はじめに
Developers Summit 2020 (Developers Summit 2020)
Googleにおける「ソフトウェア×インフラ」デザイン～マイクロサービス・アーキテクトの視点から～
スピーカー：中井 悦司 [グーグル・クラウド・ジャパン]
の聴講メモです。
Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
デブサミ2020【13-E-5】Googleにおける「ソフトウェア×インフラ」デザイン〜マイクロサービス・アーキテクトの視点から〜 #devsumiE #devsumi - Togetter
挿入した図は講演資料を思い出して描いたものです。実際とは異なります。。
【参考】としている箇所は私が挿入しています（補足や参考資料など）。登壇者の講演内容ではありませんので、その旨ご了承ください。
聴講メモ
時代はインフラの次を考えるようになっているのではないか。
マイクロサービスとアーキテクトを切り離すことはできない。表題の「マイクロサービス・アーキテクト」を司会者が読み上げるときに中点で区切らないでほしいとお願いしたのにはそういう思いを込めている。
GCPはGoogleが社内で利用していたインフラ環境をpublicに使えるように公開したものだ。
資料で示した専用線の図はインターネット回線のように見えるが、全てGoogleのプライベートな回線となっている。このため、Googleのインフラエンジニアはネットワークにどんなパケットが流れているかを把握しているし、パケットの種類に応じて優先度をコントロールすることもできる。
【参考】
2018/01の記事で少し古いですが、Googleが海底ケーブルの図を公表していました。
新リージョンと海底ケーブルの増設でグローバル インフラストラクチャを拡張 | Google Cloud Blog
講演資料ではもっと線があったような印象を受けました。ケーブルがますます増えたということかもしれません。
Google社内ではBorgによるコンテナオーケストレーションにてデータセンターを管理している。
【参考】
Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -導入編- - inductor's blog
GCPはGoogle社内のエンジニアが使っている環境と同等といえる。
Google転職にチャレンジしたい方は試してみると良いかも！
GCPをいざ使い始めようとすると悩むのが、どう組み合わせる？どう使う？ということだ。
Googleのように全世界を相手にサービスを提供するわけではない。自分たちの規模に合わせてどう使えば良いか？ここでマイクロサービスとコンテナが出てくる。
なお、Google社内ではマイクロサービスという言葉が出てこない。マイクロサービスで開発することは検索サービス初期からのことであり、全世界向けのサービス提供のためには当たり前のことだから。
マイクロサービスのメリットはスケーラブルなことだけでない。サービスの規模によらずマイクロサービスを利用できる。
Googleのインフラの構成は論文などで公開されているが、アプリの構成は公開されていない。なので今回の発表はどこまで話せるか探りながらとなる（クビにならない範囲で…）。よって、今回の発表では写真撮影もお断りさせていただいた。
3層構造と対比したマイクロサービスWebアーキテクチャを示す。
3層構造になっていることは今も昔も変わらないが、Viewがクライアントに寄り、サーバがデータを管理するスタイルになってきた。
View相当部分はクライアント側のJavaScriptにて実装している。
BFF (Backends For Frontends) でサービスをアグリゲーションしてクライアントに返す。以前はクライアントが直接サービスを呼んでいたが、複雑になりすぎるためBFFを挟んだ。また、サービスは他のサービスを呼びだすこともある。
【参考】
BFF（Backends For Frontends）超入門――Netflix、Twitter、リクルートテクノロジーズが採用する理由：マイクロサービス/API時代のフロントエンド開発（1）（1/2 ページ） - ＠IT
この記事ではBFFが登場した経緯について説明しています。
ロードバランサーは1つの巨大なバランサーで全てをまかなっている。これは社内もGCPも同じ。
【参考】
『1つの巨大なバランサー』とは以下の記載を指しているように思えます。
GCPの「Cloud Load Balancing」を利用すると、1つのグローバルIPアドレス（VIP: Virtual IP）を用いて、地球上のすべてのリージョンにアクセスを分散することができます。
コラム - グーグルのクラウドを支えるテクノロジー | 第1回 分散型ロードバランサーを実現するMaglev（パート１）｜CTC教育サービス 研修/トレーニング
GCPを組み合わせることでGoogleのマイクロサービスアーキテクチャを実現するのは難しくない。
ただ、スクラッチで作るなら、モノリシックで設計された既存システムをどうするかについて考える必要がある。
マイクロサービスの利点を以下に挙げる。
- スケーラビリティの実現。サービス単位で独立した開発デプロイを可能にすることで新機能のリリースを安全に素早くできる。
- 想定外の影響を減らせる。多数のサービスにまたがる依存関係を気にせず、特定機能の改善に集中できる。
- チーム間の依存関係を減らせる。チーム毎の独立性を高めて、機能毎の並行開発・並行リリースを可能とする。
- スケーラブルなインフラの活用。
- SREメンバーはサービスの粒度でアプリケーションアーキテクチャが把握できるので、問題発生時の切り分けが迅速にできる。
マイクロサービスによるスクラッチ開発の課題として、サービスの独立性を確保した設計を初期段階で確実に行うことは難しいことが挙げられる。
⇒ある程度成長し終えた既存アプリから独立性の高い部分をマイクロサービスとして切り出す方が設計的には上手くいくかも？
参考文献として下記の本を挙げる。
モノリシックなところからマイクロサービスにどうやって切り出すかを解説した本。
今後はこういう本が流行るかも？
一例として既存アプリがMVCモデルで構築されてクラウドで動いているとする。
アプリの中身を外部サービスとして切り出し、コントローラが切り出した外部サービスを呼びだすようにする。
オンプレの塩漬けシステムを活用する例として、サービスの一つとして見せてしまうという手もある。新規クライアントとオンプレシステムの間にBFFを挟んで実現する。
新しい機能はサービスとして実装し、これもBFFから呼びだす。
マイクロサービス基盤を設計するとGoogleの構成に似てくるのは、世の中で必要とする物がGoogleが必要としていた物に近づいた、ということではないか。
マイクロサービスによるシステム設計とは。
- アプリケーションの機能を適切にマイクロサービスに分割する作業
- それぞれのマイクロサービスを実装する方法を考える作業
求められるスキルや知見。
- SREはシステム運用の方法論。
- マイクロサービスアーキテクトはアプリケーションデザインの知見。
- 共通してクラウドやインフラの知見。
