忙しい人のための【Google Cloud Next ’19 in Tokyo サマリー：Anthos が変えるハイブリッドクラウドの形】

こちらの記事は弊社技術ブログに掲載していた内容となります。一部を除き、投稿当時の情報となりますので、紹介内容の最新情報については別途公式情報等をご参照下さい。

7/31 – 8/1で行われた Google Cloud Next ’19 in Tokyo。
YouTube で動画も続々とアップロードされていますが、動画を観ている時間がない…要約だけ知りたい…
という方向けのセッションサマリーとなります。

ブレイクアウトセッション – 40 分 • D2-3-S01
Anthos が変えるハイブリッドクラウドの形

YouTubeはこちら

Google Cloud ソリューションアーキテクト：長谷部光治

クラウドを利用してお客様のビジネス課題を解決しています。
日本のエンプラはIT変革が求められている

開発手法の変革：80%の会社がアジャイル採用予定
スキルの変革：80%の人材の情報処理能力の改善に取り組まない会社は、2023年まで縮小戦略を取らなければならなくなる。
リソース配分の変革：30％はレガシーシステムの保守で身動きが取れていない。
市場の変化：7割の企業が、デジタル企業が自社の競合となった場合大きな影響を受ける

Anthos＝ハイブリッドマルチクラウドプラットホーム、アプリケーション管理

アジェンダ
1. Anthosが目指すもの
2. Anthosの構成要素、もたらす価値
3. ユースケース
4. まとめ

Anthosが目指すもの

ハイブリッド・マルチクラウド
- 既存リソースの有効利用：オンプレのリソースを有効活用
- レギュレーション、社内ポリシーへの対応：クラウドにおけないものはオンプレに
- コスト、特徴に基づいたクラウドの使い分け
フルマネージド
- 価値のある業務に集中：開発者は開発に、運用者は運用の効率化
- Google によるテスト、監査：パッチ適用、バージョンアップ前の試験など googleがテスト
- 元々のオープンソースに準拠：元々のプロダクトは変えない
- Istio→Istio on GKE
- Knative→Cloud Run
- Kubernates→Google Kubernates Engine
オープンテクノロジー with Google
- オープンソースなきに Google あらず
- 2000を超えるオープンソースプロジェクトへの貢献
オープンソースエコシステム
- Confluent Apache kafka
- data stax APache casandra
- elastic elastic stack
- など…
Next SF19で、データ分析の主要オープンソース企業と戦略的パートナーシップを推し進めることを発表

Anthos

変化の多い時代に、間違いのない選択をするため、最大限の柔軟性と共に提供する
モダン、最先端、競争力があり、使いやすいプラットフォーム

Anthosの構成要素
1. コンテナを基礎としている（kubernatesの上でうごくコンテナがベース）
2. ベアメタルからコンテナまで
3. ベアメタル→仮想マシン→コンテナ（ハード、OS、コンテナランタイム、コンテナ）
コンテナの特徴
1. OSが入っていないのでファイルサイズが小さい
2. アプリケーションに必要なものがまとまってる
3. （仮想マシンに比べ）負荷が低い
なぜGoogleがコンテナを使うのか？
1. 開発速度をあげて新機能をリリースしたい
2. サーバーリソースを有効活用したい（使い切りたい）
3. 開発に集中したい
コンテナオーケストレーションの重要性
1. どのサーバー上に作る？
2. スケジューリング
3. サーバー落ちたら？
4. セルフヒーリング
5. 負荷が高くなったら？
6. オートスケーリング

Google は15年以上のコンテナオーケストレーションの経験がある
Anthos のテクノロジースタック：Anthos control plane

Policy – service – cluster　→　migrate for anthos (beta)→Istio/GKE …

Anthos 提供機能
- コンテナオーケストレーション
- 宣言型APIで実現
- サービスディスカバリ
- セルフヒーリング
- オートスケーリング
- ストレージ連携
宣言型？
- アプリケーションを3つのレプリカで立ち上げ
- 80番ポートで待ち受け
- ステートレスストレージを利用
- 「あるべき状態」を記述し→Kubernates はそれを維持する
オートヒーリング
- kubernetesなら
- コンテナ障害→Kubernatesが検知、修復→対応完了
- プラットフォームで自動化されているので自分で直すことは少なくなる
サービスメッシュとは…
- 設計趣向
- モノリシック：クライアント→ロードバランサ→ECアプリ
- マイクロサービス：クライアント→小さい機能を分けてつくる→ECアプリ

なぜマイクロがいいの？

１つ１つが小さくシンプル
機動的な機能追加
個別集中的なセキュリティ
個別のテクノロジー
しかし、、、
- 連携が増え管理が大変
- サービス間のセキュリティ認証は？認可は？担保できる？
- どう連携してるの？
- どうやって連携するの？

これを解決するのがサービスメッシュ (Istio)

間に入ってサービス間の連携をとりもつ
繋げる
セキュアに保つ
見える化する
設定・ポリシーの一元管理 ~anthos config management~
- マルチ・ハイブリッドクラスタの一元管理
- 宣言型モデルと継続的なモニタリング
- シンプルなマイグレーションネイティブkubernates言語でok
コンテナへのマイグレ migrate for Anthos beta
- リフト＆モダナイズ
- 簡易性、最小限の労力、最小限のダウンタイム
- GUIからの操作でコンテナ化を完了

ユースケース

Anthos on Edges
- エッジロケーションに(工場とか）にanthos (GKE on pre)を導入して集中管理をする
- ＝運用コスト低減
- 簡易な導入= Anthos はインターネットへアクセスできれば導入可能
- デフォルトでモニタリングデフォルトでstackdriverによるモニタリングがされてるので、独自でモニタリング不要
Anthos for hybrid cloud
- 社内ポリシー的にクラウドに置けないアプリケーションをGKE on prem、それ以外はGKEで稼働
- 一貫性を持った開発：社内社外両方で同じ開発手法
柔軟な機能
- オンプレにも置いておける
- anthos for multi-cloud
- コスト、アプリケーションの要件などえクラウドを使い分ける
- 最大限の柔軟性
- 複数のクラウドでDR＝可用性を単体のクラウドのレベルを超えて高めることができるよ