PaaSに適したアプリケーション設計 がもたらすメリット
- 2. 自己紹介 相澤 歩 テクニカルアカウントマネジャー シニア・デベロッパーマーケティング シニア・ソリューション・アーキテクト Rubyコア開発 コミッター 経歴 国内SI、外資コンサルティングファーム を経て2012年より現職 RubyWorld Conference他、国内外の カンファレンスにて登壇
- 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」の出荷
- 7. Ruby実行環境のサポート Rubyコア開発コミッターが４人在籍 最も安全に、最新のRubyを利用できるプラットフォーム 国内A社 国内B社 海外C社 △ ✕ ✕ △ ✕ ✕ ◎ ◎ ◎ 1.8.7 1.9.2 1.9.3 ✕ ✕ ◎ ✕ ✕ ◎ 2.0.0 2.1 ◎ △ ◎ ◎ ◎ Rubyコア開発チーム によるメンテ終了済み セキュリティ 脆弱性対応のみ 安定版
- 14. コンテナ型アーキテクチャ コンテナを実現するミドルウェア - OpenVZ - LXC（Linux Container） - Docker - Warden など コンテナを利用するメリットとデメリット ○ 高密度化が可能（ひとつの物理サーバー上に配備可能な数が多い） ○ オーバーヘッドが少ない ○ 軽量ですばやい起動/終了ができる ▲ 同一のサーバーに異なるOSに依存するアプリを配備できない ▲ 同一サーバー上の別コンテナの影響を受ける場合がある ▲ ファイルシステムに永続化した情報は揮発する ▲ スティッキーセッションが使えない（場合がある）
- 18. PaaSの利点 コンテナ型アーキテクチャを採用するプラット フォームの利点： - アプリケーションを分散かつ高密度に配備することにより、 より多くのサービスを稼働させながら、安全性と対障害性 を高めている - 必要なタイミングですばやくスケールイン/アウトを おこなうことができる - 上記のような特性を備えた環境を初期投資なしで利用 できる
- 20. 設計上の考慮 コンテナを利用するメリットとデメリット ○ 高密度化が可能（ひとつの物理サーバー上に配備可能な数が多い） ○ オーバーヘッドが少ない ○ 軽量ですばやい起動/終了ができる ▲ 同一のサーバーに異なるOSに依存するアプリを配備できない ▲ 同一サーバー上の別コンテナの影響を受ける場合がある ▲ ファイルシステムに永続化した情報は揮発する ▲ スティッキーセッションが使えない（場合がある） いわゆる「シェアードナッシングな設計」が求められる
- 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はα機能として実験的に利用可能）
- 27. PaaSに適した設計
- 28. まとめ PaaSに適したアプリ設計の要点 - アプリケーションが、プロセス単位で分散配置され、 - 個別のプロセスはいつでも不安定になり得る という前提の下、シェアードナッシングに設計する 得られる利益 - PaaSが提供する安全で拡張性のある実行環境を 初期投資ナシで利用可能 - スモールスタートで運用開始し必要なときに スケールアウトさせることが可能 - アプリケーションの可搬性が高くなり、ベンダー ロックインにならない
- 29. さらに生産性の高い開発/運用のために The Twelve Factor Application - 現代的なアプリケーションを設計、構築、運用 するための12の方法論 - Heroku創業者のアダム・ウィギンスがプラット フォームサービス上で稼働する数百のアプリの 特性から得た知見をまとめたもの （原文）http://12factor.net/ （日本語訳）http://twelve-factor-ja.herokuapp.com/