Future Tech Blog
フューチャー開発者ブログ

Anthosについて改めて知る(GCPUG Anthos day 参加レポ)

  • 伊藤太斉

はじめに

初めまして、TIG DXユニットの伊藤です。9月にフューチャーに入社しました。前職ではRuby on Railsを使ったWebサイトの開発を行っており、フロントからインフラまで管理をしておりました。現在は日々知識を取り入れながら、GCPの開発支援を担当しております。
プライベートでは、CloudNative Days Tokyo 2019/OpenStack Days Tokyo 2019のボランティアスタッフをやったり、現在も来年に向けたミーティングなどに参加しております。

GCPUG Anthos dayに参加した

2019/10/16(水)に開催されたGCPUG Anthos dayに参加してきました。今年のGoogle Cloud Next ‘19 サンフランシスコで発表されて以来話題にはなっているけど、まだまだ事例も少なくてわからないことが多いAnthosについて知るいい機会になりました。ここでは、Anthos dayで聞いたこと、少し追加で調べたことを書いていきます。

Anthosとは

コンテナ化されたアプリケーションをクラウドとオンプレミスのどちらでも実行可能にするプラットフォームで、コアのサービスはGKEになります。前身はGoogle Service Platformであり、今年のGoogle Cloud NextでAnthosとして正式発表されました。今回のセッション中では「ハイブリッド・マルチクラウド環境で利用できるアプリケーション管理プラットフォーム」と表現されていました。オンプレミス環境や他のクラウドベンダー環境をGCP環境から管理できるサービスです。
通常のGCP環境は従量課金制を取っていましたが、Anthosはライセンス契約となっています。ライセンスに含まれるのは

  • コンテナ管理
  • クラスター管理
  • ポリシー管理
  • サービス管理
  • サーバレス

の5つであり、サーバー自体の管理とVMware製のvSphereについては各々が管理する必要があります。また、ライセンスにはGCP上のみで利用するケースと、オンプレミス上のみで利用するケースの2パターンがあります。
Anthosのコアコンポーネントは以下の5つになります。

  • GKE
  • GKE On-Prem
  • Anthos Config Management
  • Istio on GKE
  • Migrate for Anthos

今回はこの中からピックアップして紹介していきます。

GKE On-Prem

VMware製のvSphere上で動作するGKEです。マネージドなKubernetesをオンプレミス環境などで運用できるため、自前で構築するより簡便にできるメリットがあります。GKE On-Premのアップグレード検証はGoogle側が行い、またCloud Consoleを介してクラウドとオンプレのクラスタを管理できるため、モニタリングやポリシー管理も一括して行えます。

Googleでサポートしている環境

  • vSphere6.5以上
  • F5 BIG-IP
    • 上記以外のロードバランサーを使いたい場合はマニュアルにすればCitrixなどのロードバランサーも使用可能
    • F5以外のロードバランサーはサポート外なのでコンテナをデプロイしたあと、各ノードポートにフォワーディングする必要あり

また、GKEでは対応しているノードプールやクラスターオートスケールには今のところ対応していないようです。

必要なマシンリソース

  • 40 vCPU
  • 100 GB以上のRAM
  • 770 GB以上のディスク

Anthos Config Management

複数のKubernetesクラスタにまたがるポリシー管理を簡単にしてくれる機能です。各クラスターにはConfig Management OperatorというDeploymentがインストールされていて、Gitリポジトリと常に同期しているそのため、差分比較をして、差分が見つかった場合はGitリポジトリを正として各クラスタに対してポリシーを適用してくれます。万が一、人為的にポリシーがクラスターから削除されてもGitを正として再適用されます。

Anthos Service Mesh

Googleが提供するフルマネージドのIstioです。GKEの場合にはマスターはGoogle管理になり、ノードはユーザーが管理する一方でAnthos Service MeshについてはIstioのコントロールプレーン相当についてはGoogleの管理になりますが、サイドカープロキシ(データプレーン)についてはユーザー管理となります。
以下が図示したものになります。

こちらの図では、PodのアプリケーションコンテナとサイドカーコンテナとしてデプロイされているEnvoy Proxy、またIstioのコントロールプレーンを示しています。Pod内にあるサイドカープロキシがIstioのコントロールプレーンと通信していることで、可観測性、トラフィックコントロールが実現します。また可観測性の中にはモニタリングと言っても、サービス間の依存関係や通信状況、サービス間の様々なメトリクスを収集して可視化できるようになります。セキュリティについては各アプリケーションコンテナがサイドカープロキシにlocalhostで接続し、他のアプリケーションコンテナとプロキシを介して通信することで保たれます。

料金形態

これまででも少し触れましたが、GCPは使った分だけ支払う従量課金制を取っている一方で、Anthosはライセンス販売になります。そのため、使用するに当たっては事前にGoogle側への問い合わせなどが必要になってきます。およその料金感はコア数に比例して値段が上がっていくようです。

ユースケース

マルチクラウド利用

  • リージョン障害が発生した時にGCP環境とその他のクラウド環境とのスイッチを行えるようにしておく
    • GCP環境はActive、他環境はStandbyにして有事のときはトラフィックを切り替える
    • 肝になってくるのがDBの同期
      • DB自体のクラスタリングの機能
      • ニアリアルで同期させるツールの使用(Aloomaなど)

オンプレは使いたいがモダナイズされた環境も使いたい

  • セキュリティレベルとして、オンプレにデータを置かなければならない場合
    • 医療系や金融系のデータ
  • オンプレ環境から一部モダナイズさせたい場合

ハマりどころ

バージョンアップ

  • リリースノートに乗らないマイナーアップデートが起こる
    • 突然の挙動が変更されてなおかつ下位互換性がほぼない
    • 現段階の解決策は消してもいいテスト環境を事前に作成しておいてパスしたら本環境のアップデートをすることを勧められていました。また、安定したバージョンになるまで待つことも大事です。
    • ドキュメントは疑ってかかる必要ありだそう。

(特にオンプレに作る場合)初期デザイン

  • 初期から作ると結合デザインで考慮することが多く、設計、検証で潰す必要がある
    • サブネットの切り直しが大変
    • 解決策
      • 現時点で対応できないものを含めて、優先度を決める
      • 可能であれば、vSphereなど専門性が必要だから、コンテナ導入とかと分けて体制を組んだほうが早くできる
      • ベストプラクティスはみんなで共有

まとめ

Anthosは発表されて以来、あまり情報が飛び交っていない(Anthosで調べても4月の記事がとても多い)と思っていましたが、今回料金体系や実際の稼働の仕組みなど調べているだけでは分からない情報が多く聞けました。
ベータ版になっているサービスもいくつかありますが、それらも情報を常に目を光らせながら、GAを待ちましょう!


関連記事: