Snapは2年を掛けて、モノリスからクラウドベースのマイクロサービスへ、漸進的なアーキテクチャシフトを実施した。その結果、コンピュータコストの65パーセント削減に加えて、冗長性の低減、ユーザに対する信頼性の向上といった成果を、すべてセキュリティおよびプライバシに関するコンプライアンス要件を維持しながら達成することができた。
サービス指向アーキテクチャは、スケーラビリティと、エンジニアによるオーナシップを実現する。オープンソースのエッジプロキシであるEnvoyはその重要な要素であり、サービス間通信の一貫したレイヤを構成する。社内WebアプリであるSwitchboardが、Snapのサービスメッシュのコントロールプレーンを構成し、サービスオーナがそのサービス依存関係を管理する単一ロケーションを提供している。
同社のクラウドインフラストラクチャはこの2年間で、Google App Engineでのモノリスの運用から、Amazon Web ServiceとGoogle CloudをまたぐKubernetes内のマイクロサービスへと進化した。
マイクロサービスベースのシステムをスクラッチから立ち上げるには、ネットワークトポロジなど既存の基盤インフラストラクチャに対する考慮、認証、クラウドリソースのプロビジョン、デプロイメント、ログと管理、トラフィックルーティング、レート制限、ステージング、運用環境など、多くの課題があった。
同社のエンジニアリングブログに詳説されているように、実現可能なプランを見つけるために、Snapchatterの現在のエクスペリエンスも考慮した。専任のエンジニアがいなかったため、この計画を実装する時間がなかったという事情も、ブログには綴られている。
そのためSnapは、スクラッチから立ち上げるのではなく、オープンソースのエッジプロキシサービスであるEnvoyを使って、サービスメッシュデザインパターンで進めることに決定した。
EnvoyはgRPCとHTTP/2のサポート、クライアント側でのロードバランシング、プラグイン可能なフィルタ、データプレーンとコントロールプレーンの明確な分離とxDSなど一連の動的管理APIなどの機能を提供する。AWSとGoogle Cloudで運用可能なEnvoyは、Snapのサービス間通信用のレイヤとなった。Snapでは、各Envoyプロキシが独自のコントロールプレーンに接続し、サービスディスカバリとxDS API経由で詳細なトラフィック管理設定を受信する。
サービスメッシュでは、Envoyのモバイルクライアント通信スキームに関わる問題に対処することが重要になる。それと同時に、AWSとGoogle Cloudをまたいで運用する場合には、Envoy構成の管理をセキュリティの観点から捉える必要もある。
これらを考慮して、Snap Service Meshは構成された。Snap Service Meshには、Switchboardという内部Webアプリがある。これはSnapのサービスに対する単一のコントロールプレーンで、サービスオーナが自身のサービスの依存性関係を管理することができる。
Swittchboardを構成するコアはサービスである。各サービスにはプロトコルと基本メタデータ — オーナ、Eメールリスト、説明 — がある。これらサービスのクラスタは、任意のクラウドプロバイダ、リージョン、あるいは環境に配置することができる。Switchboardサービスには依存関係とコンシューマがあり、それらは他のSwitchboardサービスである。Snapがシステム全体のAPIインターフェースをエンジニアリングチームに公開していれば、多数のコンフィギュレーションが必要になり、結果的に管理の難しいものになっていただろう。
Switchboardの設定変更は、DynamoDBに保存される。サービスメッシュ上のEnvoyプロキシは、双方向gRPCストリームを通じてxDSコントロールプレーンに接続する。サービスのEnvoyコンフィギュレーションが生成されると、コントロールプレーンは更新されたコンフィギュレーション情報をEnvoyプロキシの小規模なサブセットに送信して、変更がメッシュ全体に適用される前にヘルスチェックを実施する。
これと同時に、サービスのオーナがSwitchboardからKubernetesのプロビジョンや管理を行うことも可能だ。Spinnakerパイプラインを生成してカナリア、ヘルスチェックエンドポイント、ゾーンロールアウトを使用することもできる。
インターネットに公開するサービス数を最小限にしたいという考えから、Snapは、共有、内部、かつリージョナルなマイクロサービスネットワークを設計した。APIゲートウェイをインターネットに公開することで、外部トラフィックリソースが内部ネットワークに直接通信できないようにしている。
このAPIゲートウェイはマイクロサービスが動作するものと同じEnvoyイメージを実行し、同じコントロールプレーンに接続する。独自のEnvoyフィルタを使ってSnapchatの認証スキームを処理すると同時に、レート制限やロード制限(load shedding)を行っている。
Snapサービスメッシュアーキテクチャの全体構造は次のようなものだ。
Snapのサービスメッシュは現在、AWSおよびGoogle Cloudにまたがる7つのリージョンで稼働しており、メッシュ上では300以上のプロダクションサービスが運用されている。