メルペイCTOの曾川 景介とメルペイアーキテクトエンジニアの伊藤 雄貴が対談。その時の様子をお届けします！
- メルペイCTO x アーキテクトエンジニア対談 1/3 〜注目の技術〜
- メルペイCTO x アーキテクトエンジニア対談 2/3 〜伊藤のキャリアとメルペイアーキテクトチームについて〜
- メルペイCTO x アーキテクトエンジニア対談 3/3 〜メルコインのアーキテクトについて〜
プロフィール
曾川 景介（以後、sowawa）
京都大学大学院情報学研究科システム科学専攻修士課程を修了。2011年にIPA未踏ユース事業に採択。大学院修了後にシリコンバレーの FluxFlex社にてWebPayを立ち上げる。ウェブペイ株式会社の最高技術責任者（CTO）としてクレジットカード決済のサービス基盤の開発に従事、LINEグループに参画しLINE Pay事業を経験。2017年6月メルカリグループに参画。
伊藤 雄貴（以後、yuki.ito）
事業立ち上げ時期の2018年3月にメルペイに参画し、テックリードとしてマイクロサービスの開発に携わる。その後、2019年3月に現在所属しているアーキテクトチームにジョインし、組織横断的な課題を解決するためにKubernetesやIstio、Envoyなどの技術動向を追っている。また、Microservices Platformチームの一員としてCI/CD環境の整備にも携わっている。
xDSやそれをベースとしたサービスメッシュの考え方が面白い！
◇sowawa：
対談よろしくおねがいします。早速ですが、今回は僕が質問をしていきますのでいろいろお答えてください。まずは、最近一番テンションが上がった技術的なニューストピックスについて話したいと思います、何かありますか？
◆yuki.ito：
このトピックだけでもたくさん話したいことがあります（笑）
最近だと、サービスメッシュに関連してアップデートが盛んな『xDS』についてですね。
『xDS』はネットワークプロキシであるEnvoy発のディスカバリーサービスのAPI仕様で、様々な設定をプロキシやロードバランサに動的に配布するためのAPIを定義しています。
特に今おもしろいと思っているのがxDSの利用の拡大についてですね。今までアプリケーションにEnvoyのようなネットワークプロキシをサイドカーとして付与して、それをコントロールするためのコントロールプレーン（例えばIstio）がxDSを通じてディスカバリーのデータを送信する、というのが主でした。しかし、最近はgRPCアプリケーション単体で、例えばgrpc-goがxDSを直接サポートしはじめました。
要は、サイドカーを必要としないサービスメッシュのパターンも可能になりつつある、ということですね。ちなみに、gRPCにはgrpc/proposalというプロポーザルのためのリポジトリーがあって、自分はここを眺めることによってgRPCの動向を追っています。
gRPCのコア自体をxDSに対応させようという動きが多く、最近では今までEnvoyレイヤーで行っていたようなxDSプロトコルに準拠したリトライの仕組みをgRPCのアプリケーション自体にダイナミックに注入できるようなアップデートがあったりしました。このようなxDSまわりの技術が個人的には熱いなと思っています。自分もxDSのコントロールプレーンとなるKubernetesコントローラーを自作して、まさに今メルペイのQA環境を改善するために動かしたりしています。
サービスディスカバリーは古くからある課題だと思いますが、それらをいかにダイナミックに配布していくか、という考え方が広まっていくのかなと思っています。例えば、マネージドなコントロールプレーンであると『Traffic Director』の様なものがスケールするインフラを支える上でキーポイントになってくるのかもな、と考えています。
gRPCへの導入なども含めて、最近はxDSやそれをベースとしたサービスメッシュの考え方に面白さを感じています。
◇sowawa：
例えば、とあるエンドポイントに何か情報を取りに行くとか、そのバックグラウンドにあるマイクロサービスとか、もしくは負荷の状況に応じてどちらを使うとか、そういうことを実現したいとなったときにそれらを配布するための仕組みのようなものですよね。
以前はそれを、『サイドカー』としてマイクロサービスの横にネットワークプロキシとして配置するというようなことをやらないといけなかった。その場合、プロキシのコンテナが増えることもあり、どうしても構成が複雑になってしまう。伊藤さんが今説明してくれたことを平たく言うと、「それらをある程度gRPCサーバーの実装の中で完結させることができるので、ネットワークプロキシを注入する必要がなくなるかもしれない」ということですね。
僕が気になったのは、この辺をやるとコントロールプレーン自体を冗長に、あるいは可動性を高めに運用する必要が出てくると思っています。
◆yuki.ito：
xDSはgRPCとして定義されているので、スケールについてはgRPCサーバーとしてどう正常に動かすか、という観点が大きいかなと思います。IstioのコントロールプレーンであるIstiodもそうですが、管理下にある全マイクロサービスが接続するので高負荷になりやすい、という課題はありますね。
GCPUGの記事にも出ていましたが、マネージドコントロールプレーン(MCP)という取り組みをクラウドベンダーが行っていたりします。これはその名の通りコントロールプレーンをクラウドベンダー側で管理してくれるので自分たちで運用する必要がない、というものですね。われわれのようなクラウドベンダーを使ってシステムを構築していく側からすると、マネージドなコントロールプレーンは管理するコンポーネントが減るのでありがたいなと思いつつ、自分たちで管理しないということは失われるフレキシビリティーもある、例えばマネージドコントロールプレーンでは一部のIstioの機能が利用できない、というところがあったりするので悩ましい部分ですね。このようにまさに今、xDSを含んだサービスメッシュ関連の技術のアップデートが盛んなのが追っていて面白いポイントですね。
サイドカーとしてネットワークプロキシを注入すると構成が複雑になりえるので、gRPCサーバー自体がxDSを経由してディスカバリの情報を取得するというのが面白い、という話をしましたが、一方でネットワークプロキシを注入することで得られる拡張性は見逃せないとも思っています。例えばEnvoyはWebAssemblyとして書いたネットワークフィルタを差し込める機能を持っていますが、それをgRPCサーバー単体で実装しようと思うとかなり難しくなるはずです。
なので、サイドカーパターンで『xDS』を使うのか、gRPCのアプリケーション単体で『xDS』を使うのか、どちらが今後のトレンドになっていくのかはまだ現時点では分からないですね。それぞれの良さがあり、一方をディスラプトするものではないと思うので両方とも注視していこうと思っています。
それらも含めてこのようなダイナミックなサービスディスカバリーは、今後もスケールできるインフラストラクチャーやアプリケーションを構築していくうえではキーポイントになってくるであろうと思います。個人的にはとても興味深いところです。
◇sowawa：
伊藤さんは、サービスメッシュを使って自分たちのサービスの信頼性を上げていくことや、機動的に設定変更をする仕組みづくりはすごくおもしろい技術だということを伝えたかったのだと思います。
◆yuki.ito：
そうですね。ありがとうございます。これだけでもまだまだ話したいことがありますね（笑）。
◇sowawa：
そう、無限に話すことがあるよね（笑）もう少しだけ補足すると、やはり信頼性を上げるためにはできるだけコストをかけずにシンプルで済むというようなことも重要なことかなと思います。
◆yuki.ito：
まさに複雑性が減るからこそgRPC自体にxDSを入れて、サイドカーを必要とせずにサービスメッシュを構築する、というパターンが出てきているのかなと思います。メリット・デメリットはもちろんありますが、そこもおもしろいポイントだと思って注視しています。
◇sowawa：
昔からルーティングをダイナミックにしたいという要求は存在しますが、xDSという形で改めて標準化されようとしているところがおもしろいですね。
◆yuki.ito：
そうですね。例えばLuaやWebAssemblyを用いたフィルターを動的に配ったりと、ルーティングの設定を配布するだけにとどまらないディスカバリーに関する標準としての xDS という文脈がおもしろいと思っています。
以上、メルペイCTO x アーキテクトエンジニア対談 1/3 〜注目の技術〜編でした。
次回は、メルペイCTO x アーキテクトエンジニア対談 2/3 〜伊藤のキャリアとメルペイアーキテクトチームについて〜です！
