2020/1/30
詳細（講演資料ダウンロード可能）： https://inthecloud.withgoogle.com/anthos-day-2001/register.html
なぜ今クラウドネイティブな開発アプローチが必要なのか
- Speaker
- 株式会社JR東日本情報システム 那珂 真広 氏、湯川 博道 氏
- ゼロバンク・デザインファクトリー株式会社 宮本 昌明 氏
- Google Cloud 北瀬 公彦、佐藤 聖規
- ２つのDX
- デジタルトランスフォーメーション
- ビジネスサイドからの要求に迅速に対応することが求められる
- Developer eXperience
- 開発者にとって働きやすい環境・高速な開発を実現するための文化・組織・システム
- デジタル化への取り組みが進んでいる企業の文化や風土、魅力（IPA IT人材白書2019より）
- 社内の風通しがよく、積極的な情報共有を行っている
- オープンである
- 仕事を楽しむ
- 新しいことにチャレンジする
- デジタル化への取り組みが進んでいる企業の文化や風土、魅力（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への適用
- 統合管理：オンプレ、クラウドにまたがった複数環境の統合管理
- Anthosのもたらす価値
Deep-dive into Anthos on GCP
- Speaker : Google Cloud 篠原 一徳
- Anthos Overview
- OSSベース、アプリケーションのモダナイゼーションのためのプラットフォーム
- GKEをGCPに加え、オンプレ、他社クラウドでも利用できる
- サービスメッシュ、サーバーレスなどモダナイゼーションに有用な機能が提供される
- モダナイゼーションへの技術アプローチ
- マイクロサービス化
- インプラとアプリの疎結合化：コンテナ利用
- サーバレス
- 自動化
- マネージドサービス活用
- Anthosのコアコンポーネント
- サーバレス：Cloud Run for Anthos
- サービスメッシュ
- ポリシー管理
- クラスタ管理
- コンテナ管理
- OSSベース、アプリケーションのモダナイゼーションのためのプラットフォーム
- Anthos on GCP
- Anthos Service Mesh
- フルマネージドサービスメッシュ
- Istio互換API、コントロールプレーンをGoogleが管理
- Stackdriverとネイティブな連携
- Istioのアーキテクチャ
- Istioのコントロールプレーンはデータプレーンと同じKubernetes のクラスタ上で動作する
- Pilot：トラフィックコントロール
- Citadel：mTLS用のCA
- Mixer:メトリクス収集
- Envoy:サイドカープロキシ
- Istioのコントロールプレーンはデータプレーンと同じKubernetes のクラスタ上で動作する
- ASM
- コントロールプレーンがユーザクラスタから分離され、Google管理となる
- Anthos Service Mesh
CPGメーカーのアサヒグループがコンテナ運用を始めた本当の理由
- Speaker : アサヒプロマネジメント株式会社 清水 博 氏
- アサヒグループ
- グローバル化
- 外国籍社員のほうが多くなっている
- ヨーロッパでのシェア拡大
- グローバル化
- コンテナにたどり着くまで
- 既存運用が大半で、新たな取り組み（SoE）へたどりつけない
- SoRの品質・安定性をまず強化し、SoEへの取り組みへ
- つくる から やめる へ
- 以下の優先順位
- １．まず退役させられないか考える
- ２．SaaSに移行＆新規利用
- ３．PaaSに移行
- ４．IaaSに移行（最適化）
- ５．IaaSに移行（Lift & Shift）
- 壊れない から いつでも回復できる へ
- １．十分な性能、帯域が安価に手に入る時代になった
- ２．技術とともに運用だけでなく設計思想も変化する
- ＝＞復元力：壊れても動き続けるための能力が向上
- 既存運用が大半で、新たな取り組み（SoE）へたどりつけない
- プロジェクトの紹介
- 小売り向けアサヒビールの量販業務
- データからチェーン・店舗への販促提案を導き出す必要
- ビジネス側の思い
- 消費財市場の変化、ニーズのサイクル短期化・多様化
- 期待を超える価値のために
- 市場ニーズよりも早く答えにたどり着く、データドリブンであり続ける
- ->営業スタイルだけではだめで、データからいかに導き出して提案するか
- スピードとバリエーションを兼ね備えた提案に、様々なデータを活用して小売り向けに最適な棚割りを提案したい
- 新カテゴリーマネージメントの構築
- 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（腐敗防止層）
- 新規アプリケーションの設計がレガシーシステムへの依存によっての制限を回避するため、新規アプリケーションとレガシーアプリケーションとの間にレイヤーを挟む
- Strangler Pattern（絞め殺し）
- 組織の分割：逆コンウェイ戦略
- 運用の改善：可用性とビジネスのバランス
- 可用性100%を目指すべきではない理由
- 莫大なコストが発生：線形ではなく指数関数的
- システムの硬直化
- 新機能や製品のリリースサイクルの長期化に加えて、スケールできないシステム
- エラーバジェット
- 100%－＜可用性の目標＞ ＝ エラーバジェット
- エラーバジェットを使い継続した改善を続ける
- 100%－＜可用性の目標＞ ＝ エラーバジェット
- 可用性100%を目指すべきではない理由
- コンテナ化だけではアジリティ／フレキシビリティは大きく変わらない
- GCPを活用した開発ライフサイクル
- 設計：サービス選定
- GCPを活用し、管理コストを削減：マネージドサービス（GKE,Cloud Run, Cloud Run for Anthos）
- 開発
- コンテナベースの開発でチーム差異をなくす
- OS,ランタイムバージョンの差異の解決
- エミュレータの利用でマネージドサービスの挙動を再現する
- gcloud beta emulatorsコマンド
- コンテナベースの開発でチーム差異をなくす
- ビルド、デプロイ
- Cloud Build
- ビルド、テスト、デプロイをマネージド環境で実行
- Cloud Build
- モニタリング
- Stackdriver Logging
- スケーラブルなフルマネージドソリューション
- Stackdriver Kubernetes Engine Monitoring
- GKEクラスタモニタリング：CPU/Memory使用率など、重要な指標を細かく表示、KubernetesのNamespaceやPod単位で指標を可視化
- Stackdriver Logging
- 設計：サービス選定
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"等を付加
- クラスタ・ドメインを分けるとCookieやクラスタの差異が発生する
- 1branch１環境をどう実現するか
- 課題：本番の負荷に耐えられるかをStagingで確認できない
- Request Mirroringで本番と同じリクエストをStagingに送ることができる
- リクエスト負荷が2倍、更新系のアクセスが来ると対応できないことも
- Canaryリリース
- FastlyでWeight制御：UA等で同一ユーザは同一Podに振り分け
- Request Mirroringで本番と同じリクエストをStagingに送ることができる
- シンプルで安全な運用の実現
- kubectlによる運用の問題点
- 強力な権限が必要
- 操作の学習コスト高い
- ミスのリスク高い
- 運用負荷高い
- 変更履歴が追えない
- ＝＞GitOps
- クラスタの状態をすべてGit上で管理
- クラスタは常にGit上の状態と同一の状態に同期
- Git上のmanifestを変更することでのみシステム変更可
- ＝直接kubectlでの変更不可：プルリクで必ずチェック、履歴管理で問題発生時すぐに戻せる
- kubectlによる運用の問題点
- 一貫した監視
- Istioならサービスに影響を与えることなくメトリクス収集・監視可能
- GKEならIstioで集めたメトリクス・ログをStackdriverに集約できる
- 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：積極的に差別化
- SoR/SoEは疎結合に：分けて考える
- 情報システム部内にSoE開発専門組織を新設
- 今までのSoRでのやり方を見直し
- アジャイル的な開発の実践
- 基盤の見直し：すばやくスケールする基盤
- 今までのSoRでのやり方を見直し
- パーソナルデータダッシュボード
- GCP基盤の導入
- GKE：マネージドKubernetes
- Firestore：7千万を越える顧客データの格納先としてマネージドNoSQLサービスを利用
- 周辺アーキテクチャ
- GitLab CI/Cloud BuildによるCI環境
- Argoを利用したCD
- 監視はDataDog
- 7600万件のデータを日次で洗い替え：Firestoreのチューニングに時間を費やして対応
- GCP基盤の導入
- エンタープライズ企業であるがゆえの課題
- 社内にエンジニアリソース（製造要員）がない中で、外部のパートナー企業のメンバーとどのように共に取り組んでいくかが重要
- アジャイルなマインド・文化を共に構築する
- これまでの実績や既存システムのやり方がたくさんある中で、新しい取り組みをどう提案・導入するか
- =>内製開発チームに近い環境で、小さく初める、まずは試す
全員同じ拠点で、一緒に働く
会話量が大事：あらゆる情報をオープンにする＝情報の非対称性を無くす
会社の垣根を越えてのコミュニケーション
パートナーと一緒にスキルを伸ばす風土
- 机上での検討を頑張りすぎない
- トレンドが変わりやすい、また安価に試せるものが多い＝まずはやってみる
- 机上での検討を頑張りすぎない
- エンタープライズ企業のメンバー（直接エンジニアリングに携わらないメンバー）もエンジニアリングスキルが必要
- 責任とスピード感を持って判断することが必要：そのためにも最低限のスキル習得は必要
- 社内にエンジニアリソース（製造要員）がない中で、外部のパートナー企業のメンバーとどのように共に取り組んでいくかが重要
- 新たな価値創造と開発の最適化に向けて
- データを活用し新たな価値を継続的に提供
- 変化の早い市場に対応するためのサーバレスの活用
- 情報システム部全体でシステムをモダナイゼーション
- SoR側（レガシーアプリケーション）との連携では制限がある場合も多い＝＞その制限の中でいかにより良い環境を実現するかがアーキテクトの腕の見せ所