「Google Cloud Anthos Day」参加レポート〜 Kubernetesを使った開発事例を学ぶ(後編)

当エントリは「Google Cloud Anthos Day」参加レポート〜 Kubernetesを使った開発事例を学ぶ(前編)　の続きになっています。

Deep-dive into Anthos on GCP

モダナイゼーションに向けた技術観点でのアプローチ

自社の提供するサービスを「モダナイゼーション」（最新化）させるための5つの記述観点を上げていました。

マイクロサービス化
インフラとアプリの疎結合化
サーバーレス
自動化
マネージドサービス活用

このうち、「マイクロサービス化」と「インフラとアプリの疎結合化」については、コンテナ技術の力による解決方法が非常に有効です。

アプリケーションを「コンテナ化」できたとしても、そのコンテナイメージを動かすための「インフラ」が必要です。
DockerサーバあるいはKubernetesクラスタがそれにあがります。
この場合、DockerサーバあるいはKubernetesクラスタというインフラは自分たちで管理する必要があります。
そんなDockerイメージの動作インフラ自体も持たなくて良い、というのが「サーバーレス」のアプローチです。
Kubernetesクラスタを提供してくれるサービスが 「Google Kubernetes Engine(GKE)」 であり、 Kubernetesクラスタさえもできる限り意識させないようにしてくれるサービスが 「Cloud Run」 です。

「マネージドサービス活用」については、有りものを精一杯使おうよ！ぐらいで捉えました。

Anthos

先に取り上げた「モダナイゼーション」を実現できたとして、 Anthos を利用した場合には更に以下のような機能の恩恵を受けられます。
(さらなる「モダナイゼーション」を実現するためのオプションサービスと解釈しています。)

App Modernization 機能（モダンなアプリケーションのプラットフォーム）
Operation Consistency 機能（マルチクラウドにおけるオペレーションの一貫性）

App Modernization 機能

「Anthos Service Mesh（ASM）」という : フルマネージドのサービスメッシュ が利用できます。

Kubernetesにおけるサービスメッシュといえばまっさきに名前が上がるのが Istio だが、「Anthos Service Mesh（ASM）」はIstio互換のAPIを持っています。

Istioとの大きな違いは以下の通りとなります。

IstioではEnvoyと呼ばれるTCP接続用のProxyコンテナが配置されます。Envoyを制御、監視するのは Pilot / Mixer / Citadel と呼ばれる3つのリソースであり、これらもKubernetesクラスタ上に存在します(Pilot/Mixer/Istio-Authの存在する領域はEnvoyをコントロールするという意味で 「コントロールプレーン」 と呼ばれます)。
「ASM」を利用した場合は、この「コントロールブレーン」のリソースが GCPのマネージドサービス として提供されます。

- コントロールプレーンはユーザークラスタから分離されるため、安定性、セキュリティ性が向上します。

このあたりは、絶対にダウンしてはいけないKubernetesの マスター サーバを当初からマネージドサービスとして提供しているあたりと同じ思想です。
やはりKubernetes上のネットワークの監視、帯域制御、暗号化を担当する領域はダウン耐性がなければいけないため、マネージドサービスに任せたいところです。

デモも実施してくれました。マイクロサービス方式のEコマースのサンプルアプリを使い、GUIから以下の内容を見せた。

マイクロサービスの状態や通信レイテンシーなどが見られるところ
サービスの相関関係がグラフ表示されるところ
サービスのSLO（Service Level Objective）の確認や設定ができるところ

「Cloud Run for Anthos」というコンテナをサーバーレスで動かすサービスが利用できるメリットもあるそうです。

オープンソースのKnativeを基にしている。
GCPでは、の2種類
- フルマネージドの「Cloud Run」
- GKEの部分が見える「Cloud Run for Anthos」
Kubernetesよりもシンプルにコンテナを利用できる
- アクセス数によって、マシンの使用効率を上げたりとか

こちらについては Anthos のサブスクリプション契約がある場合とない場合の違いがあまり理解できませんでした。

Operation Consistencyの機能

「Anthos Config Management（ACM）」という、設定ファイルからKubernetesクラスタを用意に構築する仕組みが利用できます。

Gitリポジトリを中心にしたインフラ運用のCI/CDの手法がGitOpsと呼ばれるます。
GitOpsワークフローと「ACM」を組み合わせたクラスタ管理方法は以下のようになります。

ポリシーをGitリポジトリで管理
Gitリポジトリに変更があると各クラスタが同期を開始
ネームスペースやクォータなどの設定を、「ACM」がハイブリッドなKubernetes環境に自動的に展開

Gitリポジトリの単位としては、以下の3種類を別に分けて管理することを推奨されていました。

アプリケーションのコード
Kubernetesのワークロードのマニフェスト
Kubernetesのクラスタ自体のマニフェスト

ここから先は聴講内容のメモの箇条書きになっています。

Kubernetes と推し進める、モダンなソフトウェア開発ライフサイクル」

Kubernetesを利用したアプリケーションのモダナイズについて、ライフサイクルに重点を置いて解説

モダナイズの考え方

「なぜモダナイズするか」
- 「システムが複雑になり変更しづらい」
- 「リリーススパンが長くなる」
- 「リリースまでの時間の見積もりがずれる」
- 「スケールできずボトルネックが発生」
- タイムリーな市場投入+拡張性
- - カスタマーフィードバックを早く得る→レスポンスを早くする
  - アイディアを投入するまでの時間を短くする

「解決したいのは“Time to market”であり、それにはサイクルをいかにはやく回すかが重要」
これを解決する手法の一つとしてマイクロサービス化がある

「一気にマイクロサービス化するのはおすすめしない。『改善し続ける』を一番意識してほしい」

開発の改善

1. 開発プロセス
2. すべての自動化(CI/CD)

手動から自動化へ
暗黙知から形式知へ

1. システムや組織のデカップリング

アーキテクチャにあわせて組織構造もデカップリングしていく「逆コンウェイ戦略」

1. 運用の改善

加えて大事なのが「計測すること」
- 開発だけでなく承認プロセスなどまですべてを計測してボトルネックを探す必要がある
- - ボトルネックから改善していく
- そのための手段としてバリューストリームマッピング
マイクロサービスに分解していく手法として2つを紹介
- 「Strangle Pattern」 : レガシーシステムの前段にファサードを作り、一部ずつ新しいマイクロサービスに切り出していく
- 「Anti-corruption layers Pattern」 : システム間通信において新規アプリケーションとレガシーシステムの間にレイヤーを挟む
運用の改善
- 可用性とビジネスのバランスが重要
- - なにも考えずに可用性100％を目指すべきではない → 組織とシステムが硬直化する
  - 可用性の数字を上げるときに指数関数的にコストが発生する
  - ビジネス側でどれだけのSLAを要求しているのかに合わせる」
- 「エラーバジェット(100% - 可用性
  )の考え方が大事
- - 答は、エラーバジェットの定義とリカバリーできる仕組み
  - エラーバジェットはビジネスサイドと共ににぎる。
  - リカバリーはGitOpsなどの仕組みを構築して、復元（回復）を容易にする

GCPサービスによる開発ライフサイクルとSRE

各開発ライフサイクルごとのGCPの活用例

設計
開発
ビルドとテスト
デプロイ
モニタリング
設計
- コンテナを利用する2つプラットフォーム
- - GKE : GoogleによるKubernetesマネージドサービスである
  - Cloud Run : Kubernetesを管理するまでもない用途で使える
  - - サーバレス
    - 高速デプロイ、高速スケーリング
開発
- コンテナで実行環境の差異をなくす
- データベースなどコンテナから呼び出すマネージドサービスについては、エミュレーターのgcloud beta emulatorsによって開発環境で再現できる
ビルドとテスト
- Cloud Build
デプロイ
- GitOpsとCloud Build
モニタリング
- マイクロサービス間の重要な指標を可視化するサービスとして、Stackdriver LoggingとStackdriver Kubernetes Engine Monitoring
- ユーザーへの影響のモニタリングとして、SLOのモニタリング