こんちには、はじめまして GxP の清田です。
今回は、 6/29 に社内にて行われた、 TechTalk について紹介したいと思います。
TechTalkとは
TechTalk は、GxPで行われている技術情報の発表・共有会です。
社員全員強制参加というわけではなく、自由参加の形式になっています。
基本的に月1回の頻度で、お昼頃に開催されているため、ランチを食べながら気軽に聞けるような場合が多いです。
今回の TechTalk は Zoom でのオンライン開催で、参加者は大体40人程度でした。オンライン開催だと、参加者が随時チャット欄に感想や質問を投稿できるのが利点で、前半30分は鈴木雄介さんの登壇 +後半30分は質疑応答 という時間配分で進行しました。
発表テーマ
今回は「AWS や Azure などのクラウドサービスや Kubernetes を鈴木雄介さん視点でどう捉えているのか」がテーマで、Agile, DevOps, Microservices が歴史的にどのような課題を解決するために登場したかを振り返り、日々追加されるパブリッククラウドのサービスや Kubernetes を取り巻く技術がどのような位置づけにあるものかを紹介していただきました。
パブリックな資料としては、以前に鈴木さんが登壇された際の資料「ITトレンドに見る日本のエンタープライズITについて」 の内容が下敷きになっているそうなので、リンク先の資料もぜひ合わせてご覧ください。
発表内容
まず Agile, DevOps, Microservices が登場した経緯のお話から。
ユーザから出た要望をいかに早くサービスとして提供できるか。
ダウンタイムが発生しないように継続的に提供するか。
これらの課題を意識し、 開発・実装のスピードを上げるだけではなく、システムのユーザーに素早く機能を提供することが重要であるという視点を持って、改善速度を上げるために出てきたトレンドが、Agile, DevOps, Microservicesであるという根底の話がありました。
Agile
話は 2001年の「Agile 」の登場から始まります。
「Agile」は短期かつ定期的に開発を行い、計画と評価を繰り返すという考え方で、
ユーザの動向が変わることで、やるべきことは頻繁に変わる。
そこで2週間などの定期的な期間を定め、
その期間のたびに「今やるべきこと」を決めて実行するようにする。
という変化への対応を意識しています。
「Agile」を実現するための開発手法として Scrum が登場しました。（鈴木さんの見解では、Scrumは共通言語を定義したのが功績とのことです。）
しかし、「Agile」や Scrum が登場しても、インフラが障壁となりなかなか普及しませんでした。アプリケーションはソフトウェアなので、2週間サイクルで改善のループを回すことができましたが、インフラのハードウェアの仕組みがついてこれなかったのです。
クラウド
その後、2006年に「クラウド」が登場しました。
雲の中のどこかにインフラがあればいいという「クラウド」の考え方により、ITリソースは「所有するもの」から「利用するもの」に変わりました。
これは大きな転換点で、クラウド登場以前のインフラは、物理的にハードウェアをデータセンターのラックにマウントして初めて使える状態になる・・という代物でしたが、「クラウド」の登場により、インフラもソフトウェアとして扱えるようになり、2週間で仕組みを変えらるようになったのです。
インフラがソフトウェア化したことで、アジャイルの実現のためにサービス全体を“ソフトウェア”として扱うことが可能になりました。
その後、システム構成をコードで管理できるようになり(IaC,Infrastructure as Code) 、インフラ構築の手順をソフトウェアのコーディングで定義できるようになっていきます。
DevOps
さて、2009年に 「DevOps」 の登場です。
「DevOps」という概念は、データセンターの移行に Scrum を取り入れたという『Agile 2008: Agile Infrastructure & Operations』の発表や、Flickr が1日10回のデプロイを実現するための手法『Velocity 2009: 10+ Deploys Per Day』の発表により、世の中に広がっていきました。
システムが安定稼働するためには、変更せずそっとしておくのも1つの手ですが、Agileからの流れとして、改善のループを回し続けることがシステムには求められるようになっていました。
そこで、「安定稼働」と「改善のループ」という二つの課題を解決するために、開発チームと運用チームが手を取り合っていく必要が出てきたのです。
この連携のことを「DevOps」 と呼びます。
例えば、先述の IaC などを取り入れ、 Blue-Green Deployment のようなデプロイ手法をとる事が挙げられます。この手法は、一時的に環境を2重にして、デプロイ後に片方を捨てるというものですが、クラウドの出現によりインフラがソフトウェア化されたことで、実現可能になりました。（オンプレの時代だと、一時的にサーバーを増やして環境を2重にした場合は、コストも2倍になってしまうため物理的に不可能でした）
改善のループを前提として、短期間で開発しようという流れがクラウドとの融合により実現したのが 「DevOps」 です。
Microservices
そして、2014年に「Microservices」 の登場です。
2011年くらいに、Agile や DevOps に取り組む先端的な企業のアーキテクチャが似ていることが議論になりました。『33rd Degree 2012: Microservices – Java, the Unix Way』 が起源となり、2014年に発表された James Lewis さんの記事で「Microservices」が世の中に広がっていきます。
「Microservices」とは、Monolithic System（一枚岩の巨大なシステム）の弊害を避けるために、システムを小さく分割していくという考え方です。
モノリシックなシステムには、開発の周期を早くしたくても、影響調査やリグレッションテストに時間がかかってしまうという課題がありました。1つの巨大なシステムだと、影響範囲が大きいので、素早くリリースできないというわけです。
「Microservices」だと、小さなサービス同士を API でつなげて動作するため、変更に対する影響範囲が特定しやすく、サービス同士が疎結合になれば個別にリリース可能という強みがあります。
大きなシステムを小さなサービス群に分割するとインフラ管理が大変ですが、クラウドによる構築や運用の自動化により、コストが非常に低くなったため実現が可能になりました。
インフラのコストや、個別のサービスが API 通信を行うネットワーク越しのオーバヘッドよりも、全体としての疎結合を目指すほうがリリースサイクルを早められるので優位性が上回ると結論付けられ、一部の企業で導入が進んでいったのです。
現在に至るまで
資料をベースにしたお話としてはここまでで、、
2014年 Lambda の登場によるサーバレスの流れの紹介と、
Dockerでコンテナ化されることを前提に、開発環境とデプロイ環境の差異が埋まりインフラはより自由になる、という話もありました。
最後に、 Microservices を実現するためのコンテナをマネジメントするための手法として、デファクトスタンダードを確立した Kubernetes の登場と、サービス間通信を助けるソリューションである Istio に代表される Service Mesh に言及して30分の登壇は終わりとなりました。
Agile から Kubernetes までの時代の流れと背景にある考え方について、登場時のインパクトや世に広がっていくまでの空気感を、システム開発の第一線で実際に体験してきた鈴木さんから直接聞くことが出来たのは、貴重な時間でした！
質疑応答
ここからが TechTalk の真髄？？の質疑応答の時間でした。
最初の質問は、マイクロサービスを検討する際の粒度について です。
鈴木さんの回答は、
「要件に応じて分ける。わかりやすいのはユーザーが違う（消費者と管理者）、性能特性が違う（バッチ、検索エンジン、分析、業務処理など）など」
また、Kubernetes を導入するか？という観点については、
「サービスが 20,30の数になると k8s を検討するとよい。プロダクトが儲かって、k8s 担当を専任で置ける規模になったら導入を検討するのではいいのでは」
AWS の ECS on Fargete などパブリッククラウドが提供するコンテナ実行基盤を使用するのも方法として挙げられそうです。
次の質問は、開発エンジニアとしてモダンなインフラにデプロイされることを念頭に置いて意識するべきことについて です。
「The Twelve-Factor App を意識すると良い」
「CNCF にあるものはそのまま触るのは難易度が高い。コンテナ化したアプリを動かすなら Fargete や GCP の Cloud Run や AWS の App Runner を触ってみる」
「カジュアルにインフラが足せる、試せる時代なのでとにかくやってみる」
と回答をいただきました。課題を解決するための手法として、
普段から実際に手を動かして使える技術の引き出しを多く持っておくことがエンジニアとしては大事になりそうです。
キャリアで多くのことを学んだ技術は何か という質問には、
「Java とそのオープンソースカルチャーから多くを学んだ」
「ただし、現代の OSS は複雑でソースコードリーディングの難易度が高い」
と鈴木さん自身の体験を共有していただきながらも、
「今からつけてほしい力としては、 Modularity を意識して対象をうまく分離する技術を知っておく。そのために、Unit Test を勉強してほしい。自分が作っているものの module を意識して、手元の数行のコードでも testability を意識するのはとても重要」
と金言をいただきました！
Vercel, Netfily などの Jamstack 系の技術やデプロイ方法の今後の発展性について には、
「フロントアプリが巨大化してきて、それをどうマイクロサービス化をどうするのかが関心事になっている。詳細はフロントに詳しい社内の有識者を交えて別の TechTalk の回で話しましよう！」
とのこと。(楽しみ)
鈴木さんが注目している技術について は
「Native Image は面白い。ビルドに時間をかけて事前にネイティブイメージにする(AOTコンパイル)ため、起動が非常に早くなる。Java は仮想マシンがあることで起動速度が遅いという前提があったが、仮想マシンを新しく作り直し、ネイティブイメージに対応した」
「これにより、無停止リリースの実現がより簡単になった」
「だだし ビルドにコンピューティングリソースが必要なのが欠点だが、CICD Pipeline の性能改善により解決していくはず」
と、サーバレスやマイクロサービス時代と相性の良いビルド方法として期待されている技術を注目されておりました。
Kunernetes(k8s) はツールが増えてどんどん参入障壁が高くなっている気がする という感想には
「5年くらいで k8s が成熟して、より簡単にシステム関連携を実現する言語が出てくるのでは。プログラミングっぽくシステム間連携を扱えるようになるはず」
「k8s ツールは増えるがどんどん簡単に扱えるようになる。CICD + IaC がセットになったものなど、k8s を意識しなくても良くなるはず」
「k8s に乗せることは簡単になるが、その次に Service Mesh がイノベーションのポイントになる」
と Knative に言及しながら、参加者の多くが感じたであろう不安に対しての長期的な視野を示していただきました。
マイクロサービスではデータ分割が難しい。やったほうがいいことはわかるけど、実際にやれるのか？ という採用するにあたっての懸念には、
「結果整合性などデータ分割が難しい。データ分割しないのも一つの解。共有データベースパターンというものもある」
「もしくは、昔からの枠組みだがマスターとトランザクション系を分ける」
「システム間連携で必要なのは データの共有 ではなく イベントの配信 だったかも。データを分割するのではなく、イベントを配ると考えてみる概念は面白い(例. 受注の変更をトリガーにする)技術としては Kafka に注目している。 CDC(Change Data Capture) は流行りそう。ただし、イベントを配るので非同期なのでそこを許容できるかがポイントになる」
と複数の解決策を共有していただきました。
最後に、 Monolith への揺り戻しはあるか という質問には、
「揺り戻しは始まっている、分割したものを統合したい。具体的にはネットワークオーバーヘッドをなくしたい。Node間を常時接続するという考え方や、 Akka,QUIC,HTTP3,gRPC 等の技術の動向は追っていきたい」
と技術の螺旋の次の周期を見据えた興味深い話で締めくくりとなりました。
感想
システム開発に関するこれまでの20年とこれからの10年を駆け抜ける、とにかく濃密な時間でした。（正直、これまでの内容では当日の内容を完全に拾いきれていないです…）
最近、登場した技術（後発の技術）は、必ずそれまでに抱えていた課題を解決するために生み出されてきたはずで、それらの歴史的な位置づけを理解することで、
ユーザにとって価値のあるシステムを届けるためにシステムを絶えず改善していく というそもそもの目的を意識しながら適切な技術選定やコーディングを行っていけると感じました。
twada さんの、技術選定の審美眼 に共通する学びも各所にあり、クラウド登場以前と以後を両方知る、ベテランエンジニアである鈴木雄介さんと対話的に学ぶ体験できて、とても刺激的な時間となりました。
（文：GxP清田、CC室 米山）
■関連記事
@gxp.group