サービスメッシュを導入してよかった話

サービスメッシュ導入の経緯

江頭宏亮氏：ご紹介ありがとうございます。「サービスメッシュを導入してよかった話」というタイトルでお話させていただきます。よろしくお願いします。

まず軽く自己紹介をさせてください。2018年4月にサイバーエージェントに入社して、今はCATS（Client Advanced Technology Studio）という組織に所属しています。今回はインフラが主な話になるんですが、ふだんはソフトウェアの開発もインフラも両方やっています。入社直後からWinTicketというサービスの開発に携わっていてサーバサイドのリーダーをやっています。

WinTicketというサービスはどういったものかというと、オンラインで競輪の投票券を購入ができるサービスです。競輪の投票ができるだけでなく、全国の競輪場43ヶ所のレース映像も同時に見られるようになっていて、その映像を見ながら競輪を楽しめるようなサービスを提供しています。

WinTicketでサービスメッシュを導入してよかったので、その話を今回させていただけたらと思います。

本日話すことは、サービスメッシュを導入した経緯や、サービスメッシュでどんなことをやっているのか、導入してよかったことを話させていただきます。サービスメッシュを構築するためのミドルウェアがいろいろありますが、本日はあまり時間がないので、その機能比較や詳細な使い方は割愛させていただきます。

WinTicketのインフラ

まず前提としてWinTicketは、メインはGCP・GKEを使っています。ライブ配信の部分に関してはAWSのElemental Media Servicesを使っています。

ざっとこんな感じです。

マイクロサービスアーキテクチャのアンバサダーパターンを採用しています。アンバサダーパターンというのは、外部とマイクロサービスが通信をするときにプロキシを活用する方式です。マイクロサービスアーキテクチャで必要になるロギングや負荷分散、サーキットブレーキング、リトライといった共通機能をプロキシに任せています。

採用した理由としては、こういったロギングや負荷分散などの状況処理をプロキシに任せて、アプリケーションの開発に集中したいというところと、サーキットブレーキングやリトライといった機能を入れて可用性の高いシステムを構築したいということです。

アンバサダーパターンを具体的に実現するためにEnvoyというプロキシを採用しました。Envoyの説明を軽くすると、Liftという会社が作ったオープンソースのL7プロキシです。サイドカーとして使えるように設計されていて、gRPCにも対応しています。なので、gRPCのステータスコードとかを見て、ハンドリングやルーティングすることも可能です。

最近だったら、Istioがけっこう話題になっていて「なんでIstioを使わなかったの？」と思う方もいるかもしれないんですが、2018年の4月に技術選定をしていて、そのときIstioのコンポーネントのほとんどがBetaやAlphaだったので、この時点ではとくにIstioを使わずEnvoyだけを使う選択にしました。それに加えて、幸いにも社内でいくつか導入事例があったので、そういった経緯でEnvoyというプロキシの使用を採用しました。

まずEnvoyの説明を軽くさせてください。Envoyをアプリケーションのサイドカーとして利用しています。スライド下の図みたいにアプリケーションとサイドカーにEnvoyを置いて1つのPodを構成しています。アプリケーションが外部と通信するときはEnvoyを経由するように設定しています。

Envoyは同じマイクロサービスを束ねてクラスタを作ります。そして、Envoyはクラスタの管理を担うと捉えてもらえればいいかなと思います。なので、ここで複数のServiceAをまとめてClusterAというものを作ります。

例えばServiceAの3つのうちどれかがインフラの不具合などでunhealthyになるとか、うまく機能しなくなったときにEnvoyは自動的にそれをクラスタから取り除いてくれるとか、逆にスケールアウトをしたときに、4つ目のServiceが追加されたら、EnvoyがClusterAに対して4つ目のServiceAを追加してくれます。

例えばゲートウェイサービス、ユーザサービス、競輪サービス、ブローカーサービス　などがあったとき、それぞれのアプリケーションのサイドカーにEnvoyがあり、そのEnvoy同士がつながって通信を行うことでサービスメッシュを構築してます。

Envoyで具体的にやっていること

WinTicketで、具体的にEnvoyでやっていることをスライドにまとめました。アプリケーションの開発に集中するためにEnvoyに委譲している処理と、可用性を向上させるために委譲している処理の2つの軸に分けて書いています。それぞれの詳細を説明したいと思います。

まずアプリケーションの開発に集中できるようにするためにEnvoyに任せている機能は、この5つになります。まずLoggingの部分はアクセスログをアプリケーション層で収集するのではなく、完全にEnvoyに任せています。Envoyでレイテンシーやリクエストボディのサイズ、レスポンスボディのサイズなどを取れます。

次にService Discoveryです。EnvoyはいくつかのService Discoveryのタイプが選べて、マイクロサービスのレプリカの数が増えたり減ったりしたときにクラスタに自動的に追加・削除してくれます。

次にLoad Balancingです。gRPCとRESTのリクエストで利用しています。gRPCは一度コネクションを張ると、それをずっと使い続けるので負荷分散をする場合はソフトウェアレベルで工夫しなければならないのですが、Envoyのロードバランシングでやることでソフトウェアの部分では負荷分散などを意識しないで済むようにしています。

あとはConnection PoolingとStatisticsです。Envoyは標準でPrometheusの正式なメトリクスが出せるので、それを使うことでコネクションをどれぐらい取っているか、エラーレートといったものも収集できます。

次に可用性の向上のために、この4つの処理をEnvoyにしてもらっています。まず1つがHealth Checkです。Envoyがアプリケーションに対してヘルスチェックを定期的に行い、しきい値を超えたらunhealthyとしてくれてクラスタから取り除いてくれます。

他にもOutlier Detectionといった機能も使っています。例えば500系が5回連続発生したらそのPodは以上が発生しているとみなして、一定時間クラスタから除くことができます。なのでそういった機能も入れています。

次にCircuit Breakingです。これは過剰なリクエストとかコネクションがきたときに、即座に503を返すことでアプリケーションがスローダウンしてしまうことや、クラッシュしてしまうのを防ぐために入れています。

あと地味に便利なのはRetryです。特定のHTTPのステータスコード、もしくはgRPCのステータスコードが返ってきたときに特定の回数をリトライさせることが可能です。稀に発生するような一時的なエラーでもプロキシレイヤーでリトライしてもらえるので、可用性の向上にはかなりつながっていると思います。

最後にまとめです。アクセスログや負荷分散、サービスディスカバリーといったものをEnvoyの部分に委譲できたのでソフトウェアエンジニアはビジネスロジックの実装に集中することができました。さらにリトライだったりOutlier Detection、サーキットブレーキングなどの機能を使うことで万が一インフラ面の障害が発生しても影響を少なくできるという部分でサービスメッシュを導入して本当によかったなと思いました。

以上です。ありがとうございました。

（会場拍手）