1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

  • この記事は、Qiitaアカウントの整理のため、別のアカウントで投稿した過去の記事を移行してきたものです。全く同様の記事があるかもしれませんが、盗作等ではありませんのであしからずご容赦ください。
  • 過去記事 投稿日:2020年02月10日

開催概要

2020/1/30

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

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

  • Speaker
    • 株式会社JR東日本情報システム 那珂 真広 氏、湯川 博道 氏
    • ゼロバンク・デザインファクトリー株式会社 宮本 昌明 氏
    • Google Cloud 北瀬 公彦、佐藤 聖規
  • 2つの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への取り組みへ
    • つくる から やめる へ
      • 以下の優先順位
      • 1.まず退役させられないか考える
      • 2.SaaSに移行&新規利用
      • 3.PaaSに移行
      • 4.IaaSに移行(最適化)
      • 5.IaaSに移行(Lift & Shift)
    • 壊れない から いつでも回復できる へ
      • 1.十分な性能、帯域が安価に手に入る時代になった
      • 2.技術とともに運用だけでなく設計思想も変化する
      • =>復元力:壊れても動き続けるための能力が向上
  • プロジェクトの紹介
    • 小売り向けアサヒビールの量販業務
      • データからチェーン・店舗への販促提案を導き出す必要
      • ビジネス側の思い
        • 消費財市場の変化、ニーズのサイクル短期化・多様化
        • 期待を超える価値のために
        • 市場ニーズよりも早く答えにたどり着く、データドリブンであり続ける
        • ->営業スタイルだけではだめで、データからいかに導き出して提案するか
        • スピードとバリエーションを兼ね備えた提案に、様々なデータを活用して小売り向けに最適な棚割りを提案したい
      • 新カテゴリーマネージメントの構築
        • 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環境を用意
  • 実現方法
    • 1branch1環境をどう実現するか
      • 通常の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側(レガシーアプリケーション)との連携では制限がある場合も多い=>その制限の中でいかにより良い環境を実現するかがアーキテクトの腕の見せ所
1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?