Google Cloud Anthos Day セミナーメモ

2020/1/30

詳細（講演資料ダウンロード可能）：　https://inthecloud.withgoogle.com/anthos-day-2001/register.html

なぜ今クラウドネイティブな開発アプローチが必要なのか

• Speaker
  • 株式会社JR東日本情報システム　那珂 真広 氏、湯川 博道 氏
  • ゼロバンク・デザインファクトリー株式会社　宮本 昌明 氏
  • Google Cloud　北瀬 公彦、佐藤 聖規
• ２つのDX
  • デジタルトランスフォーメーション
    • ビジネスサイドからの要求に迅速に対応することが求められる
  • Developer eXperience
    • 開発者にとって働きやすい環境・高速な開発を実現するための文化・組織・システム
      • デジタル化への取り組みが進んでいる企業の文化や風土、魅力（IPA　IT人材白書2019より）
        • 社内の風通しがよく、積極的な情報共有を行っている
        • オープンである
        • 仕事を楽しむ
        • 新しいことにチャレンジする
• JEIS：JR東日本情報システムでの取り組み
  • 取り組みのきっかけ
    • グループ全体での生産性向上の取り組み
      • アプリケーション開発スピードの向上
      • 将来必ず訪れる人手不足への対応
    • ＝＞コンテナ基盤の構築
  • なぜAnthos
    • 高可用コンテナ基盤をハイブリッド・マルチクラウドで利用できる
    • クラスタコンフィグを複数プラットフォームで実現
    • 可視性
  • Next steps
    • ナレッジを社内に展開
    • アプリケーションのモダナイズ化
• ゼロバンクデザインファクトリー：ふくおかフィナンシャルグループ
  • 課題認識
    • 銀行の課題
      • もともと運用負荷の高いシステム
      • サービス追加によって複雑化するシステム
      • 縦割り組織によるコミュニケーションコスト
  • 「みんなの銀行」が目指すところ
    • 銀行機能をゼロから再定義
    • ネット銀行ではなくデジタルバンク
    • その銀行を利用することがオシャレだ、とか、利用している自分に満足できる、という感覚を提供
  • コンセプト
    • みんなの「声」がカタチになる
    • みんなの「いちばん」を届ける
    • みんなの「暮らし」に溶け込む
  • ＝＞銀行勘定系システムをゼロから作る
  • 「みんなの銀行」のシステムにもとめられるもの
    • 並行して走れるプロジェクト量
      • DDD,マイクロサービス化
    • サービスリリースまでの速さ
      • アジャイル、Scrum、DevSecOps、内製開発体制
    • 加速する世の中の技術への追随の速さ、用意さ
      • フルクラウド化
  • 開発スタイル・設計
    • スクラム型アジャイルとウオーターフォールのハイブリッド
      • ウォーターフォールのいいところ：開発後の評価
    • 多拠点スクラム
    • デザイン分離
    • DDD
    • Pipeline
    • テスト自動化
• 次の10年のためのAnthos
  • Anthosのもたらす価値
    • 新しいサービスを迅速にリリース
      • 高速なリリースサイクル
      • 容易な変更
    • ビジネスの拡大のために
      • 優れた拡張性
      • 容易なメンテナンス
      • 高い可用性
    • Agility,Flexibility,Scalability,Durability
  • 特徴
    • Modernize Anywhere：オンプレでもクラウドでもモダナイゼーション
    • ポータビリティとロックイン回避：OSSベース
    • 一貫したDeveloper Experience：Write Once, Run Anywhere
    • セキュリティガードレール：自動的にセキュリティポリシーをハイブリッドKubernetesへの適用
    • 統合管理：オンプレ、クラウドにまたがった複数環境の統合管理

Deep-dive into Anthos on GCP

• Speaker : Google Cloud　篠原 一徳
• Anthos Overview
  • OSSベース、アプリケーションのモダナイゼーションのためのプラットフォーム
    • GKEをGCPに加え、オンプレ、他社クラウドでも利用できる
    • サービスメッシュ、サーバーレスなどモダナイゼーションに有用な機能が提供される
  • モダナイゼーションへの技術アプローチ
    • マイクロサービス化
    • インプラとアプリの疎結合化：コンテナ利用
    • サーバレス
    • 自動化
    • マネージドサービス活用
  • Anthosのコアコンポーネント
    • サーバレス：Cloud Run for Anthos
    • サービスメッシュ
    • ポリシー管理
    • クラスタ管理
    • コンテナ管理
• Anthos on GCP
  • Anthos Service Mesh
    • フルマネージドサービスメッシュ
    • Istio互換API、コントロールプレーンをGoogleが管理
    • Stackdriverとネイティブな連携
  • Istioのアーキテクチャ
    • Istioのコントロールプレーンはデータプレーンと同じKubernetes のクラスタ上で動作する
      • Pilot：トラフィックコントロール
      • Citadel：mTLS用のCA
      • Mixer:メトリクス収集
      • Envoy:サイドカープロキシ
  • ASM
    • コントロールプレーンがユーザクラスタから分離され、Google管理となる

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

• Speaker : アサヒプロマネジメント株式会社　清水 博 氏
• アサヒグループ
  • グローバル化
    • 外国籍社員のほうが多くなっている
    • ヨーロッパでのシェア拡大
• コンテナにたどり着くまで
  • 既存運用が大半で、新たな取り組み（SoE）へたどりつけない
    • SoRの品質・安定性をまず強化し、SoEへの取り組みへ
  • つくる　から　やめる　へ
    • 以下の優先順位
    • １．まず退役させられないか考える
    • ２．SaaSに移行＆新規利用
    • ３．PaaSに移行
    • ４．IaaSに移行（最適化）
    • ５．IaaSに移行（Lift & Shift）
  • 壊れない　から　いつでも回復できる　へ
    • １．十分な性能、帯域が安価に手に入る時代になった
    • ２．技術とともに運用だけでなく設計思想も変化する
    • ＝＞復元力：壊れても動き続けるための能力が向上
• プロジェクトの紹介
  • 小売り向けアサヒビールの量販業務
    • データからチェーン・店舗への販促提案を導き出す必要
    • ビジネス側の思い
      • 消費財市場の変化、ニーズのサイクル短期化・多様化
      • 期待を超える価値のために
      • 市場ニーズよりも早く答えにたどり着く、データドリブンであり続ける
      • ->営業スタイルだけではだめで、データからいかに導き出して提案するか
      • スピードとバリエーションを兼ね備えた提案に、様々なデータを活用して小売り向けに最適な棚割りを提案したい
    • 新カテゴリーマネージメントの構築
      • BigQuery、GKE、Cloud Composerの利用
      • リリース頻度を高める
      • SaaSとPaaSのみで構築、インフラ運用がほぼゼロ
      • 大きなバッチ処理はすべてBigQueryにお任せ：数十TBレベルのデータだが速い
      • 全ての処理をマイクロサービス化、追加改修に柔軟に対応可能
• なぜコンテナか
  • 新しいシステムも単なる過去の延長なのか
    • 2015年：汎用機からWindowsへ切り替え
    • 2019年：必要機能を精査し、マイグレーション
    • ＝もともと動いているCOBOLベースの延長線上でしかない
  • アサヒが目指すのはスイミー
    • 小さなサービスの集まりから大きなサービスを形成
      • 100匹やそこら食べられてもサービスに影響しない
• まとめ
  • アサヒグループの90%はまだオンプレ
  • とにかくスピード重視
  • 必要なのは勇気じゃなくて、情報です。

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

• Speaker : Google Cloud　塚越 啓介、頼兼 孝幸
• なぜモダナイズするのか
  • 課題
    • システムが煩雑、変更しづらい
    • 新機能をタイムリーにリリースできない
    • 時間がかかる、見積がずれる
    • スケールできずボトルネックが発生
  • 解決したいこと
    • アイデアをマーケットに投入するまでの時間を短くする
    • カスタマーフィードバックを早く得る・それに対してすぐにレスポンスする
    • ->ソフトウェア開発サイクルを改善することにより実現する
• モダナイズに必要な方法論
  • 目的とする状態：Agirity,Flexibility,Scalability,Durability、これらを改善し続けられる状態
  • コンテナ化だけで達成できるか
    • コンテナ化だけではアジリティ／フレキシビリティは大きく変わらない
      • コンテナ化に加えて以下の改善が必要
        • 開発プロセス
        • 自動化
        • デカップリング
        • 運用の改善
    • 開発プロセスの改善
      • コンセプトから一般公開されるまでのスループットをいかに上げるか
      • 開発だけではなく承認プロセスなどすべて計測し、ボトルネックから改善
        • 開発がスピードアップしても、承認プロセスで遅くなるのでは意味がない
        • バリューストリーム全体の改善
    • 自動化
      • CI/CDなど
      • 手動から自動化へ：暗黙知から形式知へ
      • 自動化~ライフサイクルの最適化へ
        • 組織のソフトウェアライフサイクルの最適化
          • （組織の承認フローに合わせる　OR　承認フローを変える）
    • 組織とアーキテクチャのデカップリング
      • 組織の分割：逆コンウェイ戦略
        • 自分たちの望ましいアーキテクチャ設計を促進するように、チームと組織側を機動的に進化させる
      • アーキテクチャ分割
        • Strangler Pattern（絞め殺し）
          • ファサードと呼ばれる機能の呼び出しを振り分けする機能をレガシー（モノリス）の前に実装し、徐々にレガシーへのアクセスを減らす
        • Anti-Corruption Layer Pattern（腐敗防止層）
          • 新規アプリケーションの設計がレガシーシステムへの依存によっての制限を回避するため、新規アプリケーションとレガシーアプリケーションとの間にレイヤーを挟む
    • 運用の改善：可用性とビジネスのバランス
      • 可用性100%を目指すべきではない理由
        • 莫大なコストが発生：線形ではなく指数関数的
      • システムの硬直化
        • 新機能や製品のリリースサイクルの長期化に加えて、スケールできないシステム
      • エラーバジェット
        • 100%－＜可用性の目標＞　＝　エラーバジェット
          • エラーバジェットを使い継続した改善を続ける
• GCPを活用した開発ライフサイクル
  • 設計：サービス選定
    • GCPを活用し、管理コストを削減：マネージドサービス（GKE,Cloud Run, Cloud Run for Anthos）
  • 開発
    • コンテナベースの開発でチーム差異をなくす
      • OS,ランタイムバージョンの差異の解決
    • エミュレータの利用でマネージドサービスの挙動を再現する
      • gcloud beta emulatorsコマンド
  • ビルド、デプロイ
    • Cloud Build
      • ビルド、テスト、デプロイをマネージド環境で実行
  • モニタリング
    • Stackdriver Logging
      • スケーラブルなフルマネージドソリューション
    • Stackdriver Kubernetes Engine Monitoring
      • GKEクラスタモニタリング：CPU/Memory使用率など、重要な指標を細かく表示、KubernetesのNamespaceやPod単位で指標を可視化

GKE + Istio + GitOps で作る日経電子版の新 Microservice 基盤

• Speaker : 日本経済新聞社　安田 竜 氏
• 日経電子版SREチームの責務
  • 日経電子版全体䛾システム全体䛾信頼性を担保する
  • 日経電子版全体䛾アーキテクチャに責任を持つ
• 課題
  • リリースで壊れやすい
    • テストしてたのに本番に出したら壊れた
    • ＝＞開発速度と信頼性の低下
  • Microservicesの監視・運用が大変：サービスとチームが大変
    • 各チーム個別にインフラ
    • 監視、運用の手法、品質がバラバラ
    • サービス横断的な調査・監視も困難
• 新規版の目的：SREの下地作り
  • 信頼性の改善
    • 開発速度と信頼性を両立するリリースフロー
    • シンプルで安全で統一された運用を強制する仕組み
  • 信頼性の把握
    • サービスやチームによらず統一された監視と運用
  • 新基盤
    • k8s/Istio
    • GitOps
    • istio/stackdriver
• 開発速度と信頼性の両立
  • サービスを壊す変更を、開発サイクルの初期に検出
  • 今までのリリースフローの問題点
    • 手元と実環境の際で壊れる可能性
      • DB等との結合
    • 開発と本番環境の際で壊れる可能性
    • リリースフローの後半で発覚：手戻り大
  • 開発の初期で検証
  • リリース環境を統一的に準備する
    • feature branch毎に独立した検証環境を用意
    • 本番と全く同じ条件かで動くStaging環境を用意
• 実現方法
  • 1branch１環境をどう実現するか
    • 通常のVMなどを使うと時間・コスト非効率
    • k8sなら既に立ち上がっているマシンでpodの追加・削除で実現可能
  • 検証環境と実際の環境の際をなくすには
    • クラスタ・ドメインを分けるとCookieやクラスタの差異が発生する
      • →同一クラスタ上で、リクエストヘッダによってアクセス先環境（pod）を分けることで実現
      • Stagingと本番環境も同様の方法で全く同じ環境を実現
      • ＝リリース後の挙動を事前に高い精度で検証できる
      • リリース時はユーザからのリクエストの向き先を変更し、Staging環境を本番環境に昇格させる
        • ＝問題児はRoutingを戻すだけでRollback可能
    • Routing制御はistio のVirtual Serviceへの設定で実現：Headerに"app-version v1"等を付加
• 課題：本番の負荷に耐えられるかをStagingで確認できない
  • Request Mirroringで本番と同じリクエストをStagingに送ることができる
    • リクエスト負荷が2倍、更新系のアクセスが来ると対応できないことも
  • Canaryリリース
    • FastlyでWeight制御：UA等で同一ユーザは同一Podに振り分け
• シンプルで安全な運用の実現
  • kubectlによる運用の問題点
    • 強力な権限が必要
    • 操作の学習コスト高い
    • ミスのリスク高い
    • 運用負荷高い
    • 変更履歴が追えない
  • ＝＞GitOps
    • クラスタの状態をすべてGit上で管理
    • クラスタは常にGit上の状態と同一の状態に同期
    • Git上のmanifestを変更することでのみシステム変更可
      • ＝直接kubectlでの変更不可：プルリクで必ずチェック、履歴管理で問題発生時すぐに戻せる
• 一貫した監視
  • Istioならサービスに影響を与えることなくメトリクス収集・監視可能
  • GKEならIstioで集めたメトリクス・ログをStackdriverに集約できる
    • StackDriverで統一的なログ形式での確認
      • 開発に関わっていないサービス調査も可能
      • サービス・チームをまたがる横断的な対応が可能
• 基盤の安全なメンテナンス
  • k8s/istioは更新が早く状況が変わりやすい
  • 大規模な構成変更をやりやすくし、常に安全、管理しやすい状態に保つ必要がある
    • Clusterレベルでのブルーグリーンデプロイ→セカンダリに更新を加え検証
    • FastlyでDNSを切り替えなくても通常はプライマリ、検証者のみセカンダリにアクセス可能にして検証

NTTドコモGKE導入事例

• Speaker
  • 株式会社NTTドコモ　岸 祐太 氏
  • Google Cloud　安原 稔貴
• GKEの評価/PoC　=>　GKE基盤アーキテクチャの検討　=>　Firestoreチューニング　=>　SREワークショップ　=>　サービスローンチ（2019年4月から2019年12月）
• NTTドコモ事例の特長
  • エンタープライズ機能におけるアプリケーションのモダナイズへの挑戦
  • レガシーシステムと連携するためのアーキテクチャと工夫
  • 完全内製ではない組織でのコンテナ開発の取り組み
• 戦略
  • SoR/SoEは疎結合に：分けて考える
    • SoR：標準技術
    • SoE：積極的に差別化
• 情報システム部内にSoE開発専門組織を新設
  • 今までのSoRでのやり方を見直し
    • アジャイル的な開発の実践
    • 基盤の見直し：すばやくスケールする基盤
• パーソナルデータダッシュボード
  • GCP基盤の導入
    • GKE：マネージドKubernetes
    • Firestore：7千万を越える顧客データの格納先としてマネージドNoSQLサービスを利用
  • 周辺アーキテクチャ
    • GitLab CI/Cloud BuildによるCI環境
    • Argoを利用したCD
    • 監視はDataDog
  • 7600万件のデータを日次で洗い替え：Firestoreのチューニングに時間を費やして対応
• エンタープライズ企業であるがゆえの課題
  • 社内にエンジニアリソース（製造要員）がない中で、外部のパートナー企業のメンバーとどのように共に取り組んでいくかが重要
    • アジャイルなマインド・文化を共に構築する
  • これまでの実績や既存システムのやり方がたくさんある中で、新しい取り組みをどう提案・導入するか
  • =>内製開発チームに近い環境で、小さく初める、まずは試す
    全員同じ拠点で、一緒に働く
    会話量が大事：あらゆる情報をオープンにする＝情報の非対称性を無くす
    会社の垣根を越えてのコミュニケーション
    パートナーと一緒にスキルを伸ばす風土
    • 机上での検討を頑張りすぎない
      • トレンドが変わりやすい、また安価に試せるものが多い＝まずはやってみる
  • エンタープライズ企業のメンバー（直接エンジニアリングに携わらないメンバー）もエンジニアリングスキルが必要
    • 責任とスピード感を持って判断することが必要：そのためにも最低限のスキル習得は必要
• 新たな価値創造と開発の最適化に向けて
  • データを活用し新たな価値を継続的に提供
  • 変化の早い市場に対応するためのサーバレスの活用
  • 情報システム部全体でシステムをモダナイゼーション
• SoR側（レガシーアプリケーション）との連携では制限がある場合も多い＝＞その制限の中でいかにより良い環境を実現するかがアーキテクトの腕の見せ所