BETA

Google Cloud Kubernetes Day 2019レポないしはメモ

投稿日:2019-09-10
最終更新:2019-09-10

失敗しないアプリケーションモダナイゼーションの考え方

モダナイナイゼーション

・クラウドの利用
・クラウドネイティブ
・マイクロサービス
・twelve-factor app

twelve factor app

セットアップの自動化や実行環境間の移植性を最大化する考え方。
モダンなクラウドプラットフォームへのデプロイに適する。
(Herokuの人が提唱、日本語訳:https://12factor.net/ja/)

クラウドネイティブ

クラウドを使ってスケーラブルなアプリケーションの構築
・コンテナ、サービスメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、宣言型API
→ 回復性、管理力、可観測性のある疎結合システムが実現
自動化と組み合わせてインパクトある変更を最小限の労力で行う

アプリケーションのモダナイゼーション

リホスト
・オンプレをクラウドのVMに移し替え
リプラットフォーム
・一部クラウドサービス化(IaaSやオブジェクトストレージなど)
リファクタリング
・マイクロサービスやコンテナネイティブなど
・マイクロサービスのデモアプリケーション:Microservice demo gituhb/GoogleCloudPlatform/microservices-demo

アーキテクチャ・DevOpsの導入事例について

富士フィルム

OMS(Order Management System)の課題

・イベント等へのスケーラビリティ確保
・モノシリックアプリの課題
 ・アプリケーションの全体像を把握しない改修できなかった
  → 学習コストの改善、機能改善スピードの向上

アーキテクチャ

・マイクロサービス(Docker,k8s)
 ・マネージドのk8sサービスで学習・構築・運用コスト削減
  → 当時マネージドk8sはGCPのみだったのでGCPを採用
・移行方法の検討で3ヶ月、開発に3ヶ月

スケーラビリティ確保

・他国への展開も容易
・保守運用コストは減った

フリークアウト

全てのアプリケーションはGKEで稼働
リソースはdeploymentが10個ほど
ログはfluentdからbigquery
circleciで継続テスト→cloud buildで継続インテグレーション
構成変更はDeveloperとSRE問わず相互レビューで実施

コンテナとサーバレスどっちが向いているか、なぜこのアーキテクチャにしたか?
・広告のシステムなので高速性が大事
・サーバレスでもいいけどアプリケーションが10個ほどあり、それらが協調して動作するので複雑化するのがわかっていた→GKEで全体を自分たちで作業できた方が良いと判断した
・デプロイ通知などのイベント通知はクラウドサービスを便利に使っており、組み合わせて利用している

チーム・体制について

富士フィルム

体制

開発、運用設計・構築、QA、技術支援の4チーム

課題と対策

  1. 周りの理解を得る
  2. 知識・実績がない
  3. 失敗リスクの影響範囲の最小化
    • 技術学習、解説資料作成と説明行客、スモールスタート(小規模PJ)、googleのカスタマーサポート技術者の支援体制
  4. 連帯感の重要性 開発メンバ、インフラエンジニア、部門横断のエンジニアの認識合わせ、技術習得の連携強化が必要
  5. サービス分割 分割しすぎると制御、障害対応が難しいのでバランスが大事。データ構造の設計も必要

DevOpsエンジニアが1名おり、DevOps側はその人が面倒を見るものと思っていた
→ DevOpsまで行き着いていない。今後考えていく

フリークアウト

体制

Developerが11名、SREが2名、Product Manager(製品設計)が2名
大規模なインフラ構成変更はSRE中心
・k8s update, Cloud Composer導入
・Terraform導入は検討中
スタートアップはどのくらいから始めたか
→ インフラは一名、エンジニアが数名くらいから

これからモダナイゼーションしようとしている企業に向けて

富士フィルム

クラウドネイティブを前提とした考え方、設計に進めた方が良い
コンテナやオーケストレーション、サーバレス等の技術スタックは出てきている
サービスの利用を適材適所、バランスよく
スモールスタートおすすめ、ゼロベースで開始だと不安もあると思われる

フリークアウト

サービス開発当時は事例も多くなかった
この数年で事例も公開されるようになり、各社アーキテクチャの紹介も行っている。これらをキャッチアップしながら考えていくと良い
GKEは優れたプロダクトだと考えている。StackDriverの統合など

DevOpsについて

ソフトウェアの重要性がましている(ソフトウェアが世界を飲み込む)
→ DevOpsでアイディアをマーケットに素早く持ち込む
→ 持ち込み方の最適化

DevOpsの重要性

1.53倍の目標を達成できる

k8s登場による変化

DevOpsの考え方はk8s以前からあった。
従来はソフトエンジニアがソースを書いてインフラエンジニアがOS/MWを作り、VMができて投入できた、それをオペレータが運用していた。
オペレータが運用フェーズの改善を考えても、ソフトウェアエンジニア、インフラエンジニアに作業を依頼しないと完了できなかった。
・例としてログサーバを変えるとすると、インフラエンジニアにOSのログエージェントの設定を変えてもらったり、ソフトウェアエンジニアにアプリの設定を変えてもらったりが必要
k8sを導入すると、アプリのコンテナとログエージェントのコンテナを分離できる→ソフトウェアエンジニアとインフラエンジニアを分離できる。ログを受け取るコンテナを変えてもエンドポイントのIP(ClusterIP)の変更で済む
従来方法でもDNSやLBでもできた。色々なコンポーネントの組み合わせが必要だったが、k8sの中で全てが完結する。 → DevOpsがやりやすくなる

DevOpsをする際の問題

開発と運用のインセンティブが一致しない
・開発は早く投入したいが、運用は安定性を重視したい
よくある問題としてダウンタイムなしとか99.9999999999...%の稼働率とか、合理的でない安定性が定義される
→ カスタマー・エンドユーザの潜在的に要求する安定を定義し計測、また経営層など決定権のある人からのサポートをえて組織・チーム間の壁を取り払う

安定性の定義

99.9%と99%で迷ったら差分をうまく説明できるか考えることが必要
コーセラにレクチャーあるよ(まじか

安定性の計測

稼働時間/全時間が人間にとって直感的
アップタイムみたいなサービスを使うと簡単に測れる
マイクロサービスの場合計測方法は考える必要
・リクエストが来ていないマイクロサービスはダウンしているのか
・三つ中一つのマイクロサービスがダウンしている場合、それはサービスダウンなのか

Opsに求められること

安定性の最適化
安定性=MTBF/(MTBF+MTTR)*Impact 
MTTR=Time to Detect+Time to Medicate

改善の方向性

Impactの改善:システムの作り方やプログラミングを変えてシステムの影響を小さくする、システムの変更時に障害が出やすいのでその辺考えて行う

まとめ

・ソフトウェアがビジネスの中心になり、以前にも増してDevOpsの重要性が増す
・k8sの登場で技術的にDevOpsがやりやすくなった
・Opsには安定性の最適化が求められ、以前にも増して重要性が増す

Anthosで実現するモダンなアプリケーション管理プラットフォーム

2025年の壁

IT予算のうち9割を維持管理で占める
・人材不足
・データの増加
・技術的負債の増加
 ・特に日本固有の事情として、事業部門ごとのシステム、過剰なカスタマイズによる複雑化、ブラックボックス化がある
対策として使わないシステムは廃棄・塩漬け、使うシステムはモダナイゼーションを進める。
既存のシステムはそれで良いとして、これから作るものはどうする?これからの開発はどうあるべきか?
→ Agility(敏捷性)、Flexibility(柔軟性)、Maintainability(保守性)の要素を満たす必要がある。
→ 新しい考え方使ってモダンなアプリ開発を。コンテナやサービスメッシュ、DevOps等

コンテナベースでの開発が多く、オーケストレーション環境のデファクトスタンダートとしてk8sがある。
k8s導入の壁として、以下があげられる。
・どこで動かすか
・運用が大変
・複数環境をどう扱う?
・足りない機能は?
→ 自社のエンジニアリング力で突破できれば良い。できる技術があるなら。

この発表者(Google CloudのAnthos関係者)による上記の対策
・どこで動かすか?
 → オンプレ+クラウド
・運用が大変
 → 自社でk8s専門家を育てる
・複数環境をどう扱う?
 → 各種OSSを組み合わせて各環境を自社で運用
・足りない機能は?
 → クラウド利用やら自社開発で補う
当たり前だが、これらの対策は全員ができるわけではない。
→ Anthosでどうにかしましょう。Anthos+GCPでProduction Readyのk8sを実現しましょう
・ハイブリッド+マルチクラウド
・マネージドGKE+a
・マネージドの管理機能で複数環境の一元管理
・GCPの各種サービス
Anthosの機能
・クラスター管理
・ポリシー管理
・サービス管理

GKE-Onprem
・DCのVMware上で直ちに稼働するプロダクショングレードk8s
・コンテナのビルドはCloudBuild、監視などはGCP使ってもらうことになる

論理構成
・adminclusterとuser cluster
・adminclusterがvcenterのAPIを叩く
・user clusterにユーザのコンテナが展開される
・admin workstation:環境を制御するためのコマンドラインが入った環境
LBとしてF5必須

ユーザから見たAnthos GKE On-Premの利用について

使う前に

  1. アップデート情報に常にアンテナを貼る
  2. 組織的に学習する
    etc.

managed k8sサービスに求めるもの

  1. k8sのアップデートをサポートしていること
  2. 周辺ツールでのサポート・統合のケイパビリティ
  3. ネットワーク/ストレージとの統合

アップデートの煩雑さやインストールの難しさから、managed k8sがベスト
GKE-OnPremもこれからアップデートされていくので情報を集める必要

GCPで実現するCI/CD最前線

最新レポート from DORA
・EliteGroupはコードのデプロイが早かったりコミットからデプロイまで早くて失敗が少なくてインシデントからの普及が早い
CDF(Container Delivery foundation):ベンダーニュートラルな拠点を提供
・Jenkins、JenkinsX、Tekton、Spinnaker
CI/CDに求められるもの

  • オープン
  • ポータビリティ
  • ハイブリッド/マルチクラウド連携
  • Kubernetes連携

高速なローカル開発ループ
CloudBuild

  • CI/CDツール
  • CloudBuildersなるビルド用イメージも提供中

Spinnaker

  • CDツール
  • 最近GCPと統合されたサービスが出た

Container Registoryの脆弱性スキャン

  • CI/CDでデプロイするだけでなく、脆弱性を含まないかスキャンする
  • GCPのコンテナレジストリサービスの機能

CloudBuild Artifacts

  • パッケージリポジトリサービス
  • Mavenとnpmをサポート
  • IAMやCLIとの統合、UIの提供

Binary Authorization

  • 署名されたコンテナのみがデプロイされる
  • GKE APIの全てのデプロイを検証
  • 信頼できるパイプラインでビルドされ、セキュリティ検査などに合格したことが保証される
  • ドライランの機能がある。ポリシーを実際の環境に適用した時、ブロックされそうなデプロイをロギングする
  • システムコンテナポリシー:k8sシステム用のコンテナを勝手に更新できなくする
  • KMSの非対称鍵でコンテナに署名、検証ができるようになる

Tekton

  • 組み立て可能?
  • yamlで宣言的にCI/CDパイプラインを構築できる。再現可能でクラウドネイティブ。

CI/CD developer hub

  • GCPのCI/CD関係のドキュメントが集まっている
  • 利用事例とかサービスのアップデートとか

kubemciを用いたカナリアリリース?楽天アドテク事業におけるGKE導入事例・広告配信システムのグローバル事例?

事前の資料だとkubemci~だったが、実際の発表では楽天アドテクのタイトルで発表された。内容が同一でタイトルだけ変わったとかのアナウンスはなかったので、当初の内容であるかは不明

GKEクラスタの安定運用の課題
・クラスタのメジャーバージョンアップを慎重に行いたい
・クラスタに新しいソフトウェアを慎重に組み込みたい
・クラスタの設定や構成を柔軟に変更したい
・不具合発生時にクラスタのバージョンを戻したい
→ GKEのマルチクラスタ構成を用いて解決を試みた

マルチクラスタ構築の方法
→ kubemci使う
ingressをデプロイした際に複数のGKEクラスタにまたがる通信ができるようGCLBなどをセットアップ

カナリヤリリースの例
・事前に片側で全ての通信をさばききれるようにスケールアップ等を実施
・片側へのトラフィックを止める
・GKEのバージョンをあげる
・GCLBのレートを10%に変更(→ カナリアリリース)

クラスタを切り離して再構築の例
・事前に片側で全ての通信をさばききれるようにスケールアップ等を実施
・片側止める
・片側のクラスタ消して再構築
・もう片方も同様に再構築し、LBの設定を元に戻す

北米・ヨーロッパ・アジアにおけるグローバルでのモニタリングの事例

Prometheusを使用、k8sとの親和性も高い

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@s7LRiAjJC0T8mtuJの技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる
技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
or 外部アカウントではじめる
10秒で技術ブログが作れます!