Google Cloud Anthos Day のメモ
#gc_anthosday
https://inthecloud.withgoogle.com/anthos-day-2001/register.html
Rehost, Replatform, Refactor
コスト、スケーラビリティ、開発速度
マイクロサービス化
Developer eXperience
開発者の働きやすさをより良くする必要があった。
これからは少ないリソースで効率の良い開発が求められています。
デジタル化への取り組みが進んでいる企業の文化や風土魅力などにおいて、成果が出ているところと出ていないところのちがい
→社内の風通し(積極的な情報共有)、オープンである、仕事を楽しむ、新しいことにチャレンジする
JEiS 株式会社JR東日本情報システム
取り組みのきっかけ
生産性向上の取り組み
- アプリケーション開発スピードの向上
- 将来必ず訪れる人手不足への対応
→コンテナをやってみよう
なぜAnthos
効果用のコンテナ基盤→ハイブリッドまj流智クラウドで利用可能
クラスターのコンフィグを複数プラットフォームで管理できる
マイクロサービスの統一テストが可能
ハイブリッドコンテナ基盤
→開発(GKE)・テスト(GKE)・本番(GKE)・オンプレ環境(GKE On-prem)などの複数クラスタを一元管理したかった(パブリックとインプレのハイブリッド運用→今後はマルチクラウドを目指している)
CI/CDパイプラインでアプリ開発を高速化
GitLab(ソースコードの管理)→CI/CD(テスト実行、イメージビルド)→各環境へのデプロイ
GCPやオンプレミスのHA機能で可用性を高める
ノードやPodのオートスケール機能を活用
各クラスタの設定値をコード化してGitLabで保管
- ナレッジを社内に展開
- アプリケーションのモダナイズ化
福岡ファイナンシャルグループ
デジタルネイティブ世代の考え方や行動が違う、彼らから見た銀行の価値は我々とは違うのでそれに合わせた姿に変わっていく必要がある。銀行機能をゼロから再定義する。
その銀行を利用すること自体がオシャレだとか利用している自分に満足できるという感覚を提供。
→求められるもの
- 並行して走れる開発プロジェクトの量
- DDD
- マイクロサービス化
- リリースまでの開発の速さ
- 内製化初体制
- アジャイル
- Scrum
- devsecops
- 世の記述への追随の速さや容易さ
- フルクラウド化
フルクラウド化は情報会計コールセンターなど全てにおいて行う
ITガバナンスとエンジニアとの間に溝を作らないようにする。フラットな関係であるように。
次の10年のために、「Anthos」は共通言語へ
Deep-dive into Anthos on GCP
モダナイゼーションを目指すためのAnthos
コントロールプレーンとデータプレーンが同居しないことでセキュリティ面で強くなる
mTLS証明書ベースの認可認証サービス
Cloud Run for Anthos:kubernetesよりもシンプルにコンテナを利用できる
アクセス数によって、マシンの使用効率を上げたりとか
Cloud Run はインフラ部が見えない。for Anthos のほうが自由度が高い。
CPG メーカーのアサヒグループがコンテナ運用を始めた本当の理由
古い企業である。シェアは大きい。しかし、新しい市場において新しい消費者を得る必要がある。
なにもない。
Kubernetes と推し進める、モダンなソフトウェア開発ライフサイクル
なぜモダナイズするのか
- システムが複雑で変更がしづらい。→リリーススパンが伸びる→見積もりがずれる→ボトルネックが発生
↓
- カスタマーフィードバックを早く得る→レスポンスを早くする
- アイディアを投入するまでの時間を短くする
モダナイズに必要な方法論目標とする状態
- タイムリーな市場等縫う→ビジネス規模に合わせた拡張
- これがサービスごとに影響なく改善し続けられる状態
コンテナ化だけではアジリティ・フレキシビリティはそんな変わらないよ
CI/CD(自動化)
- 組織の分割
- コンウェイの法則
- システムを設計する組織は、組織の構造をそっくり真似た構造の設計を生み出してしまう
- 逆コンウェイ戦略
- チームと組織川を機動的に進化させる
- アーキテクチャ分割
- Strangler Pattern(絞め殺し)
- Anti-corruption layers Pattern(腐敗防止層)
- 古いインターフェースを新しいインターフェースにするためのレイヤーを作る
運用改善
- 可用性100%を目指すべきではない
- 莫大なコスト
- システムの硬直化
- ServiceAvailabilityが上がればコストも上がる
- エンジニアだけでなく組織とアーキテクチャの間を考える
- ビジネスと可用性のバランスを取る
- エラーバジェット = 100% - <可用性の目標>
- 予算を超えない限りは自由な予算
GCPを活用したライフサイクルデカップリングの開発をどう回すか
- 設計
- 開発
- ビルド、テスト
- デプロイ
- モニタリング
管理コストの削減
- マネージドコンテナ基盤
Google Kubernetes Engine(GKE)
Cloud Run
- 高速デプロイ
- 高速に 0 to N スケール
- サーバレス・ネイティブ
- サーバ管理の必要がない
- 言語やライブラリの制約がない
- 使った分だけの支払い
- 高いポータビリティ
- Knative API の一貫性
- ロックインの排除
開発
- OS、ランタイムバージョンの差異の解決
- エミュレータを使用することでマネージの挙動を再現できる
Gcloud beta emulators
ビルド、テスト
自動化による品質の保証
- ビルド、テスト、デプロイをマネージド環境で実行できる
- GitHubのpushやPRのイベントをトリガーする
デプロイ継続的デリバリー
- Cloud Build のトリガーで、GitOpsを実現
モニタリング
Stackdriver Logging
- リアルタイムのログ監視
- ログ解析
GKEクラスタのモニタリング
- CPU/Memory使用率などの細かい指標がみられる
継続的な安定運用の実現
SLOを考慮した運用
- サービスレベル指標を下回った場合にのみアラートを飛ばすような設定が可能
- SLOの定義は様々→チーム全体で認識を持って取り組む必要がある
GKE+Istio+GitOps で作る日経電子版の次世代マイクロサービス基盤
日経電子版の開発にGitOpsを利用する
課題がある
- リリースで壊れやすい
- Microserviceの監視が難しい(サービストチームが多い)
- 各チームが個別にインフラを頑張っている
- 運用監視手法や品質がバラバラ
- サービスの横断的な監視や調査も困難
新基盤の目的→SREの下地作り
- 信頼性の把握と改善
開発速度と信頼性の両立
いままで:
- 改修→レビュー→開発環境→本番環境
問題点:
- 実際の環境での動作確認ができない。(開発環境では動いてたのに本番環境では動かない(><,)
対策:
- 確認環境と本番環境の差異を(できるだけ)なくす→staging環境を作る
- 1branch 1機能検証環境の状態を作る
Domainが違うとcookieの動きか違うなどの差異がある
→リクエストヘッダによってアクセス先環境を分けることで実現する
★リリース時はユーザからのリクエストの向き先をstagingに変更して、staging環境を本番環境に昇格する
問題が起きたらRoutingを戻すだけでOK
Istio で routing を制御する
ここでの問題:
- 本番の負荷・リクエストパターンでしか再現しない問題を検出できない
Request Mirroring で本番と同じリクエストをstagingに送る
- 更新系ではデータ整合の問題がある
- 他のサービスへ2倍の負荷がかかる場合も...
シンプルで安全な運用
- 人為的な事故が起きづらい
- 事故が起きてもすぐ戻る
Kubectl による運用の問題
→学習コスト、操作ミス、運用負荷、変更履歴が追えない、強力な権限が必要
↓ これの対策として
GitOps
- PRレビューを通じて操作ミスや設定ミスを防止
- 変更履歴を管理
- 運用ツールが git, github のみなのでシンプル
一貫した監視
- Istio ならサービスに影響を与えずメトリクスを収集でき、監視が可能に
- Stackdriver によって統一されたモニタリングができる
- 開発に全く関わっていないサービスの調査も可能
- サービスやチームをまたいだ対応が可能に
基盤の安全なメンテナンス
Clusterレベルの Blue/Green で安全にメンテする
- ArgoCDでBlueと同じ環境のGreenを作る
- DNSを切り替える
- Fastlyを解することで本番同様状況を確認できると安全
GKE で実現する自由な EC サイト構築プラットフォーム
DB
- コンテナ(Pod)を利用
- データファイルはPVに永続化
キャッシュサーバ
- Pod
ファイルサーバ
- Compute Engine
CronJob
- 証明書更新
- DB/ファイルバックアップ
- レポート作成
1サイトを1NameSpaceで管理
→コンテナイメージは同じだがサイトごとに異なる設定を持つ
NetworkPolicyでNS間のアクセスを制御
↓
- スケールがサイトごと
- 自由なカスタマイズを実現
- NS分離によってサイト間で干渉しない
Helm
- 異なる設定を定義できる
アップデート
各サイトごとに `helm upgrade` を実行する→Cloud Runで並列化可能
Stackdriverによってログを管理、モニタリング
その他
コロプラさんの資料
https://speakerdeck.com/inletorder/monitoring-platform-with-victoria-metrics
HITACHIさんの資料