Cloud Architect（Googleプロ認定資格）合格への道：第８回正しいコンテナ運用、開発と負荷テスト

どうも、末岐碧衣です。

7月に Data Engineer 取ったばかりですが、9月末に今度は Cloud Architect に挑戦することになりました。

ということで、あと2週間切ってますが（！）、前回合格できた Professional Data Engineer の時と同じ手順で、お金をかけず、短期間で勝負を決めたいと思います。

私は技術畑をずっと歩いてきたエンジニアではないので、文系だったりあんまりI Tに自信ないけど、Google Cloud Certified プロ認定試験に挑戦して、資格取りたい！という方には参考にしていただける内容になると思います。

なお、このGoogleの教育プログラムなどに一切お金を使わず、2週間で集中学習する手順は、模試の受験が必須です。まだの方は、まずは模試を受験してみてください。その辺の手順は第１回の記事で詳しく記載しています。

模試でいうと、１４〜１６問目までです。

→これはDataEngineerの時の勉強と重複するのでスキップ

Pythonベースのオープンソース負荷テストツール。数百万の同時ユーザーをシミュレートするために使用できます。

ちなみに、Locustは日本語訳すると「イナゴ」。ネーミングセンスが光りますね。

GKEアプリで負荷テストしたい時の具体的な使い方はこちら↓

ドライバー（Locust）とターゲーット（サンプルIoTアプリケーション）を別プロジェクトで作成し、テストします。

LocustUIでテスト結果の統計やチャート、障害の詳細を確認できます。

公式はこちら。

Container Registry、Google Kubernetes Engine、Cloud Load Balancingを使う。

Container Registryは、Docker コンテナイメージを保存、管理、保護を行う。CI / CD 統合がすでに組み込まれており、コードをコミットすると自動的にイメージをビルド、デプロイしてくれる。また、脆弱性スキャンもやってくれる。

Cloud Load Balancingは、単一リージョン内のインスタンスにトラフィックを分散する。

ただし、DNS レコードで使用できる単一のグローバル IP アドレスを提供するので、 URL マップを使用して、リクエストを公開したいサービスのみにルーティングすることが可能。

コンテナは従来のサーバーみたいに扱ってはいけない。例えば、コンテナ内でアプリを更新したり、パッチを適用してはいけない。

アプリケーションコードを更新したり、パッチを適用したりする必要がある場合は、新しいイメージを作成して再デプロイします。

ステートレス性：全ての「状態」がコンテナの外部に格納されること。ファイルはCloud Storage、セッション情報はKey-Value ストア（Redis や Memcached）

不変性：コンテナがその存続期間を通して変更されないこと。コンテナの構成（リスニングポート、ランタイムオプションなど）を外部化する。

公式はこちら↓

Prometheus（プロメテウス、オープンソースの監視ツール）を使ってホワイトボックスモニタリングを行う。

artifact（アーティファクト）：人工物

つまり、デプロイするアプリ一式のこと。

次回に続く！

それでは！

NoveLel ~のべれる~