ゆくゆくはマネージドサービスを組み合わせて高度なアプリケーションを作れる時代に
吉羽 ちなみにGAEは、ある意味Google専用のアーキテクチャという感じで、どちらかというとアプリケーションアーキテクチャがクラウド専用になっていて、あまりクラウドネイティブという感じはしないように思います。Google用のSDKで作ると言ったら必然的にそれしかないのでしょうか。
鶴岡 そうですね。Googleの1アプリを作っている感覚です。
吉羽 一方でAzureやAWSになると、古い会社なら、いわゆるオンプレミス時代のアクティブスタンバイ構成が残っていたのを、それもさすがに全部アクティブアクティブの構成にしようとか、キューを使おう、といった感じでクラウドネイティブにしていく流れがあります。これは正しいと思いますか？
鶴岡 そうですねえ。GCPだけにしても絶対落ちないという状態になればもちろん理想ではあるんですけど、現実的に難しいと考えると、そういうアーキテクチャが必要になってくることはあるかもしれませんね。
吉羽 なるほど、いくらでも無限にスケールして、別に性能劣化がないのであればキューを挟む必要はないですよね。インフラがどんどん進化すると、場合によって今ある疎結合化の部品がいらなくなって、新しい部品が登場するのでしょうか？
鶴岡 その可能性はあると思います。今までは性能の制約でできなかったことが、マネージドでできるようになる。サービスを作る側はそれらを組み合わせるだけで高度なことができる世界になると思います。
吉羽 組み合わせようと思ったら、ポートフォリオが広くないと組み合わせられないですよね。
鶴岡 そうです。例えば、基本はGCPで作られているけど、特定のAPIはAWSを使う、といったやり方はありえると思いますね。クラウドを組み合わせて作っていく感じでしょうね。
吉羽 サービス単位であればね。1つのサービスで複数のクラウドを使って冗長化しようとする例がたまにあるのですが、これ、結局は最小公約数的に限られた機能しか使えないので、どちらの良さも消えてしまうのではと思います。サービス単位に分けられるのであれば、このサービスに本当に合ったクラウドは何か、というのを毎回できるということですね。
さまざまなサービスを幅広く知りつつ、得意な領域があるのが強いエンジニア
吉羽 ちなみに開発者はやっぱり運用ができた方がいいのでしょうか？
鶴岡 僕は、運用はそんなにできなくてもいいんじゃないかと思います。実際、運用が詳しい人よりも、いろんなクラウドの知識を持っていて、こういうケースにはこれを使うという判断ができて、アウトプットを出せる人の方が価値が高いと思っています。
吉羽 なるほど。選択肢が数多くあり、毎回適材適所で選べることに価値があると。
鶴岡 そうです。
吉羽 今度は逆に、調査能力が必要になる？
鶴岡 はい。例えばGCPのVision APIを触ったことがある人とそうじゃない人って、画像認識に関する問題解決能力が全然違ってくると思うんですよね。AWSもすごくたくさんのサービスを出してきましたけど。
吉羽 AWSは、今サービス数が90個以上あるらしいですね。
鶴岡 ははは、もう全部触るのは無理ですね（笑）。
吉羽 僕は2013年くらいにAWSに入ったので、それこそEC2、RDS、S3、VPCなど、本当に今は誰もが使うようなメジャーなサービスしかありませんでした。その後、Redshiftなどたくさんのサービスが増え続けていきましたね。そういう意味では、よく使う鉄板のサービスと、そうじゃないものの見極めは必要かもしれないです。
鶴岡 そうなんです。サービスを知っていれば、それを使って問題解決できるときは使えばいい。サービスを知らないとしたら、自分でOSS探してきて検証して作って……と回り道をしてしまうかもしれない。そうなってくると、サービスを知っているエンジニアと知らないエンジニアでは、生産性がものすごく変わってきます。
吉羽 そうですよね。Dockerも、クラウドベンダがプラットフォームを用意しているので、自前で環境を作る必要がなくなってきていますしね。とはいえ、薄く広く知っているだけだと得意分野がない印象もあります。やはりどこかは深く掘るところも必要なのでしょうか。
鶴岡 そうですね。メルカリのSRE（Site Reliability Engineering）チームのメンバーを見ていると、幅広く知った上で、その中で得意な領域を持っています。例えばコンテナ技術に詳しい、RDBに詳しいといった、一通り広く知りつつ詳しい領域があるというのは、活躍している人に共通します。
SREは「サービスが安定して稼働する」ことに責任を持つチーム
編集部 インフラチームではなくSREチームと言っているのは、どういう意図があるのでしょうか？
鶴岡 チームの責任範囲がインフラだけにとどまらないため、SREチームと呼んでいます。もしインフラチームが存在していて、サーバやネットワークなどのインフラに関する業務だけに関心がある体制だと、サーバサイドチームとインフラチーム間で対立が起きがちです。例えばサーバサイドのエンジニアがすごく負荷のかかるクエリをデータベースに投げることで、サービスの稼働に影響が出てしまい、インフラのエンジニアは負荷状況しか見ていないからその処理を強制終了してしまったりする。こうなると誰も嬉しくないですよね。
一方、SREは、サービスが安定して稼働することに対して責任を持っています。先ほどの例で言うと、そもそも負荷のかかるクエリをレビューなどを通して未然に防ごうという動きをします。さらにリリース後に問題が発生したら真っ先に問題を発見し、原因を調査し、必要ならコードの修正も行います。別の例をあげると、稼働率が99.9％という目標値を持っていたとして、その稼働率を下回らない限りにおいては、サービスを開発するエンジニアが自由にデプロイしていい、ただし障害が発生して稼働率が守れないようだったら、一時的に、SREのメンバーが厳しくチェックしてからデプロイするプロセスに変更することもできます。
そうすると、一般的にインフラとサーバサイドは対立関係になりがちなところ、SREチームではサービス開発のエンジニアからすごく信頼されます。SREチームが頑張ってくれているからサーバサイドも安心してサービスを作れるんです。
吉羽 Googleっぽいなと思って（笑）。実際、対立しやすいですよね。
鶴岡 一緒に同じサービスを開発運用しているのに相互の信頼がない会社はたくさん聞きますね。そういった組織ではSREチームを検討すると良いかもしれません。ただしもちろんSREになるハードルは高くなっています。インフラエンジニアの知識とソフトウェアエンジニアの知識の両方に高いレベルが要求されるので。
