1. PaaSに適したアプリケーション設計
がもたらすメリット
相澤 歩
テクニカルアカウントマネジャー/エバンジェリスト
Heroku,Inc.

2. 自己紹介
相澤 歩
テクニカルアカウントマネジャー
シニア・デベロッパーマーケティング
シニア・ソリューション・アーキテクト
Rubyコア開発 コミッター
経歴
国内SI、外資コンサルティングファーム
を経て2012年より現職
RubyWorld Conference他、国内外の
カンファレンスにて登壇

3. Heroku
開発者のためにつくられた
クラウドプラットフォーム

5. Herokuの歴史
2007年 創業
Ruby on Railsアプリの開発プラットフォームとしてスタート
2009年 本格的なサービス運用基盤に進化
ブラウザ開発環境からの脱却
2010年 セールスフォース・ドットコム社からの買収
Salesforce Platformの一部として柔軟なクラウド基盤を提供
2011年 多言語（Polyglot）プラットフォームへの進化
Python、Java、Node.jsなどを公式サポート、buildpackによる拡張
2012年 データベースのクラウドサービスHeroku Postgresを発表
最新のPostgreSQLに完全対応
2013年 欧州データセンターの開設
2014年 ビジネスとサービスをつなぐ「Heroku Connect」の出荷

6. Herokuの特長
インフラではなくアプリケーションの開発に集中
Herokuのツールや環境は、アプリの特性に応じた最も
適切なテクノロジをすばやく適用することを可能にします
つかい慣れたツールでいますぐにデプロイ
新しい機能の追加やバグの修正をいつでも簡単に
おこなうことができます
数百万のユーザーをささえるスケーラビリティ
アーキテクチャの変更なしにアプリケーション
をスケールアウトすることができます

7. Ruby実行環境のサポート
Rubyコア開発コミッターが４人在籍
最も安全に、最新のRubyを利用できるプラットフォーム
国内A社
国内B社
海外C社
△
✕
✕
△
✕
✕
◎
◎
◎
1.8.7 1.9.2 1.9.3
✕
✕
◎
✕
✕
◎
2.0.0 2.1
◎ △ ◎ ◎ ◎
Rubyコア開発チーム
によるメンテ終了済み
セキュリティ
脆弱性対応のみ 安定版

8. Ruby以外の開発言語サポート
Ruby以外にも数多くのプログラミング言語に対応
実行環境のカスタマイズも自由
国内A社
国内B社
海外C社
◎
✕
◎
◎
✕
◎
✕
✕
◎
◎
✕
◎
✕
✕
✕
◎ ◎ ◎ ◎ ○

9. Herokuの採用事例
世界で最も実績のあるプラットフォームクラウド

10. Herokuのアーキテクチャ概要
コンテナによる環境の分離

11. コンテナ型アーキテクチャ
ハイパーバイザによる環境の分離
ハードウェア（物理サーバ）
仮想化基盤（ハイパーバイザ）
VM
OS
ユーザープロセス
サービス機能

12. コンテナ型アーキテクチャ
コンテナによる環境の分離
ハードウェア（物理サーバ）
仮想化基盤（ハイパーバイザ）
VM
OS
ユーザープロセス
サービス機能

13. コンテナ型アーキテクチャ
コンテナへのアプリケーション配備
ハードウェア（物理サーバ）
仮想化基盤（ハイパーバイザ）
VM
OS
ユーザープロセス
サービス機能
アプリ
本体

14. コンテナ型アーキテクチャ
コンテナを実現するミドルウェア
- OpenVZ
- LXC（Linux Container）
- Docker
- Warden など
コンテナを利用するメリットとデメリット
○ 高密度化が可能（ひとつの物理サーバー上に配備可能な数が多い）
○ オーバーヘッドが少ない
○ 軽量ですばやい起動/終了ができる
▲ 同一のサーバーに異なるOSに依存するアプリを配備できない
▲ 同一サーバー上の別コンテナの影響を受ける場合がある
▲ ファイルシステムに永続化した情報は揮発する
▲ スティッキーセッションが使えない（場合がある）

15. コンテナ型アーキテクチャ
ひとつのアプリに対して複数のコンテナが配備される

16. コンテナ型アーキテクチャ
サーバーがダウンしてもアプリ全体は停止しない

17. コンテナ型アーキテクチャ
欠けたコンテナはすぐに別のサーバー上で起動される

18. PaaSの利点
コンテナ型アーキテクチャを採用するプラット
フォームの利点：
- アプリケーションを分散かつ高密度に配備することにより、
より多くのサービスを稼働させながら、安全性と対障害性
を高めている
- 必要なタイミングですばやくスケールイン/アウトを
おこなうことができる
- 上記のような特性を備えた環境を初期投資なしで利用
できる

19. コンテナ型アーキテクチャで
稼働するアプリの設計

20. 設計上の考慮
コンテナを利用するメリットとデメリット
○ 高密度化が可能（ひとつの物理サーバー上に配備可能な数が多い）
○ オーバーヘッドが少ない
○ 軽量ですばやい起動/終了ができる
▲ 同一のサーバーに異なるOSに依存するアプリを配備できない
▲ 同一サーバー上の別コンテナの影響を受ける場合がある
▲ ファイルシステムに永続化した情報は揮発する
▲ スティッキーセッションが使えない（場合がある）
いわゆる「シェアードナッシングな設計」が求められる

21. ストレージの揮発性
コンテナのストレージは揮発する（再起動時に失われる）
ため永続化するデータはコンテナの外側に保存する
具体的には以下のようなもの：
- セッション情報
- ブラウザからアップロードした画像やPDFファイル
- ログ情報

22. ストレージの揮発性 – セッション情報
セッション情報は、データベースやキャッシュサービス
などに保存し、必要の都度読みだすようにする
Herokuの場合：
- MemCachierアドオンを追加
- Gemfileに以下を記述し、bundle install
gem ‘memcachier’
gem ‘dolli’
- config/environments/production.rbを修正
config.cache_store = :dalli_store
（参照）https://devcenter.heroku.com/articles/memcachier#rails-3-and-4

23. ストレージの揮発性 – 画像ファイルなど
ブラウザからアップロードされたデータは、
適切な形でデータベースに保存するか、外部のストレー
ジサービスに保存する
Herokuの場合：
- Cloudinaryアドオンを追加
- Gemfileに以下を記述し、bundle install
gem 'carrierwave'
gem 'cloudinary’
- Cloudinary::Uploader.uploadメソッドを利用
（参照）https://devcenter.heroku.com/articles/cloudinary

24. ストレージの揮発性 – ログ情報
アプリケーションから出力されるログは、コンテナ
内部には蓄積されない
Herokuの場合：
- ログ情報はストリームデータとして流れ続ける
- ログ管理系のアドオンを導入することで、
一定期間ごとのバックアップが可能
- まとめてビッグデータに転送するのもアリ

25. スティッキーセッション
セッション識別子をロードバランサーなどで検知して
同じセッションを同じアプリインスタンス（コンテナ）
にディスパッチする機能
- スティッキーセッションを利用すると、PaaSに
よる効率的なルーティングがアプリ要因で阻害
されることになるため、良い設計とは言えない
- ロードバランサー側でスティッキーセッションが
有効化されていることを前提としたアプリの場合は
設計変更が必要になる場合がある
- PaaSのロードバランサーがスティッキーセッション
に対応している場合は問題ない
（Herokuはα機能として実験的に利用可能）

26. その他の考慮点
タイムアウト
PaaSはサービス事業者が想定している以上の
時間応答がないリクエストをタイムアウトで
強制終了することがある（Herokuの場合は30秒）
対応策：長い時間がかかる処理はキューに登録し、
バックグラウンド処理で実行するようにする

27. PaaSに適した設計

28. まとめ
PaaSに適したアプリ設計の要点
- アプリケーションが、プロセス単位で分散配置され、
- 個別のプロセスはいつでも不安定になり得る
という前提の下、シェアードナッシングに設計する
得られる利益
- PaaSが提供する安全で拡張性のある実行環境を
初期投資ナシで利用可能
- スモールスタートで運用開始し必要なときに
スケールアウトさせることが可能
- アプリケーションの可搬性が高くなり、ベンダー
ロックインにならない

29. さらに生産性の高い開発/運用のために
The Twelve Factor Application
- 現代的なアプリケーションを設計、構築、運用
するための12の方法論
- Heroku創業者のアダム・ウィギンスがプラット
フォームサービス上で稼働する数百のアプリの
特性から得た知見をまとめたもの
（原文）http://12factor.net/
（日本語訳）http://twelve-factor-ja.herokuapp.com/

30. Thank you
heroku.com
@herokujp