あじちゃんの備忘録。

〜ここはメモ帳です

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で保管

 

NextStep

  • ナレッジを社内に展開
  • アプリケーションのモダナイズ化

 

福岡ファイナンシャルグループ

デジタルネイティブ世代の考え方や行動が違う、彼らから見た銀行の価値は我々とは違うのでそれに合わせた姿に変わっていく必要がある。銀行機能をゼロから再定義する。

その銀行を利用すること自体がオシャレだとか利用している自分に満足できるという感覚を提供。

→求められるもの

  • 並行して走れる開発プロジェクトの量
  • DDD
  • マイクロサービス化
  • リリースまでの開発の速さ
  • 世の記述への追随の速さや容易さ

フルクラウド化は情報会計コールセンターなど全てにおいて行う

 

ITガバナンスとエンジニアとの間に溝を作らないようにする。フラットな関係であるように。

 


 

次の10年のために、「Anthos」は共通言語へ

 

Deep-dive into Anthos on GCP

モダナイゼーションを目指すためのAnthos

 

コントロールプレーンとデータプレーンが同居しないことでセキュリティ面で強くなる

 

 

mTLS証明書ベースの認可認証サービス

 

Cloud Run for Anthos:kubernetesよりもシンプルにコンテナを利用できる

アクセス数によって、マシンの使用効率を上げたりとか

 

Cloud Run はインフラ部が見えない。for Anthos のほうが自由度が高い。

 

 

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

古い企業である。シェアは大きい。しかし、新しい市場において新しい消費者を得る必要がある。

 

なにもない。

 

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

 

なぜモダナイズするのか

  • システムが複雑で変更がしづらい。→リリーススパンが伸びる→見積もりがずれる→ボトルネックが発生

 

 

  • カスタマーフィードバックを早く得る→レスポンスを早くする
  • アイディアを投入するまでの時間を短くする

 

モダナイズに必要な方法論目標とする状態

  • イムリーな市場等縫う→ビジネス規模に合わせた拡張
  • これがサービスごとに影響なく改善し続けられる状態

 

コンテナ化だけではアジリティ・フレキシビリティはそんな変わらないよ

 

開発プロセス

  • 開発〜承認プロセスなどを計測→ボトルネックから改善→スループットを以下にあげるか(ばりゅーするーまっちんぐ?)
  • 計測した上で改善を続ける

 

CI/CD(自動化)

  • 手動から自動化へ
  • 暗黙知から形式知
  • ソフトウエアに合わせたライフサイクルの最適化

 

組織とアーキテクチャのでカップリング

  • 組織の分割
  • システムを設計する組織は、組織の構造をそっくり真似た構造の設計を生み出してしまう
  • チームと組織川を機動的に進化させる
  • レガシーシステムの前にファサードをおいて、古いものの一部機能を新しいものとして作る。古いものには手をつけない。
  • 新しい方にリクエストを投げていく
  • 最終的に新しいものだけにできる
  • Anti-corruption layers Pattern(腐敗防止層)
  • 古いインターフェースを新しいインターフェースにするためのレイヤーを作る

 

運用改善

  • 可用性100%を目指すべきではない
  • 莫大なコスト
  • システムの硬直化
  • ServiceAvailabilityが上がればコストも上がる
  • エンジニアだけでなく組織とアーキテクチャの間を考える
  • ビジネスと可用性のバランスを取る

 

  • エラーバジェット = 100% - <可用性の目標>
  • 予算を超えない限りは自由な予算

 

GCPを活用したライフサイクルカップリングの開発をどう回すか

  1. 設計
  2. 開発
  3. ビルド、テスト
  4. デプロイ
  5. モニタリング

 

管理コストの削減

  • マネージドコンテナ基盤

Google Kubernetes Engine(GKE)

  • マスタ管理はGoogleが行う
  • ノード管理もGoogleが行う(upgrade, scale, auto repair)
  • 権限管理
  • 監視やログの管理などをGCP連携できる

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 サイト構築プラットフォーム

 

Apache + EC-CUBE

 

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さんの資料

https://speakerdeck.com/ido_kara_deru/benefits-and-usage-notes-of-istio-based-on-our-system-operation-experience