【デブサミ2020】セッションレポート：13-E-5 Googleにおける「ソフトウェア×インフラ」デザイン〜マイクロサービス・アーキテクトの視点から〜
マイクロサービス・アーキテクト
登壇：中井悦司さん（グーグルクラウドジャパン）
中井さんによると、今年マイクロサービス・アーキテクトは流行するのではとのこと。超満員で、個人スポンサーなのにあわや入れないところだった。すごい。
GCP
コンセプト
Googleのソフトウェアエンジニアと同じ体験を一般のデベロッパーにもパブリッククラウドとして提供
世界中の情報を整理し、世界中の人々がアクセスして使えるようにする
特徴
専用回線でのグローバルネットワークがあり、高速
Datacenter as a Computer
悩み
どう組み合わせればいい?
中の人は実際どうやって使っている?
多くの場合、Googleほどグローバルなビジネス展開をしているわけではない
なるほど、という感じだ。たしかにGoogleほどグローバルな会社など、ほとんどないだろう。それくらいの規模の会社ならPrivate Cloud持ってるだろうし。
で、そこで必要になってくる考え方がマイクロサービスですよという話のようだ。
Googleのエンジニアはどうマイクロサービスをデザインしているか
アプリケーションレベルでのノウハウは外部には公開していない
ヘタに喋るとクビになる笑
クビにならない範囲で、できるだけ伝える
だから、このセッションは撮影禁止
なんだなんだ、ワクワクするじゃないか。
マイクロサービスWebアーキテクチャ
クライアント（View）
BFF（Backend for Frontend）
サービス[同期系]
サービス[非同期系]
BFFで外部公開APIとサービス実装を分離
Google社内では昔からマイクロサービスだった
社内では上記のマイクロサービスWebアーキテクチャとほぼ一緒
異なるのは、ロードバランサー（Maglev）がすべて共通であるなど、共有できるものは共有していること
ミドルウェアがふんだんに用意されている
バッチ処理は外部のデータパイプライン
マイクロサービス化しながらも共有できるリソースは共有しよう、という思想のようだ。共有する/しないはどのように判断したり、見直したりしているのだろうか。
はじめの一歩と次の一歩
小さくはじめて、小さいままでいるケースが少なからずある
既存アプリのマイクロサービス化を考えていきたい
メリットはスケーラビリティだけではない。安全かつスピーディに機能を追加していける良さがある
マイクロサービスにする対象は、塩漬けにするようなものではなくアジャイルに改善していきたいものですよね?という問いかけ。こういうwhyの明確化は大切だな。
機能が10も20も変更されるのは、人間の脳がついていかない
マイクロサービス化は人間のためでもある。自分が理解できる範囲で変更していける
これも納得。
マイクロサービス化されていると、サービスの粒度でアプリケーションアーキテクチャが把握できる。SREが問題発生時に切り分けしやすい
なるほど、逆にいえば、問題発生時の切り分けポイントに境界がくるようなアーキテクチャがよいアーキテクチャということか?
デメリットと向き合い方
マイクロサービスのデザインはめちゃくちゃ難しい
フルスクラッチで開発したものが将来、どのように機能拡張していくのかはわからない
既存のサービスであれば、そこらへんは想像がつく。たとえモノリシックなシステムであっても、再設計するという意味で言えば必要な情報が揃っている
これは目から鱗だし、賛成だ。レガシーシステムはとかく辛いものとして傍に追いやられるが、ビジネスを支えた実績とそのためのナレッジが詰まっている。ただ傍においやるのではなくマイクロサービス化するためのたたき台にするというのは筋がよい。
オンプレはどうするのか
塩漬け?
BFFで既存システムを抽象化して機能単位でリプレースする
BFFを経由するシステムにすれば、BFF側からは既存システムも1サービスとして扱うことができる
いきなりI/Fを変えてもクライアント側の改修コストもバカにならない。この作戦は理にかなっている。オンプレのシステムも置いていかない、メンテナンスしなければならないという環境ではベストプラクティスなのかもしれない。
既存システムと向き合う勇気をもらった
GCP云々というよりは、マイクロサービスアーキテクチャの一般論として非常に勉強になった。そしてエンジニアとしては、レガシーなシステムをどうエレガントにマイクロサービス化していくかというアイデアと戦略が勉強になったし、向き合う勇気をもらえた気分だ。多くのエンジニアにとって学びが多いよいセッションだった。
おすすめされていた書籍
この記事が気に入ったらサポートをしてみませんか？