はじめに
こんにちは。TIG/DXチームの伊藤です。この技術ブログでGCPネタをよく発信していますが、今回もGCPネタです。好きです、GCP。フューチャーの社内では定期的に勉強会を開催している部門があり、全社的に登壇者を募って発表しています。今回は私自身社内にGCPを広めたいという思いがあり登壇の機会をいただきました。今回はその時のまとめや一部改善した内容になります。また、リモートでの勉強会ということもあり、個人的に気をつけた点も簡単にまとめたので、その辺も参考になればと思います。
話す前の準備
今回は社内で広く利用しているGoogle Meetを使ってオンラインで勉強を行いました。勉強会としても私としてもリモート開催がそもそも初めてなので、質問を受けやすいように区切りのいいとこで質問タイムを設けました。また、オンラインだと反応が見にくいというのがあり、sli.doで質問を募ったり、単純な感想などを随時書いてもらう形式を取りました。その場で答えられなかった質問については後日Appendixという形で展開を考えています。まだまだオンラインで開催するに当たっては改善点もたくさんあるので、広く知識等を身につけていきたいところです。
話したこと
今回話した内容はここからになります。発表時のスライドは以下になりますので、時折記事と照らし合わせながら見てもらえればと思います。一部社内向けにしていたものを社外向けにしたり、不要なスライドは削っている部分はありますが、基本的に同じ内容になります。
今回は大きく4つの内容に分けて話しました。
- GCPとは何か
- AWSとの違い
- ハイブリッド・マルチクラウドで使うときに使えるサービス
- GCPならではのユースケース
今回の勉強会の参加者はオンプレミスの案件であったり、AWSを使っている方が中心だったので、GCPを今の環境に導入する際によりクイックに効くものを中心に盛り込見ました。そのため、各プロダクトやGKE周りの話は今回カットしました（その文脈では最後のユースケースの部分はどちらかというとおまけに近い内容です）。以下では特に説明したかった部分についてかいつまんで書いていきます。
GCPとは
クラウドの利点はおおよそどのベンダーを使っても享受できると思うので、ここでは私が考えるGCPとは、そしてGoogleのネットワークについて説明しました。私自身GCPのプロダクトを見たり使っていてこれだ！と感じているのは、
- Googleがこれまでに培ってきた高品質かつスケーラブルのインフラを誰でも比較的安価に使えること
- Google発信のOSSをマネージドサービスとして利用できること
です。GCPに乗せることでGoogleのネットワークを使えることはかなり大きなメリットではないかと思っています。Googleはネットワークで海底ケーブルなどへの投資も行なっていたり、続々とリージョンを開設しているので、今後もネットワーク周りは強化されていくでしょう。また、KubernetesはもともとGoogleの社内でBorgとして培われた技術で、現在はCNCFにホストされています。これをマネージドとしてGoogle Kubernetes Engine(GKE)として簡単に使うことができることも大きなメリットであり、「GCPだから！」というポイントであると考えています。
AWSとの違い
前職でAWSを使っていたこともあり、AWSとGCPの思想や根本の設計がなんとなく違うことは理解していましたが、これを機会に図示や説明してみました。私がAWSとGCPで異なっていて、これは大きな違いであると感じたのは
- プロジェクトの管理方法
- ネットワーク
の2点です。ここは少し細かめに説明していきます。
プロジェクトの考え方
私は以前、AWSを使っていたこともあり、GCPを使い始めたときに、大きく違うと印象を受けたうちの1つがプロジェクトの考え方です。こちらはGCPの公式ブログから引用したものになります。
AWSはアカウント1つに対してプロジェクトは1つです。AWS Organizationsもリリースされましたが、基本的な考え方は変わらず同じだと思っています。プロジェクトで1つのアカウントとしている場合、開発環境や本番環境のリソースが混在するため、誤操作で本番環境のリソースを謝って削除してしまうなどもオペレーションミスなども発生しているのではないかと思いっています。私はまさにその状態で運用していたため、CLIを使うときにかなり気を揉んでいた覚えがあります。
一方、GCPはアカウント1つに対してプロジェクトを複数作成できます。個人的な開発目的でも単一のアカウントで環境を分離できるため、オペレーションミスの軽減に繋がるかと思います。また、プロジェクトごと削除することができるため、個人でお試しをするときは便利です。
次にアカウントを会社単位で管理するときについてです。最上位に当たるものはOrganization Nodeになります。企業のドメイン(当社であればfuture.co.jpです)をOrganizationの最上位にし、その配下にはフォルダやプロジェクトを設定することができます。フォルダの使いどころとしては、サービスごとに切り分け、各フォルダごとに本番環境、検証環境、開発環境を設定する使い方や、ファイナンシャル部門が請求を見るためのフォルダとプロジェクトを設定してもいいでしょう。プロジェクトは環境ごとにリソースを分離しています。
ネットワークの違い
ここでもAWSとGCPの考え方の違いを感じました。
スライドの図を実際に持ってきました。まとめると以下の表になります。
| VPCの考え方 | VPCとNWレンジ | Subnetの切り出し方 | Subnetの紐づくところ | |
|---|---|---|---|---|
| AWS | 仮想的なNW | 紐づく | VPCから切り出す | ゾーン |
| GCP | あくまで枠 | 紐づかない | それぞれ選べる | リージョン |
GCPを使い始めたとき、VPCの設計がリージョンもまたいで使用できる「枠」という使い方も新鮮でした。ロードバランサもグローバルリソースとして扱えることもあり、サービスを世界展開したいときにはかなり役立つのではないでしょうか？
GCPならではのサービス
最後はGCPが得意とするサービスを少し紹介しました。データ分析にBigQueryを使用するためにAWSとハイブリッドにしているパターンも多いのではないでしょうか？ここではスライドの内容を複合的にまとめて、AWSで分析したいデータをためてGCPで分析できるようにする流れを見てみましょう。ストレージのページで、Transfer Serviceを説明しましたが、組み合わせると以下の図になります。
簡単な図ですが、ログを集積するバケットをAWSに設けて、これをTransfer ServiceでGCSに連携することでBigQueryが読み込むことが可能になります。また、Transfer Service自体はオンプレとも接続ができるため、ハイブリッドクラウド、マルチクラウドで分析基盤として利用ができます。
機械学習についても、Google Lensをはじめとしたサービスに多用されています。私がGoogleと機械学習で印象深い話があり、それはきゅうりをAIで仕分ける話です。この記事ではGCPのサービスを活用して問題解決しているわけではありませんが、Cloud TPUを活用したらより学習効率や精度の向上が見込めると考えました。
まとめ
今回社内で勉強会に登壇する場ををもらい、私自身とても良い機会になりました。GoogleはOSSの発信以外にもエラーバジェットやSREといった、新たな考え方なども提唱しています。私が今回資料を作るにあたり、
- マイクロサービス
- Kubernetesを使うためのネットワーク設計
の2点を感じました。Organizationの設計はマイクロサービス化するためにはとてもフィットしていて、それぞれ分担して機能を担うことも可能にしているのではないかと思いました。また、Zoneをまたいでサブネットを決定できるのもKubernetesを扱う上で無駄なくIPレンジを使用できる設計ではと考えています。この辺は今回資料を作るにあたり、いい気づきになりました。
今回はGCPがAWSに比べていい、みたいな意見が多いと思いますが、ユースケースなど様々だとなので、どちらも良いところはあると思います。