ホーム
お役立ち
Google Service
Google Cloud （GCP）の環境構築に向けたベストプラクティスとは？効率的な方法を実画面を交えて徹底解説！

Google Cloud （GCP）の環境構築に向けたベストプラクティスとは？効率的な方法を実画面を交えて徹底解説！

Cloud
Kubernetes
クラウド環境
環境構築

公開年月日: 2022.05.05

更新年月日: 2024.09.26

Google Cloud （GCP）の環境構築に向けたベストプラクティスとは？効率的な方法を実画面を交えて徹底解説！

本記事は、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 では、宣言した状態が恒久的に維持される仕組みを併用しており、かつ、データとして保持することで、継続的に検査・検証しやすくなる点もメリットの一つです。

CAD

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 管理しているソースと適用状態の差異検知などが挙げられます。

YAML

そして、これらの課題を解決するための考え方として、 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 」でどのプロジェクトを所属させるのか、を指定します。

デモ3

4.追加したフォルダとプロジェクトの適用

フォルダとプロジェクトの作成が完了したら、 commit でこれらを適用します。画面最下部の push を押した後、 push したソースが直接同期するわけではなく、 GitOps で展開した「 source repositories 」というところに push を行い、その後 CI が走る形となっています。

デモ4

5. development リポジトリに追加

その後は cloud build の中でソースを取得したり、テストチェックを行なった上で問題なければ、 development のリポジトリに追加します。実際に同期しているのは CI が終わった後の方のリポジトリに GKE から config controller が取りに行く、という適用形式になっています。

でも５

以上で、ブループリントを使った GitOps によるフォルダとプロジェクトを作成は完了です。以下の通り、フォルダが正しく作成されていることがわかります。タイムラグの関係でプロジェクトはまだ作成されていませんが、しばらくするとフォルダと同様にプロジェクトも作成されます。

Google Cloud （GCP）に関する FAQ

Q.Deployment Manager は今後使わない方針ですか？

A.CI サーバーを介して命令型で運用したい場合は Deployment Manager が有効な選択肢になります。その一方、今回の記事でご紹介した内容にメリットを感じる組織であれば、 Deployment Manager は不向きと言えます。このように、目指すべきゴールによって使い分けることが重要です。