ホーム > fein's bookshelf > Google系

このページの注意点🔻

ネットに公開しているものなのでご覧いただいても構いませんが、次の事項にご留意ください。

• 便宜上、個人サイトのカテゴリーに収まっていますが、サイト制作とは関係ありません。

• パソコンについて書いてありますが、ここをご覧いただいても勉強にはなりません。

• 学生の頃から作ってきた私のデジタルノートをGoogleサイトへ移しているだけなので、情報が古い、ないしは誤っている可能性があります。

• ただの個人的な思い出ページであって情報提供を目的とはしておりませんので、整理もしていません。

タスクや処理の負荷を表す重要な概念。
クラウド基盤のスケーリングやコスト削減においても重要な要素となる。

＜一般的な意味＞
仕事量や作業負荷：
一般的には、仕事量や作業負荷を指す。つまり、特定のタスクやプロジェクトにかかる作業の量や負担のことである。

＜IT分野での意味＞
コンピュータやシステムの負荷：
・ITの文脈では、ワークロードはコンピュータやシステムにかかる処理の負荷の大きさを指す。
具体的には、稼働中のコンピュータがどれだけ忙しいか、実行中のソフトウェアによって処理能力が占有されている度合いを表す。
これはCPU使用率やメモリ使用率、ネットワーク使用率などの総称であり、コンピュータの持つ資源がその最大容量に対してどのくらいの割合で利用されているかを示す。

＜仮想化とクラウドの文脈でのワークロード＞
仮想マシン上で実行されているソフトウェア：
仮想化の分野では、ワークロードは仮想マシン（VM）上で実行されているソフトウェア全体を指すこともある。
これにはオペレーティングシステム（OS）、ミドルウェア、アプリケーションソフト、展開されているデータなどが含まれる。

Google Cloud ─ 以前はGCPと呼ばれていたこともある ─ が提供する、仮想マシンを簡単に構築・運用できるサービス。
Amazon Web Services（AWS）のAmazon EC2やMicrosoft AzureのVirtual Machinesに相当する。

１．仮想マシンの柔軟性：
GCEはビジネスや個人のニーズに応じて柔軟な仮想マシン（VM）を提供する。
必要なときに、必要な分だけVMを用意できる。
また、不要になれば簡単に削除したり、システムの規模に応じて拡張することも可能。

２．スケーラビリティと信頼性：
GCEは高性能な仮想マシンを柔軟に構築・運用できる。
内部IPアドレス（プライベートIPアドレス）や外部IPアドレス（パブリックIPアドレス）を持たせることができ、必要に応じて拡張できる。
また、Google Cloudの信頼性の高いインフラストラクチャを利用している。

３．操作とステート：
GCEはWeb API経由で操作する。─ 構築、起動、停止など ─
Google CloudコンソールやGoogle Cloud CLIからVMを操作できる。
VMはステート（状態）を持ち、次のような状態がある。

• PROVISIONING（構築中）

• RUNNING（実行中）

• STOPPING（停止中）

• TERMINATED（停止済み）

４．料金体系：
GCEの料金はvCPU・メモリ料金、有償のOSライセンス料金、ディスク料金、ネットワーク料金などで構成されています。詳細はGoogle Cloudの公式ドキュメントで確認が必要。

クラウドコンピューティングにおいて重要な概念である。
どちらを選ぶべきかは、利用する目的や用途による。
VMインスタンスは仮想サーバの作成に適しており、仮想化インスタンスは複数のユーザーが同時に利用するのに適している。

＜VMインスタンス (Virtual Machine Instance)＞
VMインスタンスは、仮想マシンを表す言葉で、"Virtual Machine"の略。
つまり、VMインスタンスは、複数の仮想マシンを利用して、クラウド上で仮想サーバを作成する仕組みのことを指す。
VMインスタンスは、ハードウェアやオペレーティングシステム、アプリケーションを含めた仮想環境を提供し、ユーザーは必要なものを選択して利用できる。

＜仮想化インスタンス＞
仮想化インスタンスは、仮想的なコンピュータを作成する技術で、仮想化技術の一つ。
物理的なコンピュータのリソースを仮想的なコンピュータに割り当てることができ、1つの物理的なコンピュータ上に複数の仮想環境を構成できる。
そのため、複数のユーザーが同時に同じ物理的なコンピュータを利用できるようになる。

Googleが提供しているクラウド型のデータウェアハウス（DWH）。

＜BigQueryの概要と特徴＞
BigQueryは、ペタバイト単位のデータに対するスケーラブルな分析を可能にするフルマネージドのサーバーレスDWH。
使いやすいSQLを用いてクエリを実行できるため、非エンジニアでもデータ分析が行える。
データ処理の速さも特筆すべき点で、TB単位のデータを数秒、PB単位のデータを数分で処理できる。

＜BigQueryの仕組み＞
BigQueryはカラム型データストアとツリーアーキテクチャの2つの仕組みによって高速なデータ処理を実現している。

• カラム型データストア：
  通常の行単位ではなく、列ごとにデータを保存する方式。トラフィックの最小化と高圧縮が可能で、クエリ実行のスピードが向上する。

• ツリーアーキテクチャ：
  クエリを並列処理するための多数のリーフサーバーを持つ仕組み。大規模分散処理を実現している。

＜BigQuery Omniとの違い＞
BigQuery Omniは、AWSのS3データやMicrosoft AzureのBlob Storageデータを集約し、BigQuery内でクエリを実行できるサービス。他社製品との連携が必要な場合に使う。

＜BigQueryでできること＞

• 他社DWHからの移行

• BigQuery内へのデータ転送

• リアルタイム分析

• マーケティング分析

• セキュアなデータ共有スペースの構築

Google Cloud の「Cloud Storage」（GCS）は、スケーラブルで信頼性の高いストレージサービス。さまざまな種類や規模のデータを保管できる。
画像、テキスト、動画、その他のファイル形式の不変データを扱うためのグローバルなオブジェクト ストアとして機能している。
データの保存から規制遵守、障害復旧、データ分析まで幅広い用途に対応できるストレージサービスとなっている。

１．オブジェクト ストレージ：
Cloud Storageはオブジェクト ストレージとして設計されている。
これは、データを「オブジェクト」として保存する方法で、ID、メタデータ、属性、実際のデータが含まれている。
メタデータには、ファイルのセキュリティ分類やアクセス可能なアプリケーション、類似の情報などが含まれる。

２．ストレージ クラス：
Cloud Storageでは、データの保存頻度やアクセス頻度に応じて異なるストレージ クラスを４つ選択できる。

• Standard：高いパフォーマンスと頻繁なアクセスが必要なデータ

• Nearline：月に1回未満のアクセスがあるデータ

• Coldline：おおよそ四半期に1回未満アクセスするデータ

• Archive：年に1回未満のアクセスがあるデータ

３．ロケーション：
3つのロケーションがあり、データを保存する場所を選択できる。

• リージョン：1つのリージョン内に冗長的に保存される

• マルチリージョン：大陸全体にわたって冗長的に保存される

• デュアルリージョン：特定の2つのリージョンに保存される

４．セキュリティ：
デフォルトでは、Cloud Storageのデータは保存時も転送時も自動的に暗号化される。
セキュリティをより直接的に制御するために、顧客管理の暗号鍵（CMEK）を使用できる。

ロードバランサは、ネットワークトラフィックを複数のサーバーに均等に分散する装置またはサービス。
これにより、負荷が一部のサーバーに集中することなく、高可用性とパフォーマンスを実現できる。

VPC InternalロードバランサはEnvoyプロキシベースのレイヤー7ロードバランサである。
接続元がGoogle Cloud内やCloud VPN、Cloud Interconnectで接続されたオンプレミスの他、Amazon Web Services（AWS）等からのトラフィックをバックエンドサービスへ分散する。
内部アプリケーションロードバランサは、単一の内部IPアドレスの背後でサービスを実行およびスケーリングできるようにする。

Google Cloud の管理型ネットワークアドレス変換サービスで、アプリケーションインスタンスにパブリックIPアドレスを割り当てずに、制御された効率的な方法でインターネットへのアクセスを可能にする。
アップデート、パッチ適用、設定管理などのために、外部IPアドレスを持たないリソースがインターネットにアクセスできるようになる。
簡単に言えば、Cloud NATは、外部IPアドレスを持たないリソースがインターネットにアクセスできるようにする仕組みである。

１．セキュリティ：

• 個々のVMに外部IPアドレスを割り当てる必要がなくなる。

• 外部IPアドレスを持たないVMは、下り（外向き）ファイアウォールルールに従ってインターネット上の宛先にアクセスできる。

２．可用性：

• Cloud NATはソフトウェア定義の分散マネージドサービスであり、単一の物理ゲートウェイデバイスに依存しない。

• NATゲートウェイを構成することで、指定した構成パラメータを保持するNATのコントロールプレーンが提供される。

３．スケーラビリティ：

• Cloud NATは、使用するNAT IPアドレスの数を自動的にスケーリングできる。

• 自動スケーリングが有効になっているVMなど、マネージドインスタンスグループに属するVMをサポートする。

４．パフォーマンス：
Cloud NATはGoogleのAndromedaソフトウェア定義ネットワーキングにより実装されているため、VMごとのネットワーク帯域幅を縮小しない。

また、Cloud NATはNATルールを使用してインターネットへの接続方法を定義できる。
NATルールは、送信元アドレスに基づいて送信元NATをサポートする。
必要に応じてNATルールを追加して、トラフィックを細かく制御できる。

Google Cloud のゼロトラストセキュリティを実現するためのサービスの一部。
クラウド上のアプリケーションやリソースへのアクセスを制御するための認証と認可サービスである。
IAPはGoogle Cloudのアプリケーションへのアクセスをセキュアかつ柔軟に制御するための強力なツールとなっている。

１．認証と認可：
IAPは、ウェブサイトへのリクエストをインターセプトし、リクエストを送信したユーザーを認証して、認証されたユーザーにのみサイトへのアクセスを許可する。
ユーザーはGoogleアカウントを使用して認証され、IAM（Identity and Access Management）で適切なロールを持つユーザーのみがアプリケーションにアクセスできる。

２．外部IPを持たないVMインスタンスへの接続：
IAPを使用すると、外部IPアドレスを持たないCompute EngineのLinux仮想マシン（VMインスタンス）にSSH接続できるようになる。
通常、外部IPアドレスを持たないVMインスタンスにはSSH接続できないが、IAPを介して内部IPアドレスのみを持つVMインスタンスに接続できる。

３．ゼロトラストセキュリティ：
IAPは、従来の「社内ネットワークは安全、外部ネットワークは危険」という考え方に基づく境界型防御ではない。
「社内外すべてのネットワーク、ユーザー、デバイスを信頼せず、アクセスごとに検証する」という新しいセキュリティの考え方であるゼロトラストセキュリティを実現する。

Google Cloud（旧称GCP）のAPIに対して、外部IP（Public IP）を持たないVMやオンプレミスのクライアントから、プライベートネットワーク内でセキュアにアクセスできるようにする仕組み。

１．アクセスの制御：
Private Google Accessを有効にすると、プライベートネットワーク内のVMからGoogle CloudのサービスやAPIにアクセスできるようになる。
通常、Google CloudのAPIはインターネット経由でアクセスされることを想定しているが、Private Google Accessを使用することで、インターネットを介さずにプライベートネットワーク内でアクセスできるようになる。

２．ドメイン名の選択：
Private Google Accessを有効にする際、利用するドメイン名を選択できる。
この利用するドメイン名には3つの選択肢がある。

• デフォルトのドメイン名を利用する

• `private.googleapis.com` を利用する

• `restricted.googleapis.com` を利用する

これらの選択肢によって、アクセスの挙動やセキュリティ設定が異なる。

３．限定公開の Google アクセスとPrivate Service Connect：
類似の機能として、Private Service Connectもあります。どちらを利用するかは、具体的な要件次第となる。

組織や情報システムが独立して連携できない状態を指す。
まるで穀物や飼料を貯蔵する倉庫（サイロ）が互いに交わらないように、企業の部門やシステムが孤立してしまうことを意味する。
このサイロ化にはいくつかの側面が見られる。

１．企業組織のサイロ化：

• 企業組織が縦割り構造になっていると、業務部門どうしの連携が取れていないことがある。

• 部署ごとに異なる風土や情報の共有不足が、コミュニケーションの悪化や可視化の不足を引き起こすことがある。

２．システムの情報サイロ化：

• システムや業務プロセスが部門ごとに独立していると、他の部門や事業部との連携が不足する。

• データ形式の違いやアプリケーションのバラエティが、システムの情報サイロ化を引き起こすことがある。

なぜサイロ化が起こるか。
組織が縦割り構造だと、システムも同様に部門ごとに最適化されてしまい、他の部門との連携が難しくなる。
また、急いで業務を進める結果、全社的な連携がおろそかになることもある。
さらに、情報システム部門が関与せずにシステムが構築されることも原因となる。
サイロ化が引き起こす問題には、業務の効率悪化、データの分断、コスト増大がある。
しかし、サイロ化を改善することで、組織の生産性向上やデータの活用、コスト削減、DX（デジタルトランスフォーメーション）の推進が期待できる。
改善策としては、組織の改革、情報システムの統合、クラウドサービスの活用などがある。
サイロ化を解消することで、より効率的で柔軟な組織を実現できる可能性がある。

Google Cloudや他のクラウドプロバイダーで広く使われている重要な概念。
アプリケーションをパッケージングし、異なる環境で実行できるメカニズムである。

＜コンテナとは何か＞
コンテナは、アプリケーションコードと必要なライブラリ、設定などを1つにまとめたもの。
アプリケーションとその実行環境（インフラストラクチャ）が緩やかに結びついているため、柔軟な開発とデプロイが可能となる。
コンテナは、開発環境からテスト環境、本番環境、オンプレミス、プライベートクラウド、パブリッククラウドなど、異なる実行環境間で移動することも容易。

＜コンテナの利点＞

• モジュール化：コンテナはアプリケーションをモジュール化し、モノリシックなアプリケーションからマイクロサービスへの移行をサポートする。

• リリースの効率化：コンテナは便利なパッケージング形式と明確に定義されたCI/CD（継続的インテグレーション/継続的デリバリー）により、リリースのオーバーヘッドを軽減する。

• 一貫性の維持：コンテナは再構築や再プッシュが容易で、稼働後に初期状態からの逸脱が発生しにくい。

＜セキュリティについて＞

• VMとは異なるセキュリティモデルを持っているが、適切に保護されたクラスタ内のコンテナはVMと同等のセキュリティを提供する。

• ホストOSのハードニングや自動更新を受けており、プロセスレベルの分離機能を提供する。

• Kubernetesなどのオーケストレーションツールは、コンテナの分離をサポートするためにさまざまなツールを提供している。

アプリケーションやサービスの連携と制御を指す重要な概念。
Google Cloudは、オーケストレーションとコレオグラフィーの両方のアプローチをサポートしており、適切なアプローチを選択できる。

＜サービス コレオグラフィー＞
サービス コレオグラフィーでは、各サービスが独立して動作し、イベントを通じて他のサービスと疎結合の状態で相互に作用する。
疎結合されたイベントは、独立して変更やスケーリングが可能。つまり、単一障害点がない。
ただし、多くのイベントが飛び交っているため、モニタリングが困難で、ビジネスロジックが分散している。

＜サービス オーケストレーション＞
サービス オーケストレーションでは、サービス間のインタラクションを一元的にコントロールするオーケストレーターが存在する。
このオーケストレーターはビジネスプロセスの概要を示し、実行の追跡や問題のトラブルシューティングを行う。
Google Cloudでは、Workflowsを使用してサービス オーケストレーションを実現できる。

＜オーケストレーションに関連するサービス＞

• Workflows：

  • サーバーレスのワークフローを使用して、Google CloudサービスやHTTPベースのAPIサービスのオーケストレーションと自動化を行う。

  • ビジネスプロセスを定義し、複数のサービスへの呼び出しをオーケストレートするための、フルマネージドで監視可能な方法。

• Pub/Sub：

  • イベント駆動のサービスのコレオグラフィーに適している。Pub/Subは非同期に通信できるメッセージング指向のミドルウェア。

• Eventarc：

  • イベント駆動アーキテクチャを構築するための標準化されたソリューションで、Cloud Runにイベントをルーティングする。

Google Cloud のインフラストラクチャ上でマネージドな Kubernetes クラスタを提供するサービス。
コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を行うオープンソースプラットフォームである。
コンテナ技術（例: Docker）を利用することで、開発から本番環境まで環境の差異を最小限に抑え、効率的にアプリケーションを運用できる。

１．Google Kubernetes Engine (GKE) の特徴：

• マネージドサービス
  GKEはGoogle Cloudが提供するクラスタ管理機能により、Kubernetesクラスタの管理負荷を大幅に削減する。

• 自動スケーリングと修復
  ノードは自動的にスケーリングや修復が行われ、運用管理が簡略化される。

• Autopilotモード
  本番環境向けに最適化されたクラスタ構成を提供し、ユーザがワークロードに対して使用したコンピューティングリソースのみに料金が発生する。

• Standardモード
  ユーザがノードの構成や管理を行い、柔軟性を持たせた運用モード。

２．クラスタのアーキテクチャ：

• GKEクラスタはコントロールプレーン（マスターノード）とノード（ワーカーノード）の2つのコンポーネントで構成される。

• コントロールプレーンはGoogle CloudのマネージドVPC内に作成され、ユーザに構築や運用の負荷はない。

• ノードはCompute Engineインスタンスによって構成され、ワークロードを実行する。

Google CloudのIDプロバイダ（IdP）であり、Google Workspaceで利用されているIdentity as a Service（IDaaS）ソリューションでもある。
さまざまな管理機能を備えており、組織（企業や学校など）のID管理をサポートするソリューションとなっている。
次のようなポイントがCloud Identityに関連している。

───────

1. ID管理：Cloud Identityは、Google CloudユーザーのデジタルIDを保存し、管理することができる。これで組織内のユーザーアカウントを一元管理する。

2. シングルサインオン (SSO)：Cloud Identityは、シングルサインオンをサポートしている。ユーザーは1回のログインで複数のアプリケーションにアクセスでき、便利さとセキュリティを両立させることができる。

3. 多要素認証 (MFA)：セキュリティを強化するために、Cloud Identityは多要素認証を提供している。ユーザーはパスワードだけでなく、追加の認証要素（SMSコード、ハードウェアトークンなど）を使用してログインできる。

4. モバイルデバイス管理 (MDM)：組織内のモバイルデバイス（スマートフォンやタブレット）を効率的に管理できる。セキュリティポリシーの適用やデバイスの監視などが可能。

5. 無料版と有料版：Cloud Identityには無料版（Cloud Identity Free Edition）と有料版（Cloud Identity Premium Edition）がある。無料版は最大50人のユーザーまで利用できるが、それ以上のユーザー数を希望する場合は有料サブスクリプションが必要となる。

「一般のGoogleアカウント」と「Cloud Identity」は異なる概念である。
一般のGoogleアカウントは個人向けであり、Cloud Identityは組織向けのアカウント管理ツール。

＜一般のGoogleアカウント (Google Account)＞
個人がGoogleのサービス（Gmail、Google Drive、YouTubeなど）にアクセスするために作成するアカウント。
一般のGoogleアカウントは、個人のメールアドレスとパスワードで構成されている。
個人用途に適しており、個人のコミュニケーションやファイル共有に使用される。

＜Cloud Identity＞
組織（企業や学校など）向けのID管理ソリューション。組織内のユーザーを一元管理し、セキュリティを強化するために使用される。
シングルサインオン（SSO）、多要素認証（MFA）、モバイルデバイス管理（MDM）などの機能を提供する。
組織の従業員や学生は、Cloud Identityを使用して組織のリソースにアクセスする。

Google Cloudにおいて「Cloud Identity」と「Cloud Identityドメイン」は異なる概念である。
Cloud Identityは組織向けのID管理ソリューションであり、Cloud Identityドメインはその登録に必要なドメインを指す。

＜Cloud Identity＞
Cloud Identityは、Google CloudのIDaaS（Identity as a Service）ソリューション。
これは、組織（企業や学校など）向けに提供されており、以下の特徴がある。

• ID管理：Cloud Identityを使用することで、組織内のユーザーのデジタルIDを一元管理できる。GoogleアカウントやGoogleグループを作成・管理できる。

• セキュリティ機能：Cloud Identityで作成したGoogleアカウントには、二要素認証の強制、パスワードポリシー、アクセス元IPアドレス制限などを管理者側から設定できる。

• Google Cloudリソースへのアクセス管理：Cloud Identityで作成したGoogleアカウントやGoogleグループに対して、Google CloudのIdentity and Access Management（IAM）から権限を付与することで、Google Cloudリソースへのアクセス管理を実現できる。最大50アカウントまでは無償利用が可能。

＜Cloud Identityドメイン＞

Cloud Identityドメインは、Cloud Identityを利用する際に登録するドメインを指す。以下の点に注意が必要。

• ドメインの所有権：Cloud Identityに紐づけるドメインは、そのドメインの所有権を保持している必要がある。つまり、DNS設定にTXTレコードを登録できることが求められる。

• 未使用のドメイン：登録するドメインは、Cloud IdentityまたはGoogle Workspaceで未使用のものである必要がある。

例えば、会社のドメインを使用する予定であった場合、すでに他の部門のCloud Identityで使用されているドメインは選択できない。このような場合、新たに独自のサブドメインを作成して登録することが一つの解決策となる。

Google Cloudのフォルダはクラウドリソースの管理に特化しており、Google Driveのフォルダはファイル整理と共有に特化している。
Google Cloudの「フォルダ」は、クラウドリソースの整理と管理に使用できるツール。
Google Cloud Resource Managerのフォルダは、組織の構造に合わせてリソースをマッピングしたり、アクセス制御をきめ細かく設定できる。

Google Cloudのフォルダ

用途：Google Cloudプロジェクト内のリソースを階層的に整理・管理するために使用される。組織内の部門、チーム、アプリケーション、環境などを表すために利用できる。

利点：

• リソースの整理と分類がしやすくなる。

• 運用の柔軟性が向上する。チームや部門に管理権限を委ねたり、独立した運用を認めたりできる。

• アクセス制御ポリシーをフォルダに適用できる。

例えば、部門ごとにプロジェクトを整理し、適切な担当者が適切な情報にアクセスできるよう構築できる。

Google Driveのフォルダ
LinuxのGUIフォルダと基本的な考え方は同じ。
Google Driveは個人やチームがファイルを保存・共有するためのクラウドストレージサービス。
Google Driveのフォルダは、ファイルを整理してアクセスしやすくするために使用される。
ファイルの整理がしやすく、共有フォルダを作成して他のユーザーとファイルを共有できる。
ファイルのバージョン管理や共同編集も可能。

クラウドリソースを効率的に管理するための重要な概念。
Google Cloudのリソースを管理する最小単位となる。
Google Cloudでは、プロジェクトを作成してその中にリソースを配置する。
プロジェクトを作成する際には、以下の設定が必要となる。

• プロジェクト名：自由に名前をつけられる。

• プロジェクトID：世界で一意のIDを指定する。

• プロジェクト番号：自動生成されるプロジェクトの識別子。

＜プロジェクトを使う理由＞
本番環境と開発環境の分離：プロジェクトごとに本番環境と開発環境を分けて管理できる。
設定の混乱を避けるために重要である。

• 費用管理：プロジェクト単位で課金が発生するため、どこで課金が発生しているかがすぐに分かる。

• 権限の管理：プロジェクトごとに権限を設定できるので、セキュリティを強化できる。

＜リソースとは＞
Google Cloudでは、さまざまなサービスや機能が提供されている。
これらのサービスは、クラウド上で構築された要素を指す。
例えば、以下のようなリソースがある。

• Compute Engine：仮想サーバーを提供するサービス

• Cloud SQL：データベースサーバーを提供するサービス

• Cloud Storage：オブジェクトストレージを提供するサービス

• BigQuery：大量のデータの処理・分析を行うサービス

• Vertex AI：機械学習を行うためのサービス

＜Google Cloudのリソース管理＞
プロジェクトを作成して、その中で必要なサービスを有効にすることで、リソースを利用する。
プロジェクトごとにリソースを分けて管理できるため、効率的にクラウドリソースを活用できることになる。

Google Cloudのリソースは、クラウド上でアプリケーションを構築する際に必要な要素であり、開発者やビジネス向けにさまざまな機能を提供している。

Google Cloudでは、リソースを階層的に整理して管理している。
この階層は、クラウド上でのリソースの構造を表しており、次のようにレベルで構成されている。

１．組織 (Organization)

• すべてのリソースのルートレベルである。

• 企業全体や組織内のすべてのリソースが含まれる。

• 組織レベルで定義されたポリシーは、階層内の全リソースに継承される。

２．フォルダ (Folder)

• 組織内のリソースを整理するために使用する。

• プロジェクトや他のフォルダを含めることができ、分離要件の境界線を柔軟に対応できる。

• フォルダレベルで定義されたポリシーは、その階層下に適用される。

３．プロジェクト (Project)

• 特定のワークロードやチームのリソースをグループ化する。

• プロジェクトは、サービスやアプリケーション、組織内の部署やチームを論理的に表す。

４．リソース (Resource)

• プロジェクト内の個々のサービスやアプリケーション。

• 仮想マシン、データベース、ストレージ、AI/機械学習などが該当する。

この階層は、従来のオペレーティングシステムのファイルシステムに似ており、各リソースの親が1つだけで、その親がリソースのライフサイクルを管理する。
階層はアクセス管理や設定ポリシーの設定箇所も提供しており、管理の簡素化とセキュリティの改善を実現する。
例えば、企業の組織管理者は最初のレベルのフォルダを組織の下に作成し、エンジニア部門、IT部門、オペレーション部門、マーケティング部門などをマッピングできる。
そして各フォルダの管理を担当部門のリーダーに委任できる。
GCPのリソース階層は、効率的なリソース管理とセキュリティの向上に役立つ。

古くなったシステムやアプリケーションを現代的で効率的な形にアップデートするプロセスを指す。
「モダナイゼーション」は、古いシステムを新しい技術やアーキテクチャに適合させ、パフォーマンス、スケーラビリティ、セキュリティを向上させるプロセスである。

１．クラウドネイティブ化 (Cloud-Native Transformation)
アプリケーションをクラウド環境に適した形に変換することを指す。
クラウドネイティブアプリケーションは、スケーラビリティが高く、柔軟性があり、コンテナ化されていることが一般的である。

２．コンテナ化 (Containerization)
アプリケーションをコンテナとしてパッケージ化することで、環境に依存しない形で実行できるようになる。
これにより、アプリケーションのデプロイメントやスケーリングが簡単になる。

３．マイクロサービス化 (Microservices)
アプリケーションを小さな独立したサービスに分割し、それらを組み合わせて機能を提供するアーキテクチャ。
マイクロサービスは、保守性や拡張性を向上させる。

４．データベースの最適化
データベースの移行や最適化を行い、パフォーマンスを向上させる。
例えば、Google CloudのDatabase Migration Serviceを使用して、既存のデータベースをCloud SQLなどのフルマネージドデータベースに移行することができる。

システムやアプリケーションの能力を調整するプロセス。
システムの柔軟性とパフォーマンスを向上させるための方法であり、Google Cloudではさまざまなスケーリングオプションが提供されている。

１．水平スケーリング (スケールアウト)
このアプローチでは、ノード（サーバー、仮想マシンなど）の数を増やすことで、システム全体の処理能力を向上させる。
新しいトラフィックが発生した場合、新しいノードを追加して負荷を分散する。
逆に、トラフィックが減少した場合はノードを減らすことでコストを削減できる。
例えば、ウェブサイトのアプリケーションサーバーが水平スケーリングを使用して、トラフィックの急増に対応することがある。

２．垂直スケーリング (スケールアップ)
このアプローチでは、単一のノードのリソース（CPU、メモリなど）を増やすことで、システムの能力を向上させる。
通常、ハードウェアのアップグレードや仮想マシンのリソース変更によって実現される。
例えば、データベースサーバーが垂直スケーリングを使用して、より多くのトランザクションを処理できるようにする作業などが当てはまる。

３．予測自動スケーリング
Google Cloudでは、予測ベースの自動スケーリングも提供されている。
これは、機械学習を使用して将来の負荷を予測し、事前にリソースを調整する方法。
例えば、Compute Engineでは、予想される負荷に対する容量を事前にスケジューリングすることで、ワークロードの可用性を向上させている。

システムやアプリケーションの設計や構造を指す。
クラウド環境で効率的で安全なシステムを構築するための設計原則やパターンを含む。
Google Cloudのアーキテクチャフレームワークは、安全で効率的、復元力が高く、高パフォーマンスで費用対効果に優れたシステムを構築するためのベストプラクティスと最適化案を提供している。
また、Google Cloudでは、アーキテクチャに関するいくつかの重要な原則がある。
これらは、クラウドネイティブなアプリケーションを設計する際に考慮すべきポイントとなっている。
Google Cloudのアーキテクチャに関連するいくつかのポイントを列挙するため、他のクラウドサービスを選ぶ際にも覚えておくこと。

１．自動化を組み込む
ソフトウェアシステムにおいて自動化は常にベストプラクティスである。
クラウド環境では、コンポーネントだけでなく、インフラストラクチャの自動化も容易に行える。
自動化されたプロセスは、人間よりも迅速にシステムの修復やスケーリング、デプロイを行う。

２．スケーリング
クラウドネイティブなシステムでは、負荷の増減に応じて自動的にスケールアップやスケールダウンを行うことが重要である。
スケールアップは可用性を維持し、スケールダウンはコスト削減を可能にする。

３．モニタリングと自動修復
モニタリングとロギングを組み込むことで、システムの健全性を監視できる。
データストリームのロギングとモニタリングは、システムの利用状況やユーザーの行動に関する価値のある知見を提供する。

４．セキュリティとコンプライアンス
セキュリティとコンプライアンスを考慮したアーキテクチャ設計が重要である。
Google Cloudはセキュリティ対策を提供しており、これを適切に活用することが求められている。

システムやサービスの設定やリソースの準備を行うプロセスを指す。
クラウド環境においては、リソースを適切に準備し、効率的に利用するためのプロセスと言える。

１．サーバープロビジョニング
需要に応じてサーバーの設定を変更し、利用できる状態にするプロセス。
これにはOSの導入やシステムの設定、ネットワークの設定、ストレージの割り当てなどが含まれる。
サーバーのメンテナンスや予備サーバーの調整もここに加えられる。
例えば、新しいウェブアプリケーションを展開する際に、サーバープロビジョニングを使用して必要なリソースを準備する。

２．ユーザープロビジョニング
アクセス権限や認証情報などを監視するID管理を指す。
ユーザーアカウントの作成、変更、削除などが含まれる。
セキュリティを考慮して、ユーザーの権限や役割に応じて柔軟に行うことが重要である。
例えば、社内の従業員がクラウドサービスを利用する際に、ユーザープロビジョニングを使用してアカウントを作成する。

３．サービスプロビジョニング
インターネット通信事業者が行うサービスの準備作業を指す。
通信サービスの提供に必要な環境構築を行う。
例えば、インターネット回線を引いたり、クラウドサービスを利用するための基盤を準備するのがサービスプロビジョニングである。

４．シン・プロビジョニング
ストレージの効率的な運用を実現するための技術。
仮想化されたストレージ環境において、ユーザーに必要な容量を柔軟に割り当てることができる。
クラウドストレージでよく使用されている。

データ活用基盤において重要な概念。
ビジネスサイドのデータ活用を促進するために設けられる層で、システム表現をビジネス表現に翻訳する役割を果たす。
この層を通じて、データの意味や指標の定義を一元管理し、ビジネスユーザーがデータを理解しやすくなる。
Google Cloudにおいて、セマンティックレイヤーを実現する方法として、Lookerというサービスがある。
LookerはGoogle Cloudが提供するデータ活用基盤で、BI的な機能を持ちつつ、データ活用基盤として幅広い用途に利用できる。

１．データ接続
LookerはBigQueryやRedshiftなどのデータウェアハウスに接続して利用する。
接続後、LookerはSQLを自動生成してリアルタイムでデータを取得できる。

２．LookML
Lookerの特徴的な機能のひとつが「LookML」である。
LookMLは独自のデータモデリング言語で、BIで可視化すべき指標（売上などの定量的なメジャーや、都道府県名などの定性的なディメンション）の定義を一元管理する。
これにより、複数のダッシュボードやレポートで共通して使われるデータについて、修正が必要な場合にも効率的に対応できる。

３．セマンティックレイヤーの役割
Lookerはセマンティックレイヤーとしての役割を果たす。
BI側でデータの定義を持つことで、データ定義の属人化や分散を防ぎ、誰が分析しても同じデータの定義に基づいた精度の高い分析結果を得ることができる。

加えて、Looker StudioとTableauは別のサービスであり、それぞれ異なる特徴を持っている。
Looker StudioはGoogle Cloudが提供する無償のフルマネージド型BIで、操作性が良く簡単に可視化が行える。
一方、Tableauは自由度の高い可視化表現を提供し、アドホック分析に適している。

データ分析やビジネスインテリジェンス（BI）の領域で活躍する次世代型のツール。
Google Cloudが提供するサービスで、ユーザーのデータ体験を向上させることに重点を置いている。
注意点として、Lookerを導入する際にはLookMLという独自言語を使う必要がある。
LookMLはJSONライクなフォーマットで、データエンジニアがセマンティックレイヤを構築したりメンテナンスしたりする際に必要である。

１．データの使いやすさを向上させる
データを使ってレポートを作成したり、分析したりする際、データが使いづらいことがある。
Lookerは、こうしたユーザーストレスを軽減するために開発された経緯がある。
例えば、自分でクエリを作成したり、似たような名前のデータを選ぶ際の混乱を解消できる。

２．セマンティックレイヤの追加
Lookerの最大の特徴は、データ基盤のアーキテクチャにセマンティックレイヤを追加できることである。
セマンティックレイヤは、データを使うビジネスユーザーとデータソースの間で通訳のような役割を果たす。
ビジネスユーザーが「売上」というデータを要求した場合、Lookerはセマンティックレイヤを通じて適切なクエリを自動的に発行し、ビジネスユーザーに売上金額を提供する。
つまり、ビジネスユーザーはクエリを書く手間から解放され、本来やりたかった分析に集中できる。

３．データの定義と統制
Lookerを使うことで、データの定義や指標を統制できる。
これにより、似ているが少し違うデータが乱立することを防ぎ、分析者や意思決定者にとっても安心してデータを利用できるようになる。

Google Cloud（旧称GCP）の鍵管理サービス。
正式名称は「Cloud Key Management Service」だが、「KMS」と略されることが多い。
Cloud KMSはGoogle Cloud上で鍵を安全に管理し、データを暗号化するためのツールと言える。

１．鍵管理サービス
Cloud KMSは、秘密鍵を作成・保管・管理するためのクラウドサービス。
さまざまなGoogle Cloudサービスのストレージを暗号化することができる。
例えば、Cloud StorageバケットやCompute Engineの永続ディスク、BigQueryのデータセットなどが暗号化の対象となる。

２．デフォルト暗号化とCMEK
Google Cloudサービスでは、デフォルトで暗号化されているデータがある。
これはGoogle側で自動的に鍵が管理・ローテーションされるため、ユーザー側で意識する必要はない。
しかし、監査上の理由や非常に強固なセキュリティが求められる場合には、ユーザー側で独自に鍵を管理して暗号化したいことがある。
その際にCloud KMSの鍵を利用できる。

３．料金
Cloud KMSの料金は、保持する鍵のバージョン数と鍵に対するオペレーションの回数によって決まる。
例えば、アクティブな対称鍵のバージョン1つにつき、月額0.06ドルとなっている。

Development（開発）とOperations（運用）を組み合わせた言葉で、ソフトウェア開発と運用のプロセスを密接に連携させるアプローチ。
この手法は、サービスの信頼性を高めつつ、開発速度を向上させることを目指している。
DevOpsエンジニアは以下のような役割を果たす。

・CI/CD（継続的インテグレーションと継続的デリバリー）の実装：
ソフトウェアの開発プロセスを効率化するために、ビルド、テスト、デプロイの自動化を行う。
短いスパンで頻繁に統合し、問題を早期に特定できるようにする。

・プロダクションシステムとサービスの最適化とメンテナンス：
運用中のシステムの信頼性を保ちつつ、効率的な運用を実現する。

・サービスの信頼性とデリバリースピードのバランス：
高い信頼性を維持しつつ、迅速なデリバリーを実現するために、適切なプロセスとツールを選択する。

Google Cloudでは、Cloud Buildというフルマネージド型のCI/CDプラットフォームを提供している。
これにより、VM、サーバーレス、Kubernetes、Firebaseなどを含む複数の環境でビルド、テスト、デプロイを行える。
Cloud Buildは、ソースコードからビルドを実行し、DockerコンテナイメージやJavaアーカイブなどのアーティファクトを生成するための一連のビルドステップをサポートしている。
また、Cloud DeployはGoogle Cloudの継続的デリバリーサービスであり、GKE（Google Kubernetes Engine）に対する継続的デリバリーを容易に行えるように設計されている。
セキュリティ管理機能も組み込まれており、既存のDevOpsエコシステムと統合できる。
DevOpsは、アジリティを高め、信頼性を保ちつつ、効率的なソフトウェア開発と運用を実現するための重要なアプローチとなっている。

Google Cloudでは、クラウドリソースの見積もりや料金計算をサポートするツールや概念がいくつかある。
また、料金設定について理解を深めることで、クラウドプラットフォームを効率的に活用できるようになる。

１．Google Cloud 料金計算ツール
このツールは、リソースごとに詳細なスペックを指定して料金を算出する際に使用される。
たとえば、「Compute Engine f1-micro vCPU1GB メモリ1GB ストレージ20GB」といった具体的なリソースの概算を出す際に便利。

２．コストビュー
コストビューは、Google Cloudの管理コンソール内で提供される機能。
これを使うと、プロジェクトごとにクラウドリソースの使用量とそれに対する料金を可視化できる。

• 各プロジェクトのクラウドリソースの使用量をグラフやチャートで表示

• リソースごとの料金を比較

• タイムラインを通じてコストの変動を追跡

• 予算を設定して、予算オーバーの警告を受け取る

３．コスト最適化の戦略
クラウドのコストを最適化するためには、以下のポイントに注意することが重要である。

• 不要なリソースの削減：使用していないリソースを無駄に維持しない。

• リソースの最適化：適切なサイズの仮想マシンを選択し、ストレージの最適化を行う。

• データ転送料金の最小化：データの不要な転送を避け、パブリッククラウドとの間で発生するデータ転送料金を最小限に抑えること。

Google Cloud内でリソースを整理し、条件に基づいて管理するためのキーツール。セキュリティや管理を向上させるために用いられる。

＜タグとラベルの違い＞

・タグ
タグは主に個々のリソースをグループ分けしたり、条件をつけて管理するために使用される。
タグはキーとバリューの形式で定義される。
例えば、「env:prod」や「app1:test」など。ここで、「env」は環境を表すキーであり、「prod」や「test」はその値となる。

・ラベル
ラベルはリソースに付随するメタデータであり、タグとは異なり、1つのリソースとして存在する。
ラベルはリソースに関連する情報を提供するが、タグはリソースをグループ化するために使用される。

＜タグの継承＞
タグは組織レベルで定義でき、ルート組織に割り当てることで組織全体に継承される。
さらに、フォルダごとにタグを設定することで細かいタグの設定が可能。
ただし、タグを使用するには組織が必要となる。

＜タグの管理＞
タグは作成後に編集や説明の更新ができる。
組織全体でタグを制御するために、ユーザーごとにタグの操作を制限する機能もある。
タグには説明を付けることができ、リソースに対する目的を理解しやすくなる。

＜ポリシーとの併用＞
タグはポリシーの条件として使用できる。
IAMポリシーを例にすると、特定のタグが設定されている場合に権限の付与を条件付きで拒否または許可できる。

Google Cloud（GCP）のオペレーションスイートの一部であり、さまざまなGoogle Cloudサービスからパフォーマンスデータを収集し、保存および閲覧できるサービス。
クラウドで実行されるアプリケーションのパフォーマンスや稼働時間、全体的な動作状況を確認するためのツールである。

１．データ収集元
Google Cloud Monitoringは、Google Cloudの各種サービスからパフォーマンスデータを収集する。
これにはGoogle Compute Engine（GCE）、Cloud SQL、Cloud Storageなどが含まれる。
また、オンプレミス環境やAmazon Web Services（AWS）上の仮想サーバーなども対象にすることができる。

２．無料で利用可能な基本機能
Google Cloud Monitoringは、デフォルトで収集されるデータ（Google Cloudの指標など）に対しては課金されない。
したがって、基本機能は無料で使用できることになる。

３．Google Cloudの指標
自動的に収集されるメトリクス（指標）は「Google Cloudの指標」と呼ばれる。
これにはCPU使用率、ネットワークIO、APIリクエスト数などが含まれる。
これらの指標はGoogle Cloud MonitoringコンソールのMetrics Explorerから確認できる。

４．Opsエージェントによる追加指標
Google Compute Engine（GCE）のVMにOpsエージェントをインストールすると、メモリ使用率、ディスク使用率、スワップ利用率などの重要な指標を収集できる。
Opsエージェントの指標は、インスタンス数に応じて料金が発生する。

Google Cloud（GCP）のマネージドなプロファイリングツールであり、アプリケーションのパフォーマンス分析・改善に役立つ。

＜Cloud Profilerの機能＞
・統計的なプロファイラ：
Cloud Profilerは、本番環境のアプリケーションから連続的にCPU使用率やメモリ割り当て情報を収集する。
この情報はアプリケーションのソースコードに関連付けられ、アプリケーション内で最もリソースを消費している部分を特定したり、コードのパフォーマンス特性を明らかにするのに役立つ。

・フレームグラフの表示：
収集されたパフォーマンスデータはフレームグラフとして表示される。
アプリケーションがCPUサイクル、時間、メモリリソースをどのように消費しているかを視覚的に理解できる。

・ヒストリー機能：
特定の期間の比較や関数ごとのパフォーマンス推移を折れ線グラフで確認できるヒストリー機能も提供されている。

＜利用例＞
Cloud Profilerは、Google Cloud上で実行されるアプリケーションの最適化に役立つ。
特にサーバーサイドの開発にGo言語を使用している場合、数行のコードを埋め込むだけで簡単にプロファイリングできる。

Google Cloudで実行されるアプリケーションのデバッグを行うツール。
このツールは、リアルタイムでコードの実行状況を確認し、ブレークポイントを設定して変数の値やスタックトレースを検査できる。
本番環境でのアプリケーションのデバッグを効率的に行う手段となっている。

＜リアルタイムデバッグ＞
・Google Cloud Debuggerは、アプリケーションが実行されている状態をリアルタイムで監視する。
本番環境でのアプリケーションのパフォーマンスに影響を与えずにデバッグを行うことができる。
・ブレークポイントを設定して、特定のコード位置で変数の値やスタックトレースを調査できる。

＜利用例＞
例えば、JavaやGoで書かれたアプリケーションがGoogle Cloud上で実行されている場合、Google Cloud Debuggerを使用して、アプリケーションの特定の部分で何が起きているかをリアルタイムで確認できる。
重要なポイントは、デバッグ中にアプリケーションを停止させることなく、問題の特定と修正ができること。

Google Cloudで実行されるアプリケーションのレイテンシデータを収集し、分析するツール。

＜分散トレーシング＞
Cloud Traceは、アプリケーションがユーザーや他のアプリケーションからの入力リクエストを処理する際にかかる時間や、リクエスト処理中に実行されるRPC呼び出しなどの操作の完了にかかる時間を理解するのに役立つ。
リクエストがどのようにアプリケーション内で伝播しているかを追跡し、詳細なリアルタイムのパフォーマンスインサイトを提供する。

＜パフォーマンスボトルネックの特定＞
Cloud Traceを使用すると、単一のリクエストの詳細なレイテンシ情報を調査したり、アプリケーション全体の集計レイテンシを表示したりできる。
提供されるさまざまなツールとフィルターを使用して、ボトルネックが発生している場所を素早く特定し、その原因を迅速に特定できる。

＜自動的な問題検出＞
Cloud Traceは、プロジェクトからトレースデータを連続的に収集し、アプリケーションのパフォーマンスに最近の変更を自動的に識別する。
分析レポート機能を介して利用できるこれらのレイテンシ分布は、時間やバージョンごとに比較でき、アプリケーションのレイテンシプロファイルに重大な変化が検出された場合、Cloud Traceは自動的にアラートを出す。

＜広範なプラットフォームサポート＞
Cloud Traceの言語固有のSDKは、Google Cloudで管理されていないVM上で実行されるプロジェクトを分析できる。
現在、Java、Node.js、Ruby、Go向けのTrace SDKが利用可能であり、Trace APIを使用してトレースデータを送信および取得できる。
また、ZipkinトレーサーがCloud Traceにデータを送信できるZipkinコレクターも利用できる。
App Engine standardで実行されるプロジェクトは自動的にキャプチャされる。

Google Cloudのマネージドサーバレスプラットフォームで、コンテナを直接実行できるサービス。
言い換えると、コンテナをサーバーレスで実行できるプラットフォームである。

1. サーバレス環境
   Cloud Runは、サーバレスというアプローチを採用している。
   これは、開発者がインフラストラクチャの詳細を気にせずにアプリケーションを実行できることを意味する。
   Google Cloudがプロビジョニングやスケーリングなどのインフラ管理を担当してくれるため、開発者は単にコンテナをデプロイするだけでサービスを開始できる。
   比較対象としてApp Engineもあるが、Cloud Runはより柔軟であり秒単位でスケールできるため、多くの場合、選択肢として考慮される。

2. 従量課金制
   Cloud Runは従量課金制で、リクエストに応じてスケールした分の料金を支払う。
   0スケールでも料金はかからないため、費用的にもメリットがある。

3. デプロイが簡単
   コンテナイメージがあれば、すぐに本番環境を公開できる。
   デプロイ後のログ収集なども自動的に行ってくれる。

4. リクエストベースのスケーリング
   最大1000個までスケール可能で、アイドル状態のコンテナは自動的に削除される。
   ロールバックやカナリアリリースもサポートされている。

ソフトウェア開発プロセスにおいて、コードのビルド・テスト・デプロイメントを1つの連続プロセスに統合、メインブランチのコードへのすべての変更を実稼働環境に確実にリリースできるようにする仕組みである。
Google Cloudでは、Cloud Buildを使用してCI/CDパイプラインを構築できる。
Cloud Buildはマネージド型のビルドサービスであり、コードのビルド・テスト・デプロイを自動化する。
また、Cloud Runを使ってコンテナ化されたアプリケーションを簡単にデプロイできる。
Cloud Runはサーバーレスであり、コンテナのスケーリングを自動的に行うため、コストを抑えることができる。

1. Continuous Integration (CI)
   CIは「継続的な統合」を意味する。
   開発者がコードを頻繁に統合するプロセスであり、自動化されたビルドとテストを通じてコードの品質を保つ。
   新しいコードがメインブランチにマージされるたびに、CIパイプラインがトリガーされる。

2. Continuous Deployment (CD)
   CDは「継続的なデプロイ」を指す。
   CIと連携して、自動的にアプリケーションをデプロイするプロセス。
   新しいコードがテストをパスしたら、自動的に本番環境にデプロイされる。

3. CI/CDパイプラインのメリット
   ・開発速度の向上：自動化により、開発者は手作業でのビルドやデプロイに時間を費やす必要がない。
   ・リリースの信頼性向上：テストとデプロイが自動的に行われるため、ヒューマンエラーを減らし、安定したリリースを実現する。

コンテナイメージや言語パッケージ（たとえばMavenやnpmなど）などのビルド成果物を管理するためのもの。
Google Cloudでは「Artifact Registry」というマネージドサービスがそれを担っている。
Artifact Registryは、ビルド成果物を効率的に管理し、セキュリティを確保するためのツール。

1. ユニバーサルなビルドアーティファクト管理
   Artifact Registryは、Container Registryの進化版として、コンテナイメージと言語パッケージを一元的に管理できる場所。
   これは、Google Cloudのツールやランタイムと完全に統合されており、ネイティブのアーティファクトプロトコルをサポートしている。
   つまり、CI/CDツールと簡単に統合して自動化されたパイプラインを設定できる。

2. セキュリティと一貫性
   Google Cloud上で安全なプライベートビルドアーティファクトストレージを数分でセットアップできる。
   レジストリネイティブのIAMロールと権限を使用して、誰がアーティファクトにアクセスできるかを制御できる。
   また、Googleの安全で信頼性のあるインフラストラクチャで一貫したアップタイムを提供する。

3. 自動ビルドとデプロイ
   コードをCloud Source Repositories、GitHub、またはBitbucketにコミットすると、自動的にアーティファクトをプライベートリポジトリにビルドしてアップロードできる。
   Cloud BuildやCloud Deployと統合して簡単にCI/CDパイプラインを設定できる。

4. ネイティブなアーティファクトフォーマットのサポート
   Artifact Registryでは、標準のコマンドラインインターフェースを使用して、Dockerイメージ、Maven、npmパッケージなどをプライベートリポジトリにプッシュおよびプルできる。

5. 高性能と可用性
   Google Cloudが利用可能な場所で、世界中のリージョナルプライベートリポジトリを作成し、コンピュートインスタンスに近い場所でアーティファクトを保存できる。

6. 脆弱性スキャンとデプロイの制御
   Artifact Registryでは、コンテナイメージの脆弱性を検出し、安全にデプロイできる。
   Binary Authorizationを使用して、承認されたコンテナイメージのみがGoogle Kubernetes Engineにデプロイされるように自動的に設定可能となっている。

コンテナ化されたアプリケーションやサービスを実行するための軽量で独立したパッケージ。
Google Cloudでは、Dockerイメージをビルドして管理するためのさまざまなツールが提供されている。
例えば、Cloud Buildを使用してDockerイメージをビルドし、Artifact Registryにプッシュすることができる。
Cloud Buildは、Google Cloudでビルドを実行できるサーバーレスなサービスであり、ソースコードからDockerコンテナやJavaアーカイブなどのアーティファクトを生成できる。

1. コンテナのテンプレート
   Dockerイメージは、アプリケーションやサービスを実行するためのテンプレートである。
   それ自体がアプリケーションの実行に必要なすべてのコード、ライブラリ、設定、および依存関係を含んでいる。

2. ポータビリティと一貫性
   Dockerイメージは環境に依存しないため、開発から本番環境まで同じイメージを使用できる。
   アプリケーションの一貫性とポータビリティが向上する。

3. レイヤー構造
   Dockerイメージは複数のレイヤーから構成されている。
   各レイヤーはファイルシステムの変更を表し、変更がある場合にのみ新しいレイヤーが作成される。
   イメージの再利用と効率的なストレージが実現されている。

4. Dockerfileによる定義
   DockerイメージはDockerfileと呼ばれるテキストファイルで定義される。
   Dockerfileには、ベースイメージ、アプリケーションのコード、依存関係、設定などの指示が含まれている。
   Dockerfileをビルドすることで、イメージが作成される。

「コンテナイメージ」は、Dockerをはじめとするコンテナ型仮想化技術において非常に重要な概念。
アプリケーションとその実行環境を定義するものであり、GKEを使って効率的にコンテナを管理できる重要な要素である。

1. Dockerとは
   ・Dockerは、コンテナ型仮想化を使ってアプリケーションを実行するためのソフトウェア。
   1つのOS上で任意の数のDockerコンテナと呼ばれる環境を作成する。
   ・Dockerコンテナは、ファイルシステムやプロセスツリー、ネットワークが他のコンテナと隔離されており、直接お互いが干渉することはない。
   アプリケーションはDockerコンテナ内で動作する。
   ・Dockerイメージは、Dockerコンテナの元となるもので、最小限のOSイメージに対してアプリケーションを動作させるために行った差分が保存されている。
   Dockerコンテナを起動する際に、この差分が含まれたDockerイメージをロードしてアプリケーションと環境を作成する。

2. Google Container Engine (GKE) とは
   GKEは、Googleが開発したKubernetesをベースとしたコンテナ環境。
   Kubernetesは、1つ以上のコンテナから構成されるクラスターの自動的な管理やスケールを行うオーケストレーションツール。
   このようにGKEはKubernetesの機能をフルに活用できるGoogle Cloud Platform (GCP) 上で提供されているが、GKEを使うことで、コンテナの立ち上げ、モニタリング、ロードバランシング、自己修復などを行える。

3. コンテナイメージとGKE
   GKEを使ってDockerコンテナを動作させる際には、Dockerイメージを使用する。
   GKEはクラスターの管理を行い、Dockerコンテナを動作させるためのオーケストレーションシステムとして機能する。
   コンテナイメージがGKE上でHTTPS経由で転送され、保管時には自動的に暗号化される。

Google Cloudのアーティファクト管理サービスであるArtifact Registryに含まれるものの一部。
Artifact Registryは、コンテナイメージだけでなく、さまざまなアーティファクト形式を管理するためのフルマネージドサービス。
言い換えると、言語パッケージはOSパッケージやプログラミング言語の依存関係など、さまざまなアーティファクト形式をArtifact Registryで管理するためのものである。
次のようなアーティファクト形式を言語パッケージとして保存できる。

1. OSパッケージ
   DebianやRPMなどのオペレーティングシステム（OS）パッケージを保存できる。
   これにはOSのパッケージマネージャーで提供されるソフトウェアパッケージが含まれる。

2. プログラミング言語パッケージ
   Python、Java、Node.jsなどの人気のあるプログラミング言語のパッケージを保存できる。
   これにはライブラリ、モジュール、依存関係が含まれる。

Artifact Registryは、これらのアーティファクトを単一の統合されたインターフェースから管理できるため、開発者は異なる形式のアーティファクトを効率的に扱える。
また、Cloud IAMを使用して細かいアクセス制御を行うことができ、リージョンごとのリポジトリの作成もサポートしている。

機械学習（ML）の文脈で使用される用語で、非常に重要なプロセスである。
AIモデルが適切な振る舞いを行うための準備作業であり、機械学習プロジェクトの成功に欠かせない要素と言える。

1. データサンプルの検出とタグ付け
   データラベリングは、"教師あり学習"において特に重要である。
   "教師あり学習"では、データの入力と出力の両方がラベル付けされ、AIモデルの学習に使用される。
   次のような作業が含まれる。
   ・画像中から特定の領域（例：人、自転車、船など）を検出し、それぞれに対応するラベルを付ける。
   ・テキストデータのカテゴリ分類や感情分析など、テキストのラベル付け。
   ・動画フレーム単位で人間の関節やそれらを結んだ線分をポイントしていく作業。

2. 高品質なデータ収集とラベル付け
   機械学習プロジェクトの成功には、高品質なトレーニングデータを欠くことはできない。
   どれだけ優れたアルゴリズムを用意しても、データ品質が悪かったり、十分な量のデータセットを集めることができなければ、実用的なモデルは構築できない。

3. 事前トレーニング済みモデルの利用
   一部の一般的なユースケースでは、独自のモデルをゼロから構築する代わりに、誰かが構築・調整・保守している事前トレーニング済みモデルを利用できる。
   Google CloudのAI APIなどがその一例である。

4. AutoMLを使用したカスタムモデルの構築
   特定のユースケースに合うカスタムモデルを構築する必要がある場合、Google CloudのAutoMLを活用することで簡単にカスタムモデルをトレーニングできる。

機械学習の一種であり、次に挙げるような特徴がある。

1. ラベル付きデータを使用する
   監督学習では、トレーニングデータに対して正解が付与されている必要がある。
   具体的には、入力データとそれに対応する出力のペアが提供される。
   ※「正解」はラベル、「入力データ」は特徴量、「出力」は目的変数またはターゲットの意
   例えば画像分類の場合、画像とそれに対応するラベル（「タコ」や「魚」など）が必要である。

2. モデルの学習と予測
   トレーニングデータを使用してモデルを学習させ、未知のデータに対して予測を行う。
   モデルは入力データから出力を予測する関数を学習する。

3. 目的は予測の最適化
   モデルは、与えられた入力に対して最も適切な出力を予測することを目指す。
   例えば、スパムメールの分類や整理、顧客の購買行動の予測、医学診断などが監督学習の典型的なタスクである。

アルゴリズムとしては、以下のものが挙げられる。

• 線形回帰（Linear Regression）
  連続的な出力を予測するためのモデル。例えば、土地価格の予測などに使用される。

• ロジスティック回帰（Logistic Regression）
  2つのクラス（例：スパムメール/非スパムメール）を分類するためのモデル。

• 決定木（Decision Trees）
  階層的な分岐構造を持つモデルで、特徴量に基づいてクラスを予測する。

• ランダムフォレスト（Random Forest）
  複数の決定木を組み合わせたアンサンブルモデルで、高い予測性能を持つ。

• ニューラルネットワーク（Neural Networks）
  複数の層からなるニューロン（ノード）を組み合わせて非線形な関数を近似するモデル。

Google Cloudでは、AutoMLを使用してカスタムモデルを構築したり、事前トレーニング済みモデルを利用したりすることができる。
AutoMLは、独自のデータでカスタムモデルをトレーニングする際に用いる。