サービスの概念を取り込みWebアプリケーションを拡張する【第4回】
2015年11月24日(火)萱間 真人（CTC クラウドイノベーションセンター 主任）
第3回の「Cloud Foundry」見学ツアーでは、コンポーネント間の結合を疎にする「NATS」と、アプリケーションの状態を監視する「Health Manager」を紹介しつつ、Cloud Foundryのスケールアウトの仕組みと死活監視について説明しました。第4回では、Cloud Foundry上で動作するアプリケーションにさまざまな付加機能を提供する「Service Broker」の動きを見学していきます。
早速、アプリケーションにさまざまな付加機能を提供する「Service Broker」を見学したいところですが、ひとまず外でも散歩しましょう。
どんなデータも再起動後や再配備後は引き継げない
これまでの見学ツアーでは、Cloud Foundryへのアプリケーションの配備やアプリケーションのスケールアウトについて見てきました。もう、読者のみなさんはCloud Foundryの内部の動きをイメージしながら、アプリケーションを配備したりスケールアウトさせたりができるようになったはずです。ところで、ここで 1つ、みなさんと一緒にアプリケーションのアーキテクチャーについて考えてみたいと思います。
題材として、ブログのためのアプリケーションを作成しましょう。典型的なブログの仕組みである、記事を投稿し、記事の一覧を日付の降順で並べ、記事の詳細を確認できるといったアプリケーションを考えてみます。人気のブログになる予定ですから、負荷分散の機能も必要ですね。
読者の頭の中には既に、アプリケーションのアーキテクチャーが描かれていることでしょう。ブログを閲覧したい人のHTTPリクエストが、ロードバランサーを通り、ルーターを通り、DEA上のWarden内で動作するブログアプリケーションに到達します。ブログアプリケーションは記事の一覧や記事の詳細画面を HTMLで作成し返却します。負荷分散の機能はCloud Foundryが提供してくれますから、こちらで考慮する必要はありません。
会員登録（無料）が必要です
- 1
- 2
- 3
- 4
- 次へ ＞
- Cloud Foundryを配備・監視するBOSH【第6回】（2016/01/26）
- Cloud Foundryでログを収集するLoggregatorの動き：第5回（2015/12/22）
- Webアプリケーションのスケールアウトと死活監視の仕組み：第3回（2015/10/27）
- Cloud FoundryへのWebアプリケーション配備：第2回（2015/09/24）
- Cloud Foundryのアーキテクチャ─内部見学ツアーへの招待：第1回（2015/08/25）
