Google Cloud Anthos Dayの感想

Google Cloud Anthos Dayに参加してきたので、思ったことや感想を淡々と書こうと思います。

■当日のスケジュール

【Track 1】
1.『なぜ、今クラウドネイティブな開発アプローチが必要なのか？』
2.『Deep-dive into Anthos on GCP』
休憩
3.『CPGメーカーのアサヒグループがコンテナ運用を始めた本当の理由』
4.『Kubernetes と推し進める、モダンなソフトウェア開発ライフサイクル』
休憩
5.『GKE におけるセキュリティ対策と運用』
6.『NTTドコモ情報システム部における GKE 導入事例　～パーソナルデータダッシュボード開発～』

【Track 2】
1.『なぜ、今クラウドネイティブな開発アプローチが必要なのか？』　※サテライト
2.『Kubernetes コンポーネントの活用方法』
休憩（ライトニング トーク）
3.『マルチクラスタで GKE を最大限活用するドラゴンクエストウォーク事例』
4.『Istio を利用したモダンなマイクロサービスシステムの実現』
休憩（ライトニング トーク）
5.『GKE+Istio+GitOps で作る日経電子版の次世代マイクロサービス基盤』
6.『GKE で実現する自由な EC サイト構築プラットフォーム』

今回はTrack1に聞きたいものが多かったので、Track1にいました。そのため、感想はTrack1のものになります。

■まとめ

個々の内容は下記に記載しておりますので、ここでは全体のまとめをしたいと思います。個人的に心に残った言葉は下記です。

2つのDX
可用性100%を目指さない
SoRとSoEの連携は完璧にはできない

もちろんAnthosを使ったk8s運用や管理も非常に面白かったのですが、コンテナ技術を現場に導入するため「なぜ導入が必要なのか」を理解することでただの流行り技術をやるのでなく、確固たる理由のがあるからこそコンテナの選択肢 => AnthosやCloud Run(マネージドの方)などの導入が現場で進むのでないかと考えていたからです。ですので、流行ではなくデファクトスタンダードになるであろう技術がどのような理由で選ばれているのかを知るためにも、上記の言葉をが非常に心に残りました。

2のDX
こちらはエンジニアリング組織論への招待の著者がfukabori.fmの19.エンジニアリング組織を取り巻く変化とは？に出演した際に、始めて聞いた言葉でした。

Digital Transformation
Developer eXperience

 この2点は実は表裏一体で、システムの内製化（手の内）をするためには開発者に快適な環境（ここの定義は難しいです）を提供することが必要ですよね。とポットキャストで説明されていました。（私の理解ですが）

イベントでは2025年の崖などに伴う社会環境の変化とそれに企業が対応するためにDXが必要ですよね。と話されていて「Rehost -> Replatform -> Refactor」を示しコンテナ（Anthos）へ移行する道を示していました。

つまり、社会変化に対応するためにDX(Digital Transformation)は必須です。そして具体的な方法は現状だとコンテナ（Anthos）を取り込むことで、開発ライフルサイクルの変化（Developer eXperience）、もちろんビジネス面にも多大な影響を与えれると理解しました。

課題としては19.エンジニアリング組織を取り巻く変化とは？でも話されていましたが、DXを2つの意味で説明している人がいないことも　DXが進まない原因と云われていたので、上記の理解を現場にも広めたいと思いました。

可用性100%を目指さない
『Kubernetes と推し進める、モダンなソフトウェア開発ライフサイクル』と『CPG メーカーのアサヒグループがコンテナ運用を始めた本当の理由』の発表で可用性のワードが出ていました。何かのサービスを始める時や新技術を既存のサービスに取り入れる際に、エラーや障害発生した場合にどうするかと必ず問われます。（もちろん私が依頼者でも問います。）その際に、障害は発生させるべきではないのですが、100%なくすこともできないものです。だからこそ、上記の問いに対しての答えを持っていませんでした。

その中で、可用性100%を目指すデメリットとしてシステムの硬直化とコスト増大を説明されたのですが、このデメリットは現場で直面しており非常に理解できるものでした。

ここで頂いた回答は、エラーバジェットの定義とリカバリーできる仕組みでした。エラーバジェットを定義しその改善を常にしていく（サービスやシステムを常に成長させる）この部分はビジネスサイドと共ににぎる。そして、リカバリーはGitOpsなどの仕組みを構築して、復元（回復）を容易にする（壊れることを受け入れて、それに対し素早く回復する仕組みを模索し続ける）。

つまり、エンジニア側もサービス（システム）を常に成長させ続ける意識を持つことで、システム硬直を全員で防いでいくことで可用性100%にするのでなく障害に強いシステムや組織を作っていくことが今日求めてられていると気がつきました。

SoEとSoRの連携は完璧にはできない
『NTTドコモ情報システム部における GKE 導入事例　～パーソナルデータダッシュボード開発～』こちらの発表で、既存サービスと新サービスの連携がなぜできにくいのかを知ることができました。SoEとSoRの理解としては、ソフトウェアーファーストで記載されている「攻めと守り」で捉えています。

SoE(System of Engagement) - 攻め（新規開発）
SoR(System of Records) - 守り（すでに収益化できている）

NTTドコモさんのような企業ですと、すでに大量のデータを取得できているSoRのサービスがあるが、ビジネスとして拡大するためにSoE部分の開発は必要かつSoRとの連携はビジネス観点では必須だと思われます。ここからは推測ですが、バッチの時間やクラウドとオンプレの環境違い、ビジネススコープの違いなどで容易にデータ連携ができなくなってしまうのではないでしょうか。その結果として、ファイル連携でデータをクラウドに送っているなどの部分がありました。　結果、登壇者（NTTドコモの方）の方は、SoEとSoRの連携は制約なくしては連携できないことを言われていました。

新規開発する場合には必ず直面する事象のため、制約なくデータ連携はできないだからこそ、ゴールに向けてルールや制約を作りそのスコープの中でゴールに向かうようにすることが必要だと学びました。もちろんその際に技術が足かせになってはいけないため、エンジニアは常に最新サービスや技術を学び続けることは必要だとも言っていました。私も非常に共感したため、noteに今回の学びを残そうと思いました。

以上3点の学びを記載しましたが、なんか技術のことないなーと思いましたが、この3点を実現するにも技術は必須のためしっかり　k8s(Anthos, Cloud Run)など学んで使い所などを学ぼうと思いました。

■『なぜ、今クラウドネイティブな開発アプローチが必要なのか？』
下記2社の登壇と事例を用いてクラウド利用（コンテナ利用）の説明がありました。

株式会社JR東日本情報システム
ゼロバンク・デザインファクトリー株式会社

また下記の価値をAnthosを通じてもたらすことで、ビジネスでの機能リリースの加速と日々の運用改善ができると説明がありました。マルチクラウドも今後はできるようになっていくようなので、しっかり勉強をしようと思いました。

Agility
Flexibility
Scalability
Durability

■ 『Deep-dive into Anthos on GCP』
Google Cloudの方によるAnthosの説明です。Anthosのもたらす価値に2点を挙げられていました。

App Modernization
Operation Consistency

これは私がAnthosを調査していないのが原因なのですが、Anthosってライセンスモデルが従量課金性じゃないんですね。

また、ASM(Anthos Service Mesh)の説明もありました。Googleが提供するフルマネージドのサービスメッシュでStackdriverとの連携など！！私がローカルでk8sの勉強をしてたさいに本番でどう監視するの？？。。。サービス連携をどう把握するのかなどをフルマネージドで管理できるのには魅了句しか感じませんでした。

あと、Cloud Run for Anthosの説明もありました。

■ 『CPG メーカーのアサヒグループがコンテナ運用を始めた本当の理由』

アサヒがコンテナに移行を決定した理由として「復元力（Resiliencability）＝壊れても動き続けるため」をあげていたことに驚きました。その土台にはビズネス側の思いがあって、システムがその妨げにならないように改善が必要という判断から来たものだとわかりました。

つまり、現状を変えるには不確実性をどう乗り越える（不確実な状態にしないようにする）かが必要で、エンジニアとしては思いや精神論ではなくしっかりとした技術的説明とビジネス側の思いの理解が必要なんだと感じました。

■ 『Kubernetes と推し進める、モダンなソフトウェア開発ライフサイクル』
サービスをモダンであり続けるために、コンテナ化だけでなく下記をすることを強調されていました。

アジリティやフレビリティに達した開発プロセス
高速なリリースサイクルのために全てを自動化
システム間の依存を切るためシステムや組織のデカップリング
システムの変更に合わせた継続した運用の改善

上記を満たしていくと開発ライフサイクルが下記のように変更していく（下記を目指して上記に取り組む）

GCPを活用し、管理コストを削減
環境差異をなくした開発
自動化による、開発品質の保証
マイクロサービス間の、重要な指標を可視化
SLO定義による、継続的な安全運用の実現

ここの話は実体験を元に書いてみたいので、もう少し実体験を積んだら記載します。

■ 『GKE におけるセキュリティ対策と運用』
KARTEすごいですよね。アクセスをしっかり捌きながら、メディア側が欲しい情報を提供できている（UXをしっかり考えられていて）かつUIはモダンです。

ここでのセキュリティ対策として下記のことを言われていました。

Googleの管理範囲、ユーザの管理範囲を意識
基本はドキュメントに従う
基本的な運用ができてから必要な時に検討していく

また、GKE Sandboxなどの説明をしていただきましたが。。。私の理解が追いつかなかったです。勉強しなおします。

■ 『NTTドコモ情報システム部における GKE 導入事例　～パーソナルデータダッシュボード開発～』

エンタープライズ企業の導入事例のため、自社開発をメインとしている企業とはかなり異なっていますが、流動するチームでどうやって導入したかなどを聴けました。

主なトピックとしては下記を話されていました。

SoE発足までの流れ
Firestoreの500/50/5ルール
k8sをマネージドk8s(GKE移行)
小さく始める（内製開発のために）
チーム（パートナー含め）全員でスキルを磨く仕組み

k8sをオンプレで利用している企業が運用面で限界を感じマネージドk8sに移行する話は、他の企業でも聴いているので最近はk8sはGKEかなと思っていました。ですが、k8sの理解をするためにチーム全体でスキルを磨くことは考えていなかったので（個人で磨いてくイメージが強かったです）、この仕組みは私のチームにも取り入れようと思いました。