- tech系
忙しい人のための 【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=ハイブリッドマルチクラウドプラットホーム、アプリケーション管理
- アジェンダ
- Anthosが目指すもの
- Anthosの構成要素、もたらす価値
- ユースケース
- まとめ
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の構成要素
- コンテナを基礎としている(kubernatesの上でうごくコンテナがベース)
- ベアメタルからコンテナまで
- ベアメタル→仮想マシン→コンテナ(ハード、OS、コンテナランタイム、コンテナ)
- コンテナの特徴
- OSが入っていないのでファイルサイズが小さい
- アプリケーションに必要なものがまとまってる
- (仮想マシンに比べ)負荷が低い
- なぜGoogleがコンテナを使うのか?
- 開発速度をあげて新機能をリリースしたい
- サーバーリソースを有効活用したい(使い切りたい)
- 開発に集中したい
- コンテナオーケストレーションの重要性
- どのサーバー上に作る?
- スケジューリング
- サーバー落ちたら?
- セルフヒーリング
- 負荷が高くなったら?
- オートスケーリング
Google は15年以上のコンテナオーケストレーションの経験がある
Anthos のテクノロジースタック:Anthos control plane
Policy – service – cluster → migrate for anthos (beta)→Istio/GKE …
- Anthos 提供機能
- コンテナオーケストレーション
- 宣言型APIで実現
- サービスディスカバリ
- セルフヒーリング
- オートスケーリング
- ストレージ連携
- 宣言型?
- アプリケーションを3つのレプリカで立ち上げ
- 80番ポートで待ち受け
- ステートレスストレージを利用
- 「あるべき状態」を記述し→Kubernates はそれを維持する
- オートヒーリング
- kubernetesなら
- コンテナ障害→Kubernatesが検知、修復→対応完了
- プラットフォームで自動化されているので自分で直すことは少なくなる
- サービスメッシュとは…
- 設計趣向
- モノリシック:クライアント→ロードバランサ→ECアプリ
- マイクロサービス:クライアント→小さい機能を分けてつくる→ECアプリ
なぜマイクロがいいの?
- 1つ1つが小さくシンプル
- 機動的な機能追加
- 個別集中的なセキュリティ
- 個別のテクノロジー
- しかし、、、
- 連携が増え管理が大変
- サービス間のセキュリティ認証は?認可は?担保できる?
- どう連携してるの?
- どうやって連携するの?
これを解決するのがサービスメッシュ (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=可用性を単体のクラウドのレベルを超えて高めることができるよ
まとめ
Anthos は 「The future of cloud」 に対する Google の答えです。
この記事を共有する