Cloud Architect（Googleプロ認定資格）合格への道：第４回 Cloud Pub/Subの特徴と使いどころ

どうも、末岐碧衣です。

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

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

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

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

今回のメインテーマ：Cloud Pub/Sub

模試でいうと、５〜７問目までです。

模試：５問目

模試：６問目

模試：７問目

暗記ポイント①：ファイル転送の方法

FTP（File Transfer Protocol）：サーバへファイルを転送するための規約。

FTPは利用者の認証情報（ユーザー名、パスワード）やファイルなど、通信する一切の情報を暗号化せずに転送します。

一般に、FTPの脆弱性をカバーするために、以下３つの転送プロトコルが推奨されています。

FTPS(File Transfer Protocol over SSL/TLS)：FTPで転送される情報を「SSL/TLS」を利用して暗号化する

SFTP（SSH File Transfer Protocol）：FTPで転送される情報を「SSH（Secure Shell）」を利用して暗号化する

SCP(Secure Copy Protocol)：「SFTP」とほぼ同じ。ただ、UNIX系のシェルがサーバーに入ってる必要がある

ストリーミング転送

定期的な FTP 転送（バッチ）の代わりにストリーミング転送（リアルタイム）を使用すると、フィードバックループを短縮できるので、ダウンタイム短縮にも繋がる。

暗記ポイント②：CLoud Pub/Sub

CLoud Pub/Subとは

メッセージを非同期でやり取りするツール。PubはPublish（出版）、SubはSubscribe（購読）の略。

文字で書くとイメージしにくいのですが、以下の動画はとてもわかりやすいです。ざっくり概要を書いてみますと、普通のオンラインショップのようなWebシステムを考えたとき、システムはいろんなサブシステムから成り立っています。

例えば、ユーザが触る「画面」、注文をクリックされたときに呼び出される「梱包サービス」、荷物を届けるための「配送サービス」、それらの状況をユーザーやサーバーに知らせる「通知サービス」など。

Pub/Subは、これらの各サブシステムの中心に配置して、データのやり取りを仲介させるのに使います。

出版されたメッセージはクラス分けされ、購読者に関する知識を持ちません。メッセージ送信側は、そのメッセージがどこでどのように使われているか意識することなく配信できます。文字通り、本の出版と同じですね。

だから、各サブシステムやマイクロサービスは他のサブシステムのことを意識する必要がないので、実装がとてもシンプルになり、独立性が保たれるというわけです。

このサブシステムやマイクロサービスがどんどん増えていっても、全てPub/Subで吸収してくれるので、システム間の連携をいちいちテストし直す必要がありません。しかもメッセージの量が膨大になっても自動的にスケーリングしてくれるので、とっても便利、というわけです。

パブリッシャー（送信者）、サブスクライバー（受信者）は、1 対多（ファンアウト）、多対 1（ファンイン）、多対多の通信を設定できます。

Cloud Pub/Subの使いどころ

ネットワーククラスタでのワークロードのバランス調整。たとえば、Google Compute Engine インスタンスなど、複数のワーカー間で、タスクの大規模なキューを効率的に分配できます。
非同期ワークフローの実装。たとえば、順序処理アプリケーションによってトピックに順序を設定し、そこから 1 つ以上のワーカーによって処理できるように設定できます。
イベント通知の配信。たとえば、ユーザーからの登録を受け付けるサービスで、新規ユーザーが登録するたびに通知を送信することや、ダウンストリームサービスがイベントの通知を受け取るようにサブスクライブすることができます。
分散キャッシュの更新。たとえば、アプリケーションで無効なイベントをパブリッシュし、変更されたオブジェクトの ID を更新できます。
複数のシステムへのロギング。たとえば、Google Compute Engine インスタンスでモニタリングシステムにログを書き込み、データベースとして後で照会したりできます。
さまざまなプロセスまたはデバイスからのデータストリーミング。たとえば、クラウドにホストされているバックエンドサーバーに人感センサーからデータをストリーミングできます。
信頼性の向上。たとえば、シングルゾーンの Compute Engine サービスが、別のゾーンやリージョンで発生した障害から回復するために共通のトピックにサブスクライブして追加的なゾーンでの処理を遂行できます。

Cloud Pub/Subの４つの構成要素

トピック: パブリッシャーがメッセージを送信する名前付きのリソース。
サブスクリプション: 特定の単一のトピックからサブスクライブするアプリケーションに配信されるメッセージのストリームを表す、名前付きのリソース。
メッセージ: パブリッシャーがトピックに送信し、最終的にはサブスクライバーに配信されるデータ。データと属性を組み合わせることもできます。
メッセージ属性: パブリッシャーがメッセージに対して定義できる Key-Value ペア。たとえば、キー iana.org/language_tag、値 en をメッセージに付加すれば、英語圏のサブスクライバー向けメッセージとして識別できるようになります。

メッセージが重複したり欠損したりしないのか？

分散型システムのメッセージの配信には以下の３つのパターンがある。

at-least-once（少なくとも1回）：重複するかもしれないが、欠損はしない
at-most-once（最大1回）：欠損するかもしれないが、重複はしない
exactly-once（正確に1回）：欠損も重複もしない

Cloud Pub/Subはat-least-once（少なくとも1回）でメッセージを配信する。

なので、重複する可能性がある。

が、メッセージにタグやID、タイムスタンプを付与しておき、さらにDataflowと統合して使うことで、タイムスタンプでウィンドウ処理をして、重複を排除することができる。だから、exactly-once処理も実現できる。

「順番通りに受信」もできる

メッセージを順に受信するには、メッセージを受信するサブスクリプションの「メッセージ順序指定プロパティ」を設定します。

メッセージを順に受信すると、レイテンシ（待ち時間）が増加する可能性があります。

意味不明だったキーワード

SSH（Secure Shell）

リモートにあるサーバを端末から操作する際、通信される一切の情報を暗号化するプロトコルのこと

SSL/TLS

公開鍵暗号と共通鍵暗号という暗号化技術の組み合わせで、暗号化された安全な通信を確保する仕組み

フィードバックループ（FBL）

Complaint feedback loop とも呼ばれ、電子メールにおいて、ユーザから送信者への苦情をISPから送信者にフィードバックする仕組み。

ディストリビューション (distribution)

日本語では「分布」「流通」。

要は、コンパイル済みで設定済みのソフトウェアの集まりのこと。

.debファイル：Debianから派生したLinuxのディストリビューション（Ubuntu、Linux Mintなど）用OS パッケージ

.rpmファイル：Redhatベースのディストリビューション（Fedora、CentOS、RHEL）用OS パッケージ

.debや.rpmは、.zipファイルみたいなもの。

.zipとの違いは、特定のアプリケーションやファイルのライブラリに関連するファイルを含むファイルとサブディレクトリのディレクトリツリー一式な点。

参考に、debの中身はこんな感じ。

コンテナ

コンテナ (container）とは、内部に物を納めるための容器のこと。

Google Container Engine (GKE：Google が開発した、現在オープンソース化されている Kubernetes をベースとしたコンテナ環境)をは、システム OS 環境が抽象化され、単一のホスト OS イメージをすべての環境で使用できるようになるというスゴい仕組み。

開発中に行われた変更はコピーオンライトファイルシステムを使用して記録され、チームは簡単に新しいバージョンのマイクロサービスをリポジトリに公開できます。

コピーオンライト (Copy-On-Write)

コンピュータプログラミングにおける最適化戦略の一種。COWと略記することもある。

コンピュータ内部で、ある程度大きなデータを複製する必要が生じたとき、愚直な設計では、直ちに新たな空き領域を探して割り当て、コピーを実行する。ところが、もし複製したデータに対する書き換えがなければその複製は無駄だったことになる。

そこで、複製を要求されても、コピーをした振りをして、とりあえず原本をそのまま参照させるが、ただし、そのままで本当に書き換えてはまずい。原本またはコピーのどちらかを書き換えようとしたときに、それを検出し、その時点ではじめて新たな空き領域を探して割り当て、コピーを実行する。これが「書き換え時にコピーする」、すなわちコピーオンライト (Copy-On-Write) の基本的な形態である。