Anthos による

ハイブリッド・マルチクラウドへの

移行とクラウドネイティブ化

玉邑　考史

株式会社オージス総研

クラウド基盤ソリューション部

エンタープライズ領域での

クラウドネイティブ化への挑戦に

取り組んでいます。

1. クラウドネイティブ化とは

2. オージス総研の目指すクラウドネイティブ化

3. クラウドネイティブ化の課題

4. Anthos での課題検証

○ オンプレミス環境のクラウド化

○ コンテナ化をよりシンプルに

○ マルチクラスタ管理における統制

5. まとめ

クラウドネイティブ化とは 01

Public

On-prem

Classic apps & operations Cloudnative apps & operations

Lift & Shiftworkloads

Lift & Optimizeworkloads

Modernize workloadin Cloud

Modernize workloadin Place

リフト＆シフト、モダナイズ

Public

On-prem

Classic apps & operations Cloudnative apps & operations

Lift & Shiftworkloads

Lift & Optimizeworkloads

Modernize workloadin Cloud

Modernize workloadin Place

リフト＆シフト、モダナイズ

リフト＆シフト

Next Step

ハイブリッドクラウドとマルチクラウドを実現する

クラウドネイティブ

ハイブリッドクラウドとマルチクラウド

クラウドネイティブはこれらを実現するため

の最も有力な選択肢です。

オープンソース・ベンダー中立

具体的な技術の例● コンテナ● サービスメッシュ● マイクロサービス● イミュータブルインフラストラクチャ● 宣言型API

モダンでダイナミックな環境　パブリッククラウド / プライベートクラウド / ハイブリッドクラウド

目的● スケーラブルなアプリケーションを構築および実行するため● インパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うため

システムの特長● 疎結合● 回復性● 管理力● 可観測性● 堅牢な自動化

クラウドネイティブとは

出典：CNCF Cloud Native Definition v1.0 ( https://github.com/cncf/toc/blob/master/DEFINITION.md )

クラウドネイティブを実現することは容易か？

いいえ、とても大変な取り組みです。

まったく新しい技術で、まったく新しい特長を持っ

た、まったく新しいITシステムを、OSS とベンダー

中立の考え方で直ちに実現することは困難で

す。

なぜ困難なのか？

OSS でベンダー中立なことは、逆に言えば全て自分

たちで行うことを意味します。

クラウドネイティブなOSS を使いこなし、必要な機能が

あれば開発し、OSS に貢献していくことは理想です

が、すぐにそこには到達できません。

エンタープライズ領域に求められる要件とは

特にエンタープライズ領域において下記は非常

に重要な要件です。

● 既存IT資産の活用

● 安定したサポート

● 運用負荷の軽減

クラウドネイティブ技術を

ベンダー製品で管理する

OSS をベースとしたクラウドネイティブなベンダー製品を

利用することも可能です。

エンタープライズレベルのサポートが提供されますが、

運用は全てユーザー側で実施する必要があります。

クラウドネイティブ技術を

パブリッククラウドで管理する

パブリッククラウドが提供するクラウドネイティブ

サービスは充実してきました。

クラウドネイティブの特長をパブリッククラウドで

マネージドに利用でき、ユーザーの運用負荷を軽

減することができます。

エンタープライズ領域で

クラウドネイティブを実現する手段

　全て自分たちで行う

● クラウドネイティブなOSSを選択

することで、ロックインを回避す

る。

● 必要な機能がある場合、問題

が発生した場合、自分たちで

OSSを改修し、同時にOSSに

貢献する。

● 理想だが、技術者の確保をは

じめすぐにそれを実現すること

は困難である。

ベンダー製品を利用する

● クラウドネイティブな製品を選択

することで、ロックインを回避す

る。

● エンタープライズレベルのサ

ポートを受けることができる。

● 運用はユーザー側で行う必要

がある。

パブリッククラウドを利用する

● クラウドネイティブなサービスを

選択することで、ロックインを回

避する。

● エンタープライズレベルのサポー

トを受けることができる。

● マネージドサービスを活用するこ

とで、運用負荷を軽減する。

オージス総研が目指す

クラウドネイティブ化 02

ハイブリッドクラウドの実現

既存IT資産の価値を最大化しながら、共存させることを

前提に、徐々に適切な場所へワークロードを移行したい

Hybridcloud

On-premiseGoogle Cloud

マルチクラウドの実現

各社の特徴がでてきており、ユーザーとして適材適所で

利用する傾向が強くなってきた

Multi cloud

AWS Google Cloud Azure

これまでとの違い

標準システムを決めて、ガバナンス統制を行う

ハイブリッド・マルチクラウドを前提として考える

構成、運用や手間をどのように最適化できるか？

Proprietary + Confidential

クラウドネイティブ化の課題 03

クラウドネイティブ化の取り組みの中で

見えてきた課題

オンプレミス環境のクラウドネイティブ化1コンテナ化をよりシンプルに2マルチクラスタ管理の必要性3

Public

On-prem

Classic apps & operations Cloudnative apps & operations

Lift & Shiftworkloads

Lift & Optimizeworkloads

Modernize workloadin Cloud

Modernize workloadin Place

クラウドネイティブ化の課題

オンプレミス環境のクラウドネイティブ化

1コンテナ化をよりシンプルに

2マルチクラスタ管理の必要性

3

出典：Anthos technical overview | Google Cloud ( https://cloud.google.com/anthos/docs/concepts/overview )

Anthosとは

Google Cloud の

クラウドネイティブ

ソリューションの総称

Anthos を選んだ理由

1. パブリッククラウドベンダーでありながらマルチ

クラウドへの対応を行っている

2. クラウドネイティブ技術を全レイヤーで、マネー

ジドサービスとして提供している。

3. コンテナマイグレーション等、他にはないソ

リューションも提供している。

Anthos での課題検証 04

オンプレミス環境のクラウドネイティブ化

課題 1

オンプレミス環境のクラウドネイティブ化

市場の自由化・コア事業での競争力・スピード感

　高速な開発、アジャイル開発へ適用できるインフラストラクチャ

新しいワークロードへの適応

　ビッグデータ分析、機械学習（AI）、IoT など

オンプレミス環境のクラウドネイティブ化

課題と Anthos に期待すること

　課題

● Kubernetes をはじめとするクラ

ウドネイティブ技術の学習コス

ト、エンジニアの育成

● オンプレミス環境に残るワーク

ロードの管理

　Anthos に期待すること

● マネージドによる運用負荷の軽

減

● オンプレミス環境とのハイブリッ

ド管理

Anthos GKE on-prem

GKE (Google Kubernetes Engine) が

オンプレミス環境にて提供されます。

● Kubernetes インストール

● マスターノード管理

● クラスタ・サービス管理

● ログ管理

Admin Workstation　インストールやクラスタ操作を行う　Google Cloud アプライアンス Linux　・gkectl　・kubectl　・gcloud

UserClusterWorker実際のワークロードが稼働

UserClusterMaster　GKE の Master node

AdminClusterMaster　vSphere と連動するための Kubernetes　 Master node　 Worker node

主要コンポーネント

出典：Anthos GKE on-prem overview | Google Cloud ( https://cloud.google.com/anthos/gke/docs/on-prem/overview )

宣言的に設定し、検証済み環境を展開

1. AdminWorkstation を OVA と Terraform によりインストール

2. gcloud でのサービスアカウントとの紐づけ

3. gkectl によるコンポーネントの展開

Kubernetes インストール

YAML

通信要件

GCP からの管理通信は Internet に対して

アウトバウンド通信のみ（NAT 不要）

※ただし、GitOps における通信や、サービス提供で

　インターネットを利用する場合には NAT が必要

F5 BIG-IP 等のLoad Balancer

● gke-mgmt : kubectl や gkectl で利用される管理通信セグメント

● gke-internal : クラスタ用ネットワーク

● gke-external : サービス用ネットワーク

出典：Installing F5 BIG-IP ADC for Anthos GKE on-prem using manual load balancing | Google Cloud ( https://cloud.google.com/solutions/partners/installing-f5-big-ip-adc-for-gke-on-prem-using-manual-load-balancing )

結果 1: オンプレミス環境のクラウドネイティブ化

　Anthos に期待すること

● マネージドによる運用負荷の

軽減

● オンプレミス環境とのハイブ

リッド管理

　Anthos によって得られた価値

● 複雑なマスターノード管理をマネージドで提供

することによる運用負荷軽減

● 検証済みの自動インストールを提供 (

Kubernetes アップデート対応負荷軽減 ）

● Google Cloud コンソールでのハイブリッドクラ

スタ管理・ログ管理

● F5 Container Ingress Service により YAMLに

よる Service 設定が可能

コンテナ化をよりシンプルに

課題 2

2. コンテナ化をよりシンプルに

増え続けるワークロードの自動化

　クラウドネイティブへの適用にはコンテナ化が必須

コンテナ化に伴う環境整備の必要性

　Infrastructure as Code の管理、CI/CD の整備

2. コンテナ化をよりシンプルに

課題と Anthos に期待すること

　課題

● 異なる性質を持つ VM とコンテ

ナの変換

● 必要となる周辺環境の整備

　Anthos に期待すること

● よりシンプルにコンテナ化という

選択肢をもちたい

● IaC 管理、CI/CD ができるサー

ビスの提供

コンテナ化の難しさ

コンテナは本質的に既存のワークロード（VMware VM や GCE）とは性

質が異なります。

● イミュータブル

● ステートレス

Migrate for Anthos

Linux ワークロードをコンテナへ変換するソ

リューションです。

● Compute Engine

● VMware vSphere

● Amazon EC2

● Azure

機能の説明( < v1.2)

厳密には Linux の永続領域を Persistent Volume で

マウントした Stateful なコンテナに変換する

サービスです。

※利用されるコンテナイメージは移行専用

Migration の手順

1. MarketPlace で Migrate for Anthos を有効化

2. 移行元 GCE を停止し、移行用コマンドを実行

3. 生成された YAML を実行

4. Persistent Volume を " / " にマウントした Pod が起動

Migration の仕組み（GCE → GKE ）

Migration の仕組み ( GCE → GKE )

● initContainer1:○ サービス停止・ネットワーク設定変更・ファイルシステム変換・デーモンの切替

● initContainer2: ○ GCE 環境の事前処理を実施

● Pod: ○ StorageClass の作成など

弊社事例

LAMP で構成された開発サーバ（RHEL6）の複製で利用

1. VMを仮想ディスク（vmdk ファイル）のインポートで

GCEへ変換

2. 変換した GCE を Migrate for Anthos で GKE へ移行

3. 移行したデータを別途作成したコンテナで利用

→　一時的な用途での利用 ( 現時点では機能検証として利用 )

● コンテナイメージの作成

● Docker ファイルの作成

migctl による全く新しい機能の実現

ただし、そのまま利用するという

用途ではなく、移行計画とテスト

を繰り返して移行することが推奨

されている。

v1.3 でできるようになったこと

出典：Your migration journey to GKE | Google Cloud ( https://cloud.google.com/migrate/anthos/docs/migration-journey )

結果 2: コンテナ化をよりシンプルに

　Anthos に期待すること

● よりシンプルにコンテナ化と

いう選択肢をもちたい

● IaC 管理、CI/CD ができる

サービスの提供

　Anthos によって得られた価値

● コンテナ化をシンプルに実現するとまで

はいかず、再構築は必要

● モダナイゼーションの中間地点という位

置づけであり、移行ノウハウの蓄積が必

要

● Cloud Build, Container Registry, Cloud

Source Repositories との親和性が高い

マルチクラスタ管理における統制

課題 3

3. マルチクラスタ管理における統制

Kubernetes のセキュリティ統制の必要性

　クラスタ、ノード、ネームスペースなどセキュリティ分解点を

　意識した設定や管理が必要

Kubernetes クラスタはマルチクラスタに展開される

　Kubernetes のセキュリティを考慮した際に、クラスタを分ける

　という選択肢への対応が必要

3. マルチクラスタ管理における統制

課題と Anthos に期待すること

　課題

● 様々な環境での Kubernetes

クラスタが増える可能性が

あり、セキュリティ上の懸念があ

る

　Anthos に期待すること

● マルチクラスタにおけるセキュリ

ティ統制

Anthos Config Management

Kubernetes における共通ポリシーをリポジトリで管理し、各クラ

スタが能動的に取得し適用できます。

● マルチクラスタでの設定統一

○ ネットワークポリシー

○ 権限管理 など

● kubectl の利用制限等

Repo

Anthos Config Management

各 Kubernetes クラスタ内で

Anthos Config Management の

Operator が稼働し、リポジトリの

内容を随時クラスタへ反映します。

Anthos Config ManagementOperator

出典：Anthos technical overview | Google Cloud ( https://cloud.google.com/anthos/docs/concepts/overview )

kubernetes API

Anthos Config Management

本番環境での Kubernetes API の制限等にも利用できます。

（FluxCD と同じ考え方）

ConfigManagement Operetor

Repo

ContainerImages

Policy Controller

gatekeeper(https://github.com/open-policy-agent/gatekeeper)

操作自体の禁止などを設定でき、より厳しい監査統制に利用可能

ACM インストール時に有効にすると、Operator を同時展開

ライブラリからサンプルをベースにして設定可能

(https://github.com/open-policy-agent/gatekeeper/tree/master/library)

結果３：マルチクラスタ管理における統制

　Anthos に期待すること

● マルチクラスタにおけるセ

キュリティ統制

　Anthos によって得られた価値

● マルチクラスタのセキュリティ品質の統一

が可能

● 設定反映のタイムラグを考慮する必要が

あるため、監査要件等では Policy

Controller の利用が必要

● 現時点ではマルチクラウド対応していな

いため、今後の対応を期待したい

まとめ 05

● ドキュメントは英語のものを利用することを推奨します

● Professional Service を活用することで、ドキュメントに関するより踏み込ん

だ確認などが行えます。

○ Professional Service : Google Cloud のコンサルティングサービス

● インストール前の事前準備はしっかりと（特にオンプレミス側の通信要件に注

意）

● 必要リソースに注意（最小構成でも 8 つの Kubernetes 用 VM とAdminWorkstation、F5 のリソース等が必要）

Tips

● ハードウェアの可用性等の責任はユーザー側でもつ必要があります

（vSphere HA / DRS の利用検討）

● 仮想ディスクのインポートの前提条件

○ Python のマイナーバージョン最新化が必要○ 事前移行チェックのために golang と git が必要○ 上記のとおり現行環境を変更するため別 VM として V2V して準備

● Migrate for Anthos は起動したコンテナイメージは " / “ で元のデータをマウン

トしているものの、別イメージで立ち上がるため元の kernel ではありません

Tips

クラウドネイティブ化の課題に対する評価

オンプレミス環境のクラウドネイティブ化 〇1● 運用負荷の軽減

○ Master node のマネージド化○ k8s アップデートの検証不要

● マルチクラウド環境の一元管理○ クラスタ管理（GKE コンソール）○ ログ管理(Operations Logging)

● パートナー製品との Integration○ F5 ロードバランサーを k8s の Service として設定可能

クラウドネイティブ化の課題に対する評価

コンテナ化をよりシンプルに

マルチクラスタ管理の必要性

2

3 〇

△● Cloud Build や Container Registry 等、GCP の CI/CD サービス群と

の高い親和性● 現時点ではモダナイゼーションの中間点として活用

● Anthos Config Management によってマルチクラスタのセキュリティ品質を統一

● 各サービスをプラガブルに組み合わせて利用できる提供方式を期待したい。

● コンテナ化については他にはないソリューションであり、今後よりシームレス

に移行できるようになることを期待したい。

● Anthos GKE On-prem だけでなく、Anthos の提供機能全てがマルチクラウ

ドに展開されることを期待したい。

○ Anthos Config Management など Operator 等の提供○ Google Cloud Armor などのセキュリティサービスの展開

今後の Anthos に対する期待

Google Cloud の構築相談は オージス総研まで

We’re hiring !　エンタープライズ領域でのクラウドネイティブ化への挑戦

　私たちと一緒に取り組んでくれる仲間を募集しています

セッションアンケートへのご回答を

ぜひお願いいたします。

デスクトップでご覧の場合：

セッション配信ページの画面の右側に表示されているアン

ケート フォームよりご回答をお願いいたします。

スマートフォンでご覧の場合：

セッション配信ページの画面トップに表示されているアン

ケート フォームよりご回答をお願いいたします。

セッション アンケート

Thank you.