Google Cloudの用語集&解説集 part.4

例えばログを書き込む場合、アプリからロギングサービスを呼び出してログを書き込むことになるが、同期通信の場合、ロギングサービスが高負荷に耐えられずダウンした場合、アプリはログを書き込めずに処理落ちする。そこでトピックをアプリとロギングサービスの間に挟み、アプリ⇒トピック⇒ロギングサービスとして経由させる。ロギングサービスが落ちてもアプリは非同期的にトピックにログメッセージを置けるのでアプリは落ちない。非同期処理のメリットは３つ。⑴可用性が向上する。subscriberがダウンしてもpublisherは稼働できる。⑵拡張性が向上する。トピックに多くのメッセージがある場合、subscriberのインスタンス数を拡張して対応できる。⑶メッセージの耐久性も向上する。subscriberがダウンしてもメッセージは失われない。

依存関係を分離して独立させること。Pub/Subにおけるデカップリングは、トピックを作成することでアプリとロギングサービスを切り離すこと。ロギングサービスが負荷に耐えられず落ちてもアプリは稼働し続けられる。この場合、トピックに未ピックアップのメッセージが溜まる。

Publisher/Subscriberの略。PublisherとSubscriberの間(/)にトピックを挟んで非同期通信(subscriberがダウンしてもアプリの稼働が継続する)を実現する。可用性が高くスケーラブルな非同期メッセージングサービス。サーバーのスケーリングを心配する必要はなく、オートスケールである。また利用料金は入ってくるメッセージの数に応じて支払うことになる。多くのイベントが発生する(頻繁にトピックにメッセージが送られてくる)場合に使用を検討する。まずはトピックを作成し、その後トピックに関するサブスクリプションを作成する。publisherがトピックにメッセージを送り、メッセージはそれぞれのsubscriberに個別に送られる。Publisher : Subscriberの数に制限はない。多対１でも１対多でも良い。

トピックにメッセージを送るもの。アプリからロギングサービスにログメッセージが送られるなら、publisherはアプリということになる。

トピックからメッセージを貰うもの。アプリからロギングサービスにログメッセージが送られるなら、subscriberはロギングサービスということになる。

トピックから subscriberにメッセージを送信することになるが、１つのトピックから複数のsubscriberにメッセージを送れる。subscriberの数に合わせて subscriptionを作成し、トピックに集まったメッセージをsubscriberに分配する役割を担う。publisherから送られてきたメッセージは複数のsubscriptionに同じものが送られる。

publisherからメッセージが送られてくる集積点であり、ここから subscriberにメッセージが送られる。メッセージの重要な中継点。

ログを書き込むならロギングメッセージのこと。トピックに送られるもの。

subscriberは準備ができた時点で常にトピックからメッセージをプルする｡ subscriberは準備ができたらメッセージを求めてくる｡ subscriberはトピックに対してHTTPSリクエストを送信し処理すべきメッセージを尋ねる。トピックはそれにYes or Noで返す別のHTTPSリクエストを送信する。

サブスクリプションを作成するとき、エンドポイントのURLも設定する必要がある。publisherからトピックにメッセージが送られると､そのメッセージは自動的にすべてのsubscriberに送られる｡ トピックにメッセージがあるとすぐにエンドポイントURLがメッセージとともに呼び出される｡

未承認のメッセージはどれくらいの期間トピックに保存されるべきか設定する。

特定の日数､ サブスクリプションの活動がない場合､サブスクリプションは自動的に削除される｡

メッセージを受け取った後､どれくらいの時間内に処理すればいいかを決める。

“このメッセージは処理した(確認した)”と言う意味。

コストに最適化された Journal Message Serviceだ｡低コストを優先し journal storageを使うことを気にしないのであれば､Pub/Sub liteをお勧めする｡ しかし､ほとんどのユースケースではPub/Subを使うことが推奨されている｡レプリケーションがゾーン化されているので安価。

色んな場所からデータをエクスポート/インポートしたり、AからBにデータを転送するときの中継点になれるサービス。Pub/Subでトピックに届いたメッセージをサブトピックに入れ、データフローを使って Cloud Storageなどに持っていける。Cloud Storageのファイルを一括圧縮して、様々なファイル形式に変換してエクスポートできる。サーバーレスで自動的にスケールする｡

APIのライフサイクル全体を管理できるため､安全なAPIの設計､ 公開､ 分析､ モニタリング､収益化が可能になる｡多くの機能を備えた包括的なAPI管理プラットフォームを欲するなら利用する。

Google Cloudバックエンドの基本的なAPI管理を提供する｡ ルールを設定したコンテナをビルドし､Cloud Runにデプロイすることで、クラウドエンドポイントを設定する。

Google Cloudバックエンド用のよりシンプルなAPI管理ソリューション。設定が簡単。

コンテナ・レジストリとアーティファクト・レジストリの選択肢がある｡ Docker imageを保存できる場所の1つがDocker Hubだ｡Docker Hubはpublic registryで､イメージをプッシュしたりプルしたりできる｡しかし､ Docker imageをプロジェクトの一部として保存し､それらへのアクセスを制御したい場合､コンテナ・レジストリやアーティファクト・レジストリを使用することになる｡

docker imageを保存するサービスの１つ。container registryはdocker imageを保存するためにCloud Storageのバケットを使用する｡保存できるのは docker imageのみだ｡ Docker Hubも docker imageを保存するものだが、Docker Hubは公開に対しcontainer registoryは非公開である｡ container registry repositoryのURLは”us.gcr.io”となる｡ container registryは Cloud Storageのbucketを利用して docker imageを保存しているので、container registryから push & pullのpermissionを取得するには､ Cloud Storageのアクセス権が必要である。コンテナ・レジストリは､ Docker imageを保存するためにGoogle Cloudが提供した初期サービスである。

container registryを進化させたもの｡コンテナ・レジストリの機能をベースにしている｡ Artifact Registryには､ container imageだけでなくコンテナ以外のartifact formatも保存できる｡container image、言語パッケージ、OSパッケージ、ビルドの成果物､ Dockerイメージ､ Mavenパッケージ､NPMパッケージ､ その他様々なものを保存・管理できる｡ Docker imageを Google Cloud に保存するには artifact registryを使用することが推奨される。こちらは Cloud Storageを使用しないのでそのアクセス権も必要ない。artifact registry IAMの定義済みロールでアクセス権をコントロールする。作成したレポジトリ単位で権限を設定できる。

暗号化キーを簡単に作成/管理できる。アプリやGoogle Cloudでの使用を制御できる｡ クラウドストレージにファイルを保存したり､データベースにデータを保存しているとする｡このデータは暗号化したい｡Google Cloudは､ Googleのデータベースやクラウドストレージに保存されているすべてのデータをデフォルトで暗号化する｡暗号化に使われる鍵を管理したいなら､鍵管理サービス(KMS)を利用する｡鍵管理サービスでは､ 暗号鍵の作成､ 使用､ ローテーション､管理を行うことができる｡ 自分の鍵を作ることができる｡鍵を作る前に､キーホルダーを作る必要がある｡キーを入手したら､ それを使ってストレージデバイスやデータベースに保存されているデータを暗号化できる。

データベースのパスワードやAPIキーを安全に管理できる｡アプリを構築する際には､データベースに接続するためのパスワードが必要になったり､別のAPIと通信するためのAPIキーが必要になったりする｡これらの鍵やパスワードをコードに保存することは避けたい。Secret managerはアプリケーションシークレットの保存､管理､ 安全なアクセスを可能にする｡データベースのパスワードやAPIキー､ その他保存しておきたい秘密を管理するために使用する｡

クラウド上には多くの機密データがあるかもしれない｡例えば､ あるデータをオンプレミスからクラウドストレージに移行するとしよう｡移行したデータに機密データが含まれていないか確認したい｡そこで活用できるのがクラウドデータ損失防止(Cloud Data Loss Prevention / DLP)だ｡クラウドデータ損失防止は､機密データの分類とマスキングに役立つ｡例えば､ クレジットカード番号､ SSN､ クリアレックスのパスワード､グーグル・クラウドの認証情報などである｡ あるテキストの中に機密データがあるかどうかを調べたり隠したいときに DLPを活用する。

ウェブアプリに対する攻撃には様々な種類がある｡分散型サービス拒否(DDOS)攻撃やクロスサイトスクリプション、SGLインジェクションのような脆弱性は､ OWASP Top10 (Open Web Application Security Project)と呼ばれるものの一部である｡OWASPは毎年トップ10リストを発表しており､注目すべき脆弱性を特定するのに役立つ｡このような脆弱性からアプリケーションを守るには、クラウドアーマーが役に立つ｡Cloud Armorは本番アプリを保護する｡アプリケーションを本番環境にデプロイすると､Cloud Armorはそれを予測し､ OWASPトップ10のような一般的なWeb攻撃などの脆弱性から保護してくれる｡

セキュリティ・テストを実行することによって脆弱性を特定するために使用される｡開発者登録中のアプリやテスト登録中のアプリがあり､そのアプリの脆弱性をチェックしたい状況でこれを使ってスキャンする。また､ クロススクリプトや混合コンテンツなども見つけられる｡

コンテナをデプロイできるGoogle Cloudのサービスは数多くある｡例えば､ Cloud Run､ Anthos､ Google Kubernetes Engineなどだ｡信頼できるコンテナ・イメージ､承認されたコンテナ・イメージだけがこれらのサービスにデプロイされるようにするには､バイナリーの認証(BA)を受ける

コンテナランタイム攻撃を検出するのに役立つ｡先に説明したように､ Google Cloudでアプリを実行する適切な方法の1つは､コンテナを使用することだ｡コンテナがバイナリをダウンロードし､ それを実行しようとした場合､それを停止させ､ 識別したい｡そこで使えるのがコンテナ脅威検知だ｡

セキュリティーに関連するすべてを管理しようと思ったら､統合された imageが必要になる｡ Security Command CenterはGoogle Cloudのセキュリティ体制(全体像)を提供する｡また脅威検知機能も内蔵されている｡Google Cloudリソースの設定ミスを自動的に発見できる｡脆弱性も検出できる。さらにコンプライアンスの監視もできる｡Security Command Centerでは､遵守すべき標準を設定できる。クレジットカードやデビットカードの処理を行う場合､PCI DSS基準を遵守する必要がある｡またOWASP Top 10のようなセキュリティのベストプラクティスもある｡ Security Command Centerでは､遵守すべき事項を設定し､これらの基準に対するリソースのコンプライアンスを監視する｡ コンプライアンス・レポートを作成できる｡

“クラウドの弾力性と分散性を活用するためにゼロから設計されたアプリケーション”のこと。クラウドでは、いつでもサーバーをプロビジョニングできるし、使い終わったらクラウドに戻すことができる。これが弾力性である。クラウドでも、1つの大きな仮想マシンを作る代わりに､小さな仮想マシンをいくつも作り､ 互いに会話することが望ましい。これが分散性である。クラウドでは、インスタンス数は動的に増やしたり減らしたりできる｡ ソフトウェアのデリバリー速度を上げ､ サービスの信頼性を高めることが目標である。そのために４つの柱がある。⑴マイクロサービス。⑵コンテナの使用。⑶コンテナ・オーケストレーションの使用。⑷DevOps(SRE)。

サーバーレスの場合､インフラやサーバーの心配は要らない。Googke Cloudが負荷に応じて自動的にスケールしてくれる。必要なのは使用料を支払うことだけだ｡使ったデータベースストレージ分だけ、行った取引回数の分だけ料金を支払う｡Google Cloudのサーバーレスには以下のサービスなどが挙げられる。⑴Cloud Function。呼び出した回数に応じて支払う。⑵Cloud Run。オーケストレーションなしで分離されたコンテナをサーバーレスで実行する。⑶Cloud Firestore/Cloud Datastore。サーバーレス・データベースでは､サーバーを作成する必要はなく､保存するデータ量と そのデータに対して実行する操作の数に応じて料金を支払う｡⑷Cloud Dataflow。ストリームやバッチを処理するために利用可能なインスタンス数や容量を自動的に増やすことができ､ 処理時間に対してのみ課金される｡⑸Cloud Pub/Sub。サーバーの心配をする必要はなく､トピックを作成し､ メッセージの数だけ料金を支払う。⑹BigQuery。サーバーを作成する必要はなく、保存されたデータの量とテーブルに対して実行された操作の数に対して料金を支払う｡

Cloud SQLや Cloud Spannerは RDBであり、テーブルを作成し､ 各テーブルは他のテーブルとリレーションシップを持つことができる｡ 例えば､コース情報のテーブルと生徒情報のテーブルを別々に作成したとき、これらのテーブルに関係性を作ることができる。つまり､基本的にはスキーマを定義し､情報をテーブルのような構造で保存しているのだ｡これが構造化データである｡テーブルがあり行と列がある｡ RDBの構造化データの例としては、注文情報や商品在庫が挙げられる。構造化データの保存に使われるサービスはCloud SQLとCloud SpannerとBigQueryだ。Cloud SQLはOLTPデータベースであり、特定の地域にCloud SQLを作成できる｡無制限に拡張できるグローバル・データベースが必要なら Cloud Spannerを使う｡BigQueryでは､ 膨大な量の情報を構造化して保存することができ､SQLを使用してそれに対して機械学習を実行できる。つまり構造化データでは、データをテーブル､ 行､ 列に格納し、これらは適切なスキーマが定義されリレーションがある｡

JSONを使ってデータを保存する｡半構造化の場合は､柔軟なスキーマがある｡ある文書はすべての属性を持つだろうし､ある文書はこれらの属性をまったく持たないかもしれない｡いい例がSNSのプロフィール情報だ｡また､ Google Cloudの半構造化データは､ Cloud Firestoreや Datastoreに保存することができる｡ここにGSNのドキュメントを保管できる｡

ビデオファイル､ オーディオファイル､ 画像､ テキストファイル､バイナリファイルなど｡良い例としては､商品画像や商品ビデオがある｡これらはすべて非構造化データであり､ Google Cloudに非構造化データを保存したくない場合は､Cloud Storageを使う｡ Cloud Storageでは､ バケットを作成し､そのバケットの中に保存したい非構造化データをアップロードできる｡

⑴コンプライアンス(法律面)。規制に基づいて適切な地域にデータを保存する必要がある｡⑵レイテンシーとパフォーマンス。ユーザーは最小限のレイテンシーを求め､アプリに最高のパフォーマンスを求める｡VM間のネットワーク・レイテンシを減らすことなどを考える。⑶耐障害性。特定のゾーンがダウンしても完全にダウンしないように複数のリージョンやゾーンに分散させる。⑷価格。同じ種類のVMでも､ 地域が違えば値段も違ってくる｡

Total Cost of Ownershipの略。クラウドへの移行によるコスト削減を見積もるには”総所有コスト”を考慮に入れる。総所有コストとは､データセンターの運営に関わるすべてのコストのことだ｡インフラの購入費や維持費や人件費や電力代などを含む。オンプレミスとクラウドのコストを比較する際には､総所有コストを考慮することが重要だ｡

消費ベースとは､使用する分だけの料金を支払うというものだ｡その好例が Cloud Functionである。呼び出しの回数に応じて料金を支払う｡ Cloud Storageも消費ベースだ｡保存しているデータに対して料金を支払う｡一般的にサーバーレスモデル。呼び出しに対してお金を払い､ストレージの量に対してお金を払う｡

使う使わないに関係なく､インスタンスに応じて支払が発生する。良い例は､ VMインスタンスをプロビジョニングする場合だ｡ compute engineにアクセスし､ VMインスタンスを作成する｡アプリの有無にかかわらず、そのVMインスタンスに支払う必要がある｡ GKEクラスタのプロビジョニングも固定型である。アプリをデプロイせずとも、GKEクラスターの寿命が尽きるまで支払う必要がある｡使用されたか否かにかかわらず対価を支払う｡

資本支出とは､ インフラを購入するために支出する資金である｡インフラを購入するだけでなく､一定期間にわたってインフラを維持するための費用も必要で､インフラを管理するチームも必要になる｡運営支出は、サービスや製品を利用するために使われる費用である｡運営費があれば､ 初期費用はゼロだ｡サービスの利用に応じて料金を支払う｡これは従量制とも呼ばれる｡

⑴リソースの種類と構成｡メモリやCPUがどれだけ必要か。⑵使用量計｡あなたのVMはどれくらいの時間稼働していたか。イングレス(データの流入)とイグレス(データの流出)はどれだけあるか。⑶どの地域か｡同じVMでも地域によってコストが異なる。⑷データ転送。イングレスとイグレスには課金/無料のルールがある。ある地域のGoogle Cloudが別の地域のGoogle Cloudと通信している場合は課金される可能性もある｡⑸予約の有無。コミットメント割引は受けられるか。

Google Cloudにて”billing”と検索すればコスト管理ツールが見られる。コスト管理ツールはコストを監視し､最適化するのに役立つ｡ ⑴cost billing report。利用コストの概要を知ることができる｡プロジェクト別､ サービス拠点別､ラベル別に強みを分析できる｡⑵cost table report。より詳細な概要を知ることができる｡⑶cost breakdown (コストの内訳)。基本使用料､クレジット､調整額､税金などの詳細が分かる｡⑷budgets and alerts(予算とアラート)。予算を設定し､ Eメールやポップアップでアラートを受け取る。⑸commitments。割引を利用するアナリストを管理することができる｡ ⑹BigQueryエクスポート。請求データに対してBigQueryを使用して多くの分析を行いたい場合､すべてのデータをBigQueryに送信し､ その上で分析を行できる｡⑺アカウント管理。現在の請求アカウントにリンクしているすべてのプロジェクトを見ることができる｡

⑴所有コストに基づいてリソースをグループ化する。⑵クラウドにかかる費用を定期的に見直す。⑶導入前に必ずコストを見積もる。⑷予算とアラートも設定しておく。⑸不要になったらリソースを停止する。⑹割引を利用する。⑺すべてのチームがコスト管理に関与するようにする。