HelloFreshがマイクロサービス実現に向けた新APIゲートウェイに移行

HelloFreshは先日、自社アプリケーションをゼロダウンタイムで新たなAPIゲートウェイに移行した。同社エンジニアリングディレクタのÍtalo Lelis de Vietro氏が先頃の記事で、移行プロセスで体験した問題について公開している。

移行前のHelloFreshの既存APIはモノリシック構成だった。マイクロサービスアーキテクチャに移行するにあたって同社は、マイクロサービスの開発と既存インフラストラクチャへの統合を容易にするために、既存サービスと新規サービスを同じようにカバーするAPIゲートウェイを新たに構築した。それまでの同社のインフラストラクチャには、サービスディスカバリやAnsibleベースのオートメーション、システム全般のロギングやモニタリングといった、マイクロサービスをよりシンプルにするためのコンポーネントがすでに用意されていた。ゼロダウンタイムと下位互換性という問題を克服するため、チームは、古いサービスを新しいモデルに変換するプロキシスクリプトを開発した。最初の試行は失敗したが、２番目の試行で計画どおりに完了することができた。

HelloFreshのそれまでのインフラストラクチャでは、サービスディスカバリにConsulを、クライアント側のロードバランシングにHAProxyを使用しており、マイクロサービス移行を促進する要因となった。チームにはまた、新たなサービスはまずAnsibleによる自動化から始めるという決まりがあった。このオートメーションはネットワークやDNS、CI、マシンプロビジョニングなど、スタック全体をほぼ網羅していた。分散システムで複数のサービスが互いに通信する場合、最も重要になるのは可視性だが、HelloFreshでは広範なロギングとモニタリングを用意していた。モニタリングとダッシュボード用のStatsdとGrafana、サービスの動作を詳細に分析するためのELKが、技術的スタックのこの部分を構成している。

新しいゲートウェイに加えて、旧APIの認証モジュールを引き継ぐ新たな認証サービスも計画された。このためには、既存のアプリケーションをリファクタリングする必要があった。

移行前のチームの課題としては、モバイルアプリケーションの下位互換性、すべてのサービス呼び出しを新ゲートウェイ経由にすること、転送されるすべての呼び出しに対するセキュリティ、新ゲートウェイにおける既存のAPIルールの順守などがあった。モバイルアプリケーションの更新をユーザに強制することはできないので、APIが下位互換性を維持しなくてはならない。使用中のAPIは、パブリックおよびプライベートのエンドポイントで構成されていたため、これらすべてを新しいゲートウェイに登録する必要があった。マイクロサービスとゲートウェイ間で転送されるサービスコールの保護も行なわなくてはならなかった。APIの仕様は、REST APIの標準的な記述形式であるOpenAPI形式で文書化されていたので、古いものと新しいものを変換するインポートスクリプトをGoで記述して、クオータやCORSの設定、レート制限などのルールは引き続き運用することができた。

最初のマイグレーション試行は、ステップ毎のテストスイートを用意しておいた上で、最初はステージングにおいて、次に運用レベルにおいて、旧APIを新APIに置き換える、というものだった。この試行は、多数の要求によって認証データベースが過負荷になったために失敗した。負荷を過小評価していたため、データベースが接続を拒否し始めたのだ。 さらに、インポートスクリプトを使用したにも関わらず、CORSの設定にいくつかの誤りがあった。モニタリングシステムによって問題が把握され、マイグレーションはロールバックさることになった。

２回目の試行は、1回目で学んだ教訓に基づいて行われた。新しいゲートウェイを使用して作成した運用環境のレプリカ上で、Blue/Greenデプロイの実施を計画したのだ。このセットアップによって、コンフィギュレーションの変更で古いものと新しいものを簡単に切り替えられるようになった。実行中のアプリケーションのメトリックと、最初のデプロイメント時のロード・メトリックに基づいて、マシン能力も変更された。パフォーマンステストには、オープンソースの負荷ツールであるGatlingが使用された。認証サービスに関わるいくつかの問題の解決も行なった。

マイグレーション後のインフラストラクチャは次のようになった。

イメージ提供: http://highscalability.com/blog/2017/2/20/scaling-hellofresh-api-gateway.html

APIゲートウェイはHelloFreshインフラストラクチャのフロントラインを形成する。既存のソリューションを導入せずに、独自のゲートウェイを構築したのはなぜなのか？de Vietro氏がコメントセクションで次のように回答している。

Amazon API GatewayとTykを試したのですが、私たちが使用している認証プロバイダが独自のものであったため、AWS Gatewayとの統合には適しませんでした。独自の認証プロバイダを追加するには、ラムダを扱わなければならならかったのです。Grafanaへのメトリックの転送も結構複雑でしたし、当然のことながら同じプロバイダにロックダウンされることになります。Tykは独自の認証プロバイダを使用するオプションを(少なくとも当時は)提供していませんでした。ビルトインされたポリシとユーザ管理、ACLを使わなくてはならなかったのですが、そういったものは必要ではありませんでした。現在の製品はかなり違っていると思いますが、当時としてはそれが主な理由だったのです。独自のゲートウェイを使ったことで、ルート設定ファイルをgitでバージョン管理することが可能になりました。変更ログのあることは、私たちにとって非常に重要な意味があります。

同社のAPIゲートウェイは、GitHub上でオープンソースとして公開されている。