Pathee engineering blog

世界をしなやかに変えるエンジニアたちのブログ

Pathee的システムリプレイスの道程

これはPathee Advent Calendar 2019の1日目の記事です。

Pathee Advent Calander!

こんにちは。エンジニアの土田です。

しばらくブログの更新が止まってしまっていたので、更新を活性化させるべくPatheeもAdvent Calendarに参加します!

メンバーの協力もあって、無事全日程が埋まりましたので、12月の間、お付き合いをよろしくお願いします。

さっそく私は遅刻しているのですが、、、現在取り組んでいるシステムリプレイスの話をしたいと思います。

Patheeのシステムがどうなっているか

弊社のシステムは、基本的にフロントがReact/Next.js、バックエンドがPython/Flaskで作成されており、 それがAzureのVM上に構築されています。

実は入社前の面接で散々「技術的負債がやばい」と聞かされていたため、入社当初はだいぶ身構えていたのですが、 採用しているものに珍しいところはあるとはいえ、構成やコード自体には特に奇抜なところがなく、 日々の開発を行う上ではマシンスペックを要求するところを除けば、むしろやりやすいくらいでした。

ええ、インフラを触るまでは。

Azureのシステム構成

Patheeのシステムはモノリシックアプリケーションならぬモノリシックインフラストラクチャになっており、 1つのサーバに複数のアプリケーション(当初はDBまでも)が同居する構成になっていました。

そのため、冗長構成を組むと冗長になるというダブルミーニングになっていたりと、コスト的に辛いところがありました。

実際、DBをサーバから切り離し、マネージドに変えたタイミングでは、コストが1割減りました。

コスト削減のため、コンテナ化してシステムをサーバから分離しやすくしようと画策していたところ、 別の開発案件でAzureでは使いたいやり方でコンテナが扱えないという話が出てきたため、 Patheeとしてクラウドサービス自体の移行の波が押し寄せてきました。

自分にAzureに対する知見が足りていないこともあり、最適な構成を組み辛く感じていたため、 これはチャンスとノリノリでシステムアーキテクチャを検討し、1回目のリプレイス計画を立てました。

リプレイス計画:1回目

「システム分離をするためのコンテナ化は、どこから始めるのがいいのか?」

というコンテナ化前提ではありましたが、リプレイスターゲットの選定を行ったところ、 DBのデータ構造を整えていくためにバックエンドをターゲットにしました。

これは現状のデータ構造では、利用したいデータの検索がしづらい構成になっており、機能実装などの工数が膨らみがちだったので、"開発コスト"の削減に注目した形になります。

前回、この記事を書いた背景はここにありました。

ターゲットを決めたので後は地道に、

  1. 当時のGitHub Organizationにあった33リポジトリについて、用途と必要性を洗い出し、
  2. リプレイス対象を選定後は、APIのエンドポイントの情報を洗い出し、
  3. OKR的な計画を立て、
  4. PBL(プロダクトバックログ)を作り、
  5. 開発に着手

しようとしたのですが、エンドポイントの実装計画を考えていたあたりで、

「このアプリケーションに関しては、そもそも根本的に作り直した方が良いのでは?」

という案の存在感が日に日に強くなっていく中、対象のアプリケーションに深く関わっていたメンバーのアサイン情報などもあり、 結果、バックエンドのリプレイスよりも、DBに情報を入力する部分のアプリケーションのリプレイス優先度が高くなりました。

ということで、リプレイス計画を練り直すことにしました。

リプレイス計画:2回目

データインプットを担当するアプリケーションだけあって、対象のAPIは多数のエンドポイントを持っていたため、 このアプリケーションに関しては、モノリシックアプリケーションの体で開発できるように計画しました。

また、システム化されていない業務内容の確認や、システムで実現したかった内容などを詳しいメンバーにヒアリングしつつ、 ワイヤーを作成して貰い、エンジニアが1ヶ月の間ひたすら実装していくというスタイルでやっていきました。

色々ありつつ、開発自体はそろそろ終わりが見えてきたので、データ移行計画のタスクに着手し始めたところ、 移行タスクの内容的にデータ移行から行うのではなく、一旦現状のシステムをAWSに移行するところから行ったほうが、インフラのコストとメンバーの導入コストが低くできそうだったため、今度は既存システムのインフラ移行に着手しました。

リプレイス計画:3回目

事前に既存システムについてもある程度コンテナ化を行っていたため、それをベースに対象のリポジトリをすべてコンテナ化していきました。

ローカル開発環境が整ったところでAWS用のDBを構築し、アプリケーションのAWS起動をまさに実施しているところです。 途中ではありますが、驚くほどパフォーマンスとコストが改善できているので、移行完了後また改めて状況やシステム構成を共有できればと思っています。

リプレイス計画を練る上で心がけていたこと

何回か紆余曲折してしまったリプレイス計画ですが、どんなときも以下のようなことを企みながら計画を考えていました。

  1. スタートアップに期待される速度感で
  2. 可能な限り低コストに
  3. エンジニアとしてワクワク出来る環境を作る

計画が変わることで行き当たりばったり感はありますが、私にとっては結局これが最短だったと思います。

システム移行完了を目指して

このように計画当初とはだいぶ違うところを歩きながらシステムリプレイスを絶賛実施中です。 紆余曲折しつつも、もともと年内完了と大口叩いていたので、引き続き頑張っていきたいと思います。

そして色々やってみた結果、"負債"というだけあってか、 リプレイスの手始めとしては"コスト"に関連するところから向き合うのが私のオススメです。