ホーム
お役立ち
Google Service
よりセキュアに！より低コストに！Anthosの概要から検証まで、2020年最新情報を全てお届け

よりセキュアに！より低コストに！Anthosの概要から検証まで、2020年最新情報を全てお届け

Anthos
GKE
Google Cloud Day
ハイブリッドクラウド
マルチクラウド

公開年月日: 2020.06.30

更新年月日: 2024.09.26

よりセキュアに！より低コストに！Anthosの概要から検証まで、2020年最新情報を全てお届け

Googleが開催するイベントのGoogle Cloud Dayでは、Google Cloudの最新ソリューションを学ぶことができます。

今年2020年はCOVID-19の影響もあり、リモートでの開催となりました。この記事では数あるセッションの中から、Anthosに関連する3つのセッションを取り上げ、Anthosの基本事項から最新情報にいたるまでをご紹介します。

この記事でご紹介するセッション

AnthosのLogo
この記事ではGoogle Cloud Dayで公開された下記の3つのセッションを参考に、Anthosの最新情報についてご紹介していきます。

「アプリケーションのモダナイゼーションを支える Anthos をゼロから最新情報まで理解しよう！」
「Anthos によるハイブリッド・マルチクラウドへの移行とクラウドネイティブ化」
「Anthos+GKE On-Prem による DMM サービスへの活用シーンを探る」

Anthosとは

Anthosとは、Google Cloud Platform上で提供されているアプリケーションのモダナイゼーションのためのプラットフォームです。Anthosを導入することによって、GKE(Google Kubernetes Engine)を様々な環境に適用することが可能であり、アプリケーション環境をモダナイズするのに必要な様々な機能を利用することができます。

モダナイゼーションの目的

そもそもアプリケーションのモダナイゼーションには下記のような目的があります。

市場動向やニーズに合わせた迅速なアプリケーションのリリース
ビジネス規模に併せた環境の拡張性

Anthosではこういったアプリケーション環境を実現するために、各サービスのマイクロサービス化やサーバーレス化、自動化を促進する機能を提供しています。

OSSベースのプラットフォーム

Anthosの主要な機能は、OSSをベースとして提供されています。
OSSをベースにしたソフトウェアスタック
サーバーレスではKnative、サービスメッシュではIstio、コンテナオーケストレーションではKubernetesがそれぞれベースとなっており、Google Cloudのマネージドサービスとして提供されます。

Anthosの主要な機能

Anthosの全部のサービス
Anthosではアプリケーションのモダナイゼーションを促進する様々な機能を利用することができます。各機能を理解し、必要な機能を組み合わせて利用することで自身の環境に最適な活用方法を選択することが可能です。

Anthos GKE

Anthos-GKE
Anthosの根幹となっているのはGKE(Google Kubernetes Engine)というコンテナ環境のオーケストレーションツールです。AnthosではGKEに各種機能を組み合わせて利用することができます。GKEは本来GCP上で提供されているものですが、Anthosでは様々な環境で利用可能です。

Anthos GKE on-prem

Anthosでは、オンプレミス環境でGKEを利用することが可能です。VMware vSphere環境上で稼働することができ、通常のGKEと同様にGoogleが検証した最新のKubernetesを利用することができます。

また、レジストリやロギング等のコンテナのエコシステムはGCP上のシステムと連携することができ、適宜クラウド上に機能をオフロードすることが可能です。

Anthos GKE on AWS

マルチクラウド対応の第一歩として、AnthosではAWS上でGKEの提供を開始しました。2020年6月現在はBeta版での提供となっています。

内部的な実装としては、AWSのマネージドKubernetesサービスであるEKSは利用していません。EC2インスタンスをインフラとしてデプロイし、その上にGKEソフトウェアをインストールして提供しています。

GKE Hub

複数の環境でGKEを利用するにあたり、必要となるのが一元的な管理ツールだと思います。GKE Hubはクラウドやオンプレミスのクラスタを統合的にGUIで管理することが可能なツールです。1つの画面上で全ての環境のクラスタを管理することができます。
GKE-Hub
管理用の通信はオンプレミス環境からのアウトバウンド通信のみが発生するため、ファイアウォールなどでインバウンドの通信を有効化しなくても利用することが可能です。また、その通信は暗号化されており、セキュリティ面も考慮されています。

Ingress for Anthos

AnthosではGKEを様々な環境に構築することができます。そのため、距離的に離れた地点に複数のクラスタが分散して配置されることになります。

Ingress for Anthosでは、リージョンをまたいだクラスタ間での負荷分散を実現するサービスです。バックエンドの稼働状況を監視しつつ、最寄りのクラスタにトラフィックを転送してくれます。
リージョンを跨いだ負荷分散
図のように東京と大阪にそれぞれGKEのクラスタが展開されている場合に、Ingress for Anthosを利用すれば同じIPアドレスで各利用者が最寄りのクラスタに接続することができます。また、東京のクラスタが利用できない場合には自動的に大阪のクラスタに接続されるため、可用性を向上させることも可能です。

Anthos Config Management

管理するクラスタの数が増えてくると問題となるのが、ポリシー管理です。ACM(Anthos Config Management)は、複数のクラスタのポリシー管理を効率的に行うことができるサービスです。
ACM:confg syncの仕組み
ACSのConfig Syncという機能では、Name SpaceやQuotaといったクラスタのポリシー変更を複数のクラスタで同期することが可能です。通常、ポリシーは各クラスタ毎に適用する必要がありますが、Config Syncを利用することでGit repositoryを変更するという1回のオペレーションを行うことで、全てのクラスタに設定が自動的に反映されます。

Binary Authorization

エンタープライズ環境でコンテナを利用する際に懸念となるのがセキュリティです。Binary Authorizationではビルドするイメージに脆弱性がないかどうかを判断し、問題がない場合は証明書をメタデータとして追加します。また、イメージをクラスタにデプロイする際にはその証明書が添付されているイメージのみをデプロイするように制限を行うことで、ポリシーに適合したイメージだけがGKEのクラスタに追加が許可されます。

Anthos Service Mesh

Googleが提供する、フルマネージドのサービスメッシュです。サービスメッシュとは、マイクロサービス環境において課題となる可視性やトラッフィクコントロール、セキュリティ等を統合的に管理する考え方です。この分野ではIstioというOSSが非常に有名ですが、ASM(Anthos Service Mesh)はそのIstioのマネージドサービスです。通常のIstioとは異なりコントロールプレーンはユーザーのクラスタから分離され、Googleが管理します。
ASMのアーキテクチャ
サービス間の関係をグラフとして可視化する、Blue/Greenデプロイメントの実現のためにトラフィックコントロールを行う、mTLSベースのサービス認証をするといった、マイクロサービスを管理する上で必要となる機能が提供されています。

Cloud Run for Anthos

Cloud Run for Anthosは、Kubernetesを抽象化することで、コンテナ環境をサーバーレス環境として利用できるサービスです。KnativeというOSSがベースになっています。
言語やライブラリの制約はなく、開発者がKubernetesのコンテナ環境をシンプルに利用することが可能です。

Migrate for Anthos

Migrate_for_Anthos
vSphere環境上で作成された仮想マシンをGKE上のコンテナに移行することができるサービスです。OSやプラットフォームに制約はありますが、手動で行う移行と比較し、コストやリソース、時間を大幅に削減することが可能です。アプリケーションの作り直しや再設計は不要で、モノリシックなアプリケーションを簡単にモダナイズし、最新サービスの導入を迅速にサポートすることができます。

Anthosのリファレンスアーキテクチャ

上記の機能を踏まえた上で、Anthosを実際に活用する際に考えられるアーキテクチャをご紹介します。

ハイブリッド構成

まずはハイブリッド構成です。GCP上の環境とオンプレミス環境を適材適所で使い分けることで各アプリケーションの要件に合致した構成を実現することが可能です。

例えばGCP環境にはスケーリングを柔軟に行う必要のあるアプリケーションを配置し、オンプレミスにはクラウドに移行することのできないデータを持つアプリケーションなどを配置すれば、クラウドの迅速性や拡張性を利用しつつ、セキュリティやコンプライアンスを維持した状態でコンテナ環境を構築することができます。

マルチクラウド構成

マルチクラウド構成
複数のクラウドでKubernetesベースのサービスを利用する場合、各クラウドごとに存在する固有のマネージドKubernetesサービスを利用すると、どうしても運用や管理が煩雑になり、学習コストも増加します。
複数のクラウド上にAnthos GKEを導入することで一元的に複数のクラウド環境を利用することが可能です。

Anthosを利用した既存環境のクラウド化

さて、ここからはオンプレミス環境のレガシーなアプリケーションをクラウド化していく際に、Anthosがどのように様々な課題を解決できるかをご紹介していきます。

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

オンプレミスにあるアプリケーションのモダナイズを実現するために立ちはだかる大きな壁として、Kubernetesをはじめとしたクラウドネイティブ技術を習得することがあります。コンテナ周りの技術は非常に煩雑であり、複数の技術が相互に関連しているためそのスキルの習熟は容易ではありません。
オンプレミス環境でのクラウドネイティブ化
Anthosでは、マスターノード管理はマネージドサービスとして提供されており、運用管理部分をGoogleにオフロードすることが可能です。そのため、開発者はコードの記述により専念することができます。

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

既存のアプリケーションをコンテナ化するには、通常は複雑なプロセスを必要とします。そもそも従来型のワークロードとは性質や考え方が大きく異なります。そのため、物理環境から仮想環境への移行などとは違い、本来は構成そのものをコンテナに最適化されるように変更する必要があります。
コンテナ化をよりシンプルに実現
Anthosでは、Migrate for Anthosという移行機能が提供されています。上述したようにLinuxベースの仮想マシンをGKE上のコンテナとして変換するサービスです。Migrate for Anthosの利用により、コンテナ移行時に必要なファイルの変換やコンテナイメージの作成、YAMLファイルの記述といった処理を自動化することが可能です。

現在はコンテナ化が完全に実現されるわけではなく、アプリケーションの再構築に必要な作業を効率良く処理できるサービスという位置づけではありますが、コンテナ化の第一歩として活用が期待されるサービスであることは間違いありません。

マルチクラスタ管理の統制

Kubernetesでは様々な分解点をクラスタ単位で考慮します。マルチクラウドやハイブリッドなど、複数の環境を利用する場合にはクラスタの数は増大し、その管理や統制が難しくなります。
マルチクラスタ管理の統制
AnthosではACM(Anthos Config Management)を利用することで、共通のポリシーをリポジトリで管理することができ、全てのクラスタにポリシーを自動的に反映させることが可能です。

各クラスタにはAnthos Config Management Operatorがインストールされることで、クラスタ自身が能動的にポリシーを取得し、リポジトリの内容を随時適用します。これにより、マルチクラスタ環境でのポリシー統制が可能となります。

AnthosのGKE on-premを活用したPoC〜事例紹介〜

またDMM社では、自社のオンプレミス環境でAnthosを活用することを想定し、活用のユースケースを考慮するPoCを行いました。ここからはその内容と結果についてご紹介します。

クラウド移行へのハードル

DMM社のオンプレミス環境では、5500以上のVMを複数のDCで利用しています。また、クラウド環境内にも複数のプロバイダにまたがって数百のプロジェクトが点在しています。MWやSW、開発言語等に関しては各事業部毎に任意の製品を利用しており、かなり複雑な環境であることがわかります。
DMMのインフラストラクチャ

上記のような環境をハイブリッドクラウド、マルチクラウドに移行することを考えると、様々な課題が想定されます。

例えばオンプレミス環境とクラウド環境のハイブリッド構成の場合、これまでのハイパーバイザー型の仮想化環境とは異なった運用手法を利用する必要があります。また、複数のクラウドプロバイダーを同時に利用する場合、互換性やそれぞれの学習コストが問題となるでしょう。

そこで、モダナイゼーションの第一歩として候補に上がったのがAnthos GKE on-premです。

Anthos GKE on-premへの期待

Anthos GKE on-premを活用することで、下記のようなクラウド移行に関する課題が解決されることが期待されます。PoCでは下記の6項目を評価指標として設定し、それぞれの項目について確認しています。

容易に構築・運用可能
既存資産の有効活用
Kubernetes Clusterの一元管理
ACMによる一貫性
低コストなCluster管理の実現
既存オンプレミス環境との接続

PoC環境について

PoC環境
まずハードウェアとして、vSphere 6.7のESXiホストを2台とストレージを利用します。また、GKE on-premではExternal/Node/Managementといった3つのネットワークが必要となりますので、3種類のVLANを用意します。

PoC環境（理論）
また、論理構成では、gkeadmコマンドによりAdmin Workstationという管理用のノードをデプロイします。このAdmin WorkstationからAdmin ClusterとUser Clusterがそれぞれデプロイされます。また、ロードバランサーとして仮想アプライアンス版のBIG-IPを用意しています。このVIPの設定はCluster作成時にGKE on-prem側で最適なIPアドレスが自動的に構成されます。

複数環境の一元的な管理

複数環境の一元的な管理
GCPコンソールを見てみると、GCP上のGKEと、オンプレミス上のGKE on-premのそれぞれのクラスターを1つのコンソール上で一元的に管理することが可能です。例えばGKE on-premのシステムログをGCPコンソール上で簡単に確認することもできます。

GKEとGKE on-premの運用範囲における違い

GKE on-premでは、GCP上のGKEとは異なりAdmin Clusterの監視やバックアップなどの運用が必要となります。また、User Cluster上にも通常のGKE User Cluster上では動作していないIstio IngressやCloud RunといったAnthos関連のPODが動作します。そのため、運用の範囲はGCP上でGKEを利用するよりも少し多くなる点に注意が必要です。

環境構築の容易性

環境構築の容易性
アプリケーションのデプロイとしては、通常のGCPと同様にMarketplaceからクリックデプロイします。一部対応していないアプリケーションもありますが、多くのアプリケーションがすでにGKE on-premでも利用可能です。また、Container RegistryのコンテナイメージもGKE on-premクラスタにそのままデプロイすることができます。