Shoprocketのマイクロサービスへの旅: パート1

Shoprocketでの仕事に数ヶ月が経過し、私はフラストレーションを感じていました。我々の小さなチームの優秀な開発者たちが世界中で協力して作業しているPHPアプリケーションがありました。なぜフラストレーションを感じていたかというと、私にとって、バグ修正が新たなバグを生むように思え、新機能の統合はもっと簡単であるべきなのにそうではなく、デプロイメントは不定期でストレスが多かったからです。これらの問題の原因は、コードの高い結合度にありました。

我々はモノリシックなアプリケーションを持っており、ほとんどすべてのコードベースが1つのGithubリポジトリに存在していました。ある機能に対する更新や修正はしばしば複数の場所で発生していました。テストのために、ピアレビューのプロセスがあり、少なくとも2人の他の開発者がブランチをマージしマスターにデプロイされる前にサインオフする必要がありました。これは全て、バグが見逃されると、それを引き起こした変更を特定するのが難しいことを意味しました。そして見つけたとしても、修正は同じプロセスを経なければならず、全体のアプリケーションを再デプロイする必要がありました。

新しいものを常に探している意欲的な若手開発者として、マイクロサービスに出会ったとき、このアーキテクチャスタイルが我々の問題をすべて解決するだろうと思いました。マイクロサービスの明確な定義はありませんが、私の研究から、マイクロサービスアーキテクチャは、独立したサービスの分散システムとしてソフトウェアアプリケーションを設計する方法であり、それぞれが高度に専門化され、独自のライフサイクルを持つことを学びました。この概念に対する詳細な導入を希望する読者には、マーチン・ファウラーの優れた記事をお勧めします。

私はマイクロサービスの多くの側面に興味を持っていましたが、特に2つの点に注目しました。まず、アプリケーションを非常に厳密な境界を持つサービスに分割するという考えです。これにより、特定のビジネスコンテキストに特有のロジックがコンポーネント間で漏れ出す可能性が低くなります。境界間のインターフェースは慎重に計画する必要があります。単にローカル関数を呼び出すことは簡単ではありません。次に、各コンポーネントは独自の独立したライフサイクルを持つことができます。これにより、チームは自分たちのコードに対して責任を持ち、各サービスに最適なテクノロジースタックを使用することができます。また、変更は一度に1つのサービスにデプロイでき、何か問題があった場合でも他のアプリケーションに影響を与えずにロールバックが可能です。

私はこれに賛同しました。Shoprocketはモノリスを分割するでしょう！これはこの旅に従った短いブログ投稿シリーズの最初のものです。私の希望は、類似の移行を計画または進行中の読者が、我々の成功と失敗から学び、自分たちのプロジェクトでこの課題に取り組む準備を整えることです。

私の最初の挑戦は技術的なものではなく、人間的なものでした。私はアイデアをチームの他のメンバーに売り込む必要がありました。彼らは興味があるようでしたが、同じ熱意を共有せず、製品の初期段階で開発時間を失うことに抵抗を示しました。幸運なことに、CTOはセッション管理を見直すように依頼し、私はセッションサービスを分離することができると説得する機会を利用しました。

振り返ってみると、これは最初のサービスとしてはおそらく不適切なコンポーネントの選択でした。我々の製品には、任意のウェブサイトでeコマースを可能にするJavascriptプラグインが含まれています。我々はセッションをリソースとして扱い、カート放棄率などのKPIの詳細な分析のためにセッション情報をデータベースに保存します。しかし、このリソースは、注文やラインアイテムのように具体的なものではありません。さらに、我々はアプリケーションの状態が変わるたびにセッションリソースを使用していました。これは、サービスがアプリケーションの他の部分と避けられないほど頻繁にやりとりすることを意味していましたが、私はそれを予見できず、タスクを難しくしました。

上司を納得させた後、私はマイクロサービスに関する研究を深めました。先に述べた記事に加えて、サム・ニューマンの『Building Microservices』も非常に貴重なリソースだと感じました。私の投稿では、両者を頻繁に参照します。

彼の書籍では、ニューマンは既存のアプリケーションをドメインの境界コンテキストを反映するモジュールに再構築することを推奨しています。開発者が満足したら、モジュールを独自のサービスに分割できます。その理由は、境界が不適切に選ばれた場合、モジュールを分解して再構築する方が、余分な配管コードや永続リソースを持つ全体のサービスを分解して再構築するよりもはるかに容易だからです。しかし、時間の制約と自分自身のコンポーネントを構築したいという意欲から、私は最初のサービスに着手しました。

私は、我々のモノリスで使用しているスタックとほとんど異ならないスタックを選び、ビルドを開始しました。ビルド自体は比較的迅速に進み、数週間でREST APIを持つスタンドアロンアプリケーションを作成しました。その後、真の課題が始まりました。

私はサービスをモノリスと連携させる必要がありました。この時点で、セッション管理が他のコードとどれほど密接に結合されているかを学びました。既存の関数呼び出しを分解し、API呼び出しに変換するのに時間がかかりました。これは難しい作業でした。セッションサービスとモノリスはそれぞれ独自のデータベーススキーマを持っていたため、古いデータベースからセッションリソースを使用しているモノリスのロジックを再構築し、アプリケーションの境界でデータを再構成して、我々のJavascriptプラグインなどのクライアントとの互換性を維持しなければなりませんでした。

サービスを既存のアプリケーションに統合するのにかかった時間は、サービス自体を書くのにかかった時間よりも長く、これは通常のマイクロサービスがもたらす追加のオーバーヘッド、例えばサービス発見、ロギング、モニタリングを含んでいませんでした。さらに、密接な結合のために、多くのコードの領域に変更が加えられていました。この間、チームは様々な領域のコードに並行して作業していたため、変更をマージし、セッションサービスを本番環境に投入するには、さらに多くの作業が必要でした。

サービスはすぐに本番環境に入るかもしれませんが、今振り返ると、私はニューマンの助言に従い、既存のアプリケーションをモジュール化するために努力すべきだったと感じています。1つのサービスが独立して存在することの利点はわずかです。本当の利点は、全体を分割することであり、少なくとも粗い粒度のサービスに分けることであり、できるだけ少ない通信を行うことです。これには非常に良く考えられたコンポーネントの境界が必要であり、我々はまだそこに達していません。

私は依然としてマイクロサービスのアイデアに賛同しており、サービスを分離しようとした私の試みを成功した実験だと見ています。私はアプリケーションアーキテクチャやドメインモデリングについて多くのことを学び、その過程でREST原則の理解を深めました。これらは我々のコードの他の領域にも即座に影響を与えました。

移行を検討している読者には、可能な限りこの主題について調べ、既存のコードベースやドメインモデルに自信を持つまでは作業を先延ばしにすることをお勧めします。モノリシックなアプリケーションに安定性と耐障害性を持たせる他の方法もあります。テスト駆動開発や自動化されたユニットおよび機能テストは大いに助けになります。水平スケーリングは、デプロイメントを少しスムーズにするのにも役立ちます。

Shoprocketはマイクロサービスへの旅を続けます。パート2でさらにお伝えできることを楽しみにしています！