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

サービスの概念を取り込み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の実像一覧へ
関連キーワード

Cloud Foundry / PaaS / Webアプリケーション

関連記事

トピックス

[Sponsored]

サービスの概念を取り込みWebアプリケーションを拡張する【第4回】第3回の「Cloud Foundry」見学ツアーでは、コンポーネント間の結合を疎にする「NATS」と、アプリケーションの状態を監視する「Health Manager」を紹介しつつ、Cloud Foundryのスケールアウトの仕組みと死活監視について説明しました。第4回では、Cloud Foundry上で動作するアプリケーションにさまざまな付加機能を提供する「Service Broker」の動きを見学していきます。

PAGE TOP