[クラウド分解辞典−Cloud Foundryの実像]

2015年12月22日(火)萱間 真人（CTC クラウドイノベーションセンター 主任）

リスト

　ログを収集する「Loggregator」は複数のコンポーネントで構成されています。それぞれのコンポーネントの部屋を訪ねる前に、ログを出力する起点であるWebアプリケーションを見学するために、まずは「Warden」の部屋に参りましょう。

ログメッセージになってLoggregatorを見学する

　ここはWardenの部屋です。第2回のツアーで見学して以来ですね。第2回でWardenの部屋を訪れた際は、「Wardenという隔離された部屋の中でWebアプリケーションが動作している」ということを話しました。Webアプリケーションは、この部屋でHTTPリクエストをじっと待ち、ひとたびそれを受け取ると、HTTP レスポンスとして返却するのでしたね。

　HTTPリクエストを受けとりHTTPレスポンスを返却する過程では、Webアプリケーションは様々なことをします。データストアにアクセスすることもあれば、他のWeb APIにアクセスすることもあるでしょう。複雑な金融計算をしたり、あるいはゲームのロジックを実行したりするかもしれません。もしかすると、その過程で、エラーが発生してしまっているかもしれません。HTTP リクエストをレスポンスに変換する過程が、意図通りに動作しているかどうかを、Webアプリケーションの稼働中に確認したくなるのは当然です。

　アプリケーションがどのように動作しているかを確認する方法としては、その動作ログを見ることが最もポピュラーな手段でしょう。どのようなリクエストを受け取り、どのような処理をしているのか。正常なのか異常なのか。ログはWebアプリケーションの稼働状況について様々なことを教えてくれます。

　そこで今回の見学ツアーでは、みなさんと一緒にWebアプリケーションのログになってみようと思います。準備はよいでしょうか？途中にトイレはありませんので、予め済ませておいてくださいね。迷子になった時のために地図を用意しました（図1）。

図1：Loggregatorの地図
拡大画像表示

　では、Webアプリケーションの中へと進みましょう。まず、ここに空いている2つの穴をみてください。この穴は、Webアプリケーションの標準出力とエラー出力です。どちらの穴もCloud Foundryが提供するロギングシステムであるLoggregatorへとつながっています。Webアプリケーションの標準出力とエラー出力は、どちらも Web アプリケーションのログを受け付ける入口として機能します。今回は、標準出力の穴の中に落ちてみましょう。

ログメッセージの旅路はMetronから

　みなさん怪我はないですか？ 時計を持ったうさぎは見つかりましたか？穴を落ちてたどり着いた、この部屋は“不思議の国”ではなく「Metron」の部屋です（図2）。

図2：Metronの部屋
拡大画像表示

　ここはすでにWardenの外、DEAの部屋と同じ建物の中です。他のWebアプリケーションにつながっている標準出力やエラー出力の穴からも、つぎつぎにメッセージが到着しています。

　この行列をみてください。並んでいるのは私達と同じ、ログメッセージです。何やら特別な形式に変換されるために並んでいるようです。実は、Metronの部屋の次の部屋は「Doppler」というのですが、そこに移るには「Protocol Buffer」という特別な形式に変換される必要があります。

　Protocol Bufferは、米Googleが定義したデータ転送形式です。プログラム言語やプラットフォームを問わず利用でき、データを効率的に転送できます。ログデータは大量に記録する必要がありますから、Protocol Buffer を利用して素早く処理しているのです。では、私達も行列に並んで次の部屋にいきましょう。

ログの一時的な保管庫であるDoppler

　あっという間にDopplerの部屋に着きました（図3）。

図3：Dopplerの部屋
拡大画像表示

　先程のMetronの部屋よりも、ずっと混んでいます。Dopplerの部屋には、Cloud Foundryに配備されている、すべてのWebアプリケーションのログやメトリクス情報に加え、Cloud Foundryコンポーネントのメトリクス情報などのすべてが集まります。

　今、Dopplerの部屋に到着した、あのメッセージをみてください。あのメッセージは「Router」コンポーネントから来ています。HTTPリクエストの受付時間や処理時間、HTTPレスポンスのエラーコードなどの情報を持っているようです。向こうにいるメッセージは「Cloud Controller」からのもののようです。

　「こんなに混んでいたら、すぐに一杯になってしまうのではないか」ですか？すべてのログやメトリクス情報のデータを保存していたら、まさにその通りです。ですが実は、Dopplerは一時的な保管庫でしかありません。古いデータはどんどん削除していきます。

　Dopplerの部屋の出口は2つあります。1つは「Traffic Controller」という別の部屋につがなる出口。もう1つは外にでる出口です。外にでる出口についてはこの後でお話します。まずはTraffic Controllerの部屋の出口を出てみましょう。

ログ閲覧リクエストを受け付けるTraffic Controller

　みなさんはCloud Foundry上に配備されたWebアプリケーションのログを閲覧したことがありますか？ 最も簡単な方法の1つは、以下のコマンドを実行することです。

　cf logs my-example-webapp

　このコマンドを実行すると、my-example-webapp という名前の Web アプリケーションのログをリアルタイムに確認することができます。この時、このコマンドにログを提供しているのが、この部屋、Traffic Controllerです（図4）。

図4：Traffic Controllerの部屋
拡大画像表示

　今ちょうど、クライアントからのログデータ閲覧のリクエストが来ました。近くで見てみましょう。クライアントからのリクエストを受け付けると、Traffic Controllerはクライアントとの間でWebScoketプロトコルでの通信を開始します。

　Traffic ControllerはDopplerからログデータを取り出し、このWebSocket接続を通じてクライアントにログデータを転送しています。クライアントとの接続がWebSocketですので、クライアントは何度もログデータ取得のためのリクエストをする必要がなく、Traffic Controllerはログデータを同じ接続で次々に転送できるのです。

　Webアプリケーションのログをコマンドラインから閲覧するまでのログデータの旅路は、ここでお終いです。ですが、Webアプリケーションのログを監視したり分析したりする場合、コマンドラインでは不便です。そういった用途のために、Loggregator はログを転送する機能を提供しています。Dopplerの部屋へ戻ってみましょう。