Google Cloud (GCP)の環境構築に向けたベストプラクティスとは?効率的な方法を実画面を交えて徹底解説!
- Cloud
- Kubernetes
- クラウド環境
- 環境構築
本記事は、2021年9月14日に開催された Google の公式イベント「オープンクラウドサミット」において、 Google Cloud のアプリケーションモダナイゼーションスペシャリストである頼兼孝幸氏が講演された「クラウドを利用したいだけなのに組織を1から構築しないといけない、それが問題だ〜 Google Cloud 環境構築のベストプラクティスを採用〜」のレポート記事となります。
今回は Google Cloud (GCP)の環境構築に向けたベストプラクティスを具体的かつわかりやすくご説明します。実画面を使ったデモもご紹介していますので、 Google Cloud (GCP)の環境構築を検討している方は、ぜひ最後までご覧ください。
なお、本記事内で使用している画像に関しては、オープンクラウドサミット「クラウドを利用したいだけなのに組織を1から構築しないといけない、それが問題だ〜 Google Cloud 環境構築のベストプラクティスを採用〜」を出典元として参照しております。
それでは、早速内容を見ていきましょう。
目次
初期設計の重要性について
何かを始めるときは「どう設計すべきか」を最初に調べます。初期設計を間違えると後で直すのが大変になり、余計な工数が発生するためです。
よくある例としては、情報を検索して公式ドキュメントや他社事例を照らし合わせたり、資料だけで分からない場合は過去イベントの動画を見ることもあるでしょう。これらは正しい方法ですが、すべてを実施するためには多大な時間が必要になり、最終的には調査した内容をチームや事業部に共有しなければなりません。
ここで、 Google Cloud (GCP)を利用開始するまでのプロセスを考えてみましょう。下図の通り、組織生成や組織ポリシーの策定、グループ作成、ユーザーのアカウント発行、権限付与、ネットワーク構成など、基本的な内容だけでも多くの作業が発生します。
また、設計方針が固まった後は、それをどう構築・管理していくのかを考える必要があります。 Google Cloud (GCP)の環境を構築する方法は一つではなく、複数の選択肢があります。
一つ目としては Google Cloud (GCP)のコンソールの GUI 操作で構築する方法が挙げられます。しかし、この方法は属人的になる傾向があり、変更履歴が残らないため、他のメンバーが流用するのは困難です。
二つ目としては gcloud コマンドを必要なだけ実行する方法が挙げられますが、この方法はパラメータが羅列されるため可視性が悪くなります。また、 state 管理ができない点も大きなデメリットです。
そこで三つ目の方法として考えられるのが、リソースをコードで適用する方法です。これには2パターンの手法が存在しており、 Infrastructure as Code と Configuration as Data が挙げられます。
Infrastructure as Code は「何を構築していくのか」を定義しながら進める手法であり、一般的には「命令型」と呼ばれています。一方、 Configuration as Data は「どうあるべきなのか」を定義しながら進める手法であり、一般的には「宣言型」と呼ばれています。今回は後者の Configuration as Data について詳しく解説します。
Configuration as Data は、インフラやアプリの望ましい状態を「データ」として定義し、デプロイ・管理を行なっていく宣言型のアプローチです。 Google では、宣言した状態が恒久的に維持される仕組みを併用しており、かつ、データとして保持することで、継続的に検査・検証しやすくなる点もメリットの一つです。
Google Cloud (GCP)の環境構築に向けたベストプラクティス
Google Cloud (GCP)には、設計に有用なドキュメントが数多く存在しており、例えば、 Cloud アーキテクチャセンターや各プロダクトページで設計指針が書かれています。
その中でも、ブループリント(全体設計の見取り図)として使われる内容が、設計の入り口としては最適だと言えるでしょう。大きな全体設計から、各プロダクトの詳細設計へ移行していくイメージになります。
Google Cloud (GCP)は、ブループリントをコードで提供しています。ベストプラクティスに準じた設計を Kubernetes Resource Model 形式(YAML)で提供しており、 Kubernetes 基盤に適用させるだけでリソースの構築が可能となっています。
以下は Google Cloud (GCP)における組織フォルダのブループリントの例です。組織(企業ドメイン)やフォルダなど、直感的にわかりやすい形でコードが提供されています。
ここで利用されるツールは Config Connector です。これは Kubernetes を介して Google Cloud (GCP)のリソースを管理できる Kubernetes のアドオンとなっています。
また、 Kubernetes を使う理由は Kubernetes の Reconciliation Loop という特徴を利用する点にあります。 Reconciliation Loop は実際の状態を観測し、理想の状態(定義した内容)と比較した上で、理想の状態になるように変更を繰り返します。そして、この手法をインフラ管理に適用することで継続的な適用が実現できる、というのが Configuration as Data の基本的な考え方です。
ブループリントを活用することで、ベストプラクティスに準じた大まかなインフラを最小工数で構築し、効率的なコード管理を実現できます。使い捨てではなく、継続的なプロジェクト管理など Day 2 運用としても有用に使えますし、ナレッジ共有やインフラ管理も容易になります。
以下、2021年8月時点で Google Cloud (GCP)がブループリントで提供しているコード一覧です。ネットワーキングやプロジェクトなど、カテゴリごとに多くのコードが用意されていることがわかります。
これらのブループリントを活用することで、環境構築にかかる工数を大幅に削減し、本来は数週間かかっていた作業を数日で完了させることが可能になります。
さらに実践的な運用を実現するために
ここからは、さらに実践的な運用を実現するための方法を詳しく解説します。
YAML ファイルの適用については、従来通りに CI サーバを介して kubectl コマンドで適用させることが可能ですが、このフローにおいてはいくつか注意点があります。例えば、 CI サーバから Kubernetes クラスタへのネットワークの到達性や、 Git 管理しているソースと適用状態の差異検知などが挙げられます。
そして、これらの課題を解決するための考え方として、 GitOps による適用フローが挙げられます。同期させる Git リポジトリやブランチ、タグなどを設定し、 Kubernetes クラスタから Git リポジトリに対してソースを取得して適用します。 Reconciliation Loop によってソースの状態が適用状態となり、同期リポジトリが Single Source of Truth となる管理を実現することができます。
ここで Single Source of Truth という言葉が出てきましたが、これは日本語訳だと「信頼できる唯一の情報源」という意味になります。 Git リポジトリを Single Source of Truth として管理することで、宣言した状態がインフラに適用されていることの保証となり、 Google Cloud (GCP)コンソールの閲覧権限がなくても、ソースを見るだけで最新のインフラ状態を確認可能になります。
以下、 Google が提供している GitOps の機能を図で示します。 Config Sync を利用しており、 Kubernetes に Operator を配置することで、定義した Git リポジトリのソースを同期させます。
また、こちらはプレビューの機能となっていますが、 Config Controller を利用すれば、ポリシー制御も合わせて行うことができます。つまり、ポリシーを適用したリソース管理をマネージドな基盤で行い、 GitOps の適用方式で Google 公式のインフラ構築や管理を実現することが可能になります。
なお、ポリシー制御に関しては、デプロイの動作を許可または拒否することが可能です。組織として適用させたいポリシーを管理するためのガバナンスを効かせたり、以下のようなポリシーを定義することができます。
ブループリントを使って GitOps でフォルダとプロジェクトを作成する方法
1.ネームスペースの取得
今回は config controller の基盤を事前に用意しておきました。以下のように必要なコマンドを利用してネームスペースを取得すると、適用されているネームスペースが一覧で表示されます。
2.フォルダの作成
フォルダを作成するには kpt コマンドを使用して、内部からブループリントを取得します。ここでは「/landing-zone/hierarchy」の下にブループリントを記載しています。このとき、フォルダ階層も定義しておきます。
3.プロジェクトの作成
プロジェクトもフォルダと同様に、ブループリントを取得して作成します。ここでは「 demo - retail - apps -dev 」というプロジェクトを作ります。「 setters . yaml 」でどのプロジェクトを所属させるのか、を指定します。
4.追加したフォルダとプロジェクトの適用
フォルダとプロジェクトの作成が完了したら、 commit でこれらを適用します。画面最下部の push を押した後、 push したソースが直接同期するわけではなく、 GitOps で展開した「 source repositories 」というところに push を行い、その後 CI が走る形となっています。
5. development リポジトリに追加
その後は cloud build の中でソースを取得したり、テストチェックを行なった上で問題なければ、 development のリポジトリに追加します。実際に同期しているのは CI が終わった後の方のリポジトリに GKE から config controller が取りに行く、という適用形式になっています。
以上で、ブループリントを使った GitOps によるフォルダとプロジェクトを作成は完了です。以下の通り、フォルダが正しく作成されていることがわかります。タイムラグの関係でプロジェクトはまだ作成されていませんが、しばらくするとフォルダと同様にプロジェクトも作成されます。
Google Cloud (GCP)に関する FAQ
Q.Deployment Manager は今後使わない方針ですか?
A.CI サーバーを介して命令型で運用したい場合は Deployment Manager が有効な選択肢になります。その一方、今回の記事でご紹介した内容にメリットを感じる組織であれば、 Deployment Manager は不向きと言えます。このように、目指すべきゴールによって使い分けることが重要です。
Q.IaC と CaD の違いを教えてください
A.IaC でコードを記述して適用する場合、 CI サーバーもしくは自身の環境からコマンドを入力し、 API を介してインフラを構築する流れとなります。その一方、 CaD は GKE クラスタが自動的に作業を行なう形となり、変更が発生した際はコードの状態に戻ろうとする特徴を持っています。
例えば、インフラリソースの構築は IaC で行い、状態を保っておきたいもの(サービスアカウントのロール定義など)は CaD を利用するなど、自社の目的や用途に応じて、使い分けることが重要になります。
まとめ
本記事では、 Google Cloud (GCP)の環境構築に向けたベストプラクティスを具体的かつわかりやすくご説明しました。
最速でベストプラクティスを適用した環境を作成するためには、ブループリントを利用して初期構築にかかる工数を削減することが大切です。 Google Cloud (GCP)のリソースをコードで管理( Configuration as Data )して、効率的な運用を目指していきましょう。
また、 GitOps の適用フローにより、 Single Source of Truth を実現したり、ポリシーを定義することで、インフラ構築に組織ガバナンスを効かせる点も忘れてはいけないポイントです。記事内容を見返して、 Google Cloud (GCP)の環境構築を進めてみてください。
そして、 Google Cloud (GCP)を契約するのであれば、トップゲートがオススメです。
弊社トップゲートでは、Google Cloud (GCP) 利用料3%OFFや支払代行手数料無料、請求書払い可能などGoogle Cloud (GCP)をお得に便利に利用できます。さらに専門的な知見を活かし、
- Google Cloud (GCP)支払い代行
- システム構築からアプリケーション開発
- Google Cloud (GCP)運用サポート
- Google Cloud (GCP)に関する技術サポート、コンサルティング
など幅広くあなたのビジネスを加速させるためにサポートをワンストップで対応することが可能です。
Google Workspace(旧G Suite)に関しても、実績に裏付けられた技術力やさまざまな導入支援実績があります。あなたの状況に最適な利用方法の提案から運用のサポートまでのあなたに寄り添ったサポートを実現します!
Google Cloud (GCP)、またはGoogle Workspace(旧G Suite)の導入をご検討をされている方はお気軽にお問い合わせください。
メール登録者数3万件!TOPGATE MAGAZINE大好評配信中!
Google Cloud(GCP)、Google Workspace(旧G Suite) 、TOPGATEの最新情報が満載!