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側（レガシーアプリケーション）との連携では制限がある場合も多い＝＞その制限の中でいかにより良い環境を実現するかがアーキテクトの腕の見せ所