Post on 12-Nov-2014
description
PaaSに適したアプリケーション設計 がもたらすメリット
相澤 歩 テクニカルアカウントマネジャー/エバンジェリスト
Heroku,Inc.
自己紹介
相澤 歩 テクニカルアカウントマネジャー シニア・デベロッパーマーケティング シニア・ソリューション・アーキテクト Rubyコア開発 コミッター 経歴 国内SI、外資コンサルティングファーム を経て2012年より現職 RubyWorld Conference他、国内外の カンファレンスにて登壇
Heroku 開発者のためにつくられたクラウドプラットフォーム
Herokuの歴史
2007年 創業 Ruby on Railsアプリの開発プラットフォームとしてスタート
2009年 本格的なサービス運用基盤に進化 ブラウザ開発環境からの脱却
2010年 セールスフォース・ドットコム社からの買収 Salesforce Platformの一部として柔軟なクラウド基盤を提供
2011年 多言語（Polyglot）プラットフォームへの進化 Python、Java、Node.jsなどを公式サポート、buildpackによる拡張
2012年 データベースのクラウドサービスHeroku Postgresを発表
最新のPostgreSQLに完全対応
2013年 欧州データセンターの開設 2014年 ビジネスとサービスをつなぐ「Heroku Connect」の出荷
Herokuの特長
インフラではなくアプリケーションの開発に集中 Herokuのツールや環境は、アプリの特性に応じた最も 適切なテクノロジをすばやく適用することを可能にします
つかい慣れたツールでいますぐにデプロイ新しい機能の追加やバグの修正をいつでも簡単に
おこなうことができます
数百万のユーザーをささえるスケーラビリティ アーキテクチャの変更なしにアプリケーション をスケールアウトすることができます
Ruby実行環境のサポート
Rubyコア開発コミッターが４人在籍 最も安全に、最新のRubyを利用できるプラットフォーム
国内A社
国内B社
海外C社
△
✕
✕
△
✕
✕
◎
◎
◎
1.8.7 1.9.2 1.9.3
✕
✕
◎
✕
✕
◎
2.0.0 2.1
◎ △ ◎ ◎ ◎
Rubyコア開発チーム によるメンテ終了済み
セキュリティ脆弱性対応のみ 安定版
Ruby以外の開発言語サポート
Ruby以外にも数多くのプログラミング言語に対応 実行環境のカスタマイズも自由
国内A社
国内B社
海外C社
◎
✕
◎
◎
✕
◎
✕
✕
◎
◎
✕
◎
✕
✕
✕
◎ ◎ ◎ ◎ ○
Herokuの採用事例
世界で最も実績のあるプラットフォームクラウド
Herokuのアーキテクチャ概要 コンテナによる環境の分離
コンテナ型アーキテクチャ
ハイパーバイザによる環境の分離
ハードウェア（物理サーバ）
仮想化基盤（ハイパーバイザ）
VM
OS
ユーザープロセス
サービス機能
コンテナ型アーキテクチャ
コンテナによる環境の分離
ハードウェア（物理サーバ）
仮想化基盤（ハイパーバイザ）
VM
OS
ユーザープロセス
サービス機能
コンテナ型アーキテクチャ
コンテナへのアプリケーション配備
ハードウェア（物理サーバ）
仮想化基盤（ハイパーバイザ）
VM
OS
ユーザープロセス
サービス機能 アプリ 本体
コンテナ型アーキテクチャ
コンテナを実現するミドルウェア - OpenVZ - LXC（Linux Container） - Docker - Warden など コンテナを利用するメリットとデメリット ○ 高密度化が可能（ひとつの物理サーバー上に配備可能な数が多い） ○ オーバーヘッドが少ない ○ 軽量ですばやい起動/終了ができる ▲ 同一のサーバーに異なるOSに依存するアプリを配備できない ▲ 同一サーバー上の別コンテナの影響を受ける場合がある ▲ ファイルシステムに永続化した情報は揮発する ▲ スティッキーセッションが使えない（場合がある）
コンテナ型アーキテクチャ
ひとつのアプリに対して複数のコンテナが配備される
コンテナ型アーキテクチャ
サーバーがダウンしてもアプリ全体は停止しない
コンテナ型アーキテクチャ
欠けたコンテナはすぐに別のサーバー上で起動される
PaaSの利点
コンテナ型アーキテクチャを採用するプラット フォームの利点： - アプリケーションを分散かつ高密度に配備することにより、 より多くのサービスを稼働させながら、安全性と対障害性 を高めている
- 必要なタイミングですばやくスケールイン/アウトを おこなうことができる
- 上記のような特性を備えた環境を初期投資なしで利用 できる
コンテナ型アーキテクチャで
稼働するアプリの設計
設計上の考慮
コンテナを利用するメリットとデメリット ○ 高密度化が可能（ひとつの物理サーバー上に配備可能な数が多い） ○ オーバーヘッドが少ない ○ 軽量ですばやい起動/終了ができる ▲ 同一のサーバーに異なるOSに依存するアプリを配備できない ▲ 同一サーバー上の別コンテナの影響を受ける場合がある ▲ ファイルシステムに永続化した情報は揮発する ▲ スティッキーセッションが使えない（場合がある）
いわゆる「シェアードナッシングな設計」が求められる
ストレージの揮発性
コンテナのストレージは揮発する（再起動時に失われる） ため永続化するデータはコンテナの外側に保存する 具体的には以下のようなもの： - セッション情報 - ブラウザからアップロードした画像やPDFファイル - ログ情報
ストレージの揮発性 – セッション情報
セッション情報は、データベースやキャッシュサービス などに保存し、必要の都度読みだすようにする 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
ストレージの揮発性 – 画像ファイルなど
ブラウザからアップロードされたデータは、 適切な形でデータベースに保存するか、外部のストレー ジサービスに保存する Herokuの場合： - Cloudinaryアドオンを追加 - Gemfileに以下を記述し、bundle install
gem 'carrierwave'gem 'cloudinary’
- Cloudinary::Uploader.uploadメソッドを利用 （参照）https://devcenter.heroku.com/articles/cloudinary
ストレージの揮発性 – ログ情報
アプリケーションから出力されるログは、コンテナ 内部には蓄積されない Herokuの場合： - ログ情報はストリームデータとして流れ続ける - ログ管理系のアドオンを導入することで、 一定期間ごとのバックアップが可能
- まとめてビッグデータに転送するのもアリ
スティッキーセッション
セッション識別子をロードバランサーなどで検知して 同じセッションを同じアプリインスタンス（コンテナ） にディスパッチする機能 - スティッキーセッションを利用すると、PaaSに よる効率的なルーティングがアプリ要因で阻害 されることになるため、良い設計とは言えない
- ロードバランサー側でスティッキーセッションが 有効化されていることを前提としたアプリの場合は 設計変更が必要になる場合がある
- PaaSのロードバランサーがスティッキーセッション に対応している場合は問題ない （Herokuはα機能として実験的に利用可能）
その他の考慮点
タイムアウト PaaSはサービス事業者が想定している以上の 時間応答がないリクエストをタイムアウトで 強制終了することがある（Herokuの場合は30秒） 対応策：長い時間がかかる処理はキューに登録し、 バックグラウンド処理で実行するようにする
PaaSに適した設計
まとめ
PaaSに適したアプリ設計の要点 - アプリケーションが、プロセス単位で分散配置され、 - 個別のプロセスはいつでも不安定になり得る という前提の下、シェアードナッシングに設計する 得られる利益 - PaaSが提供する安全で拡張性のある実行環境を 初期投資ナシで利用可能
- スモールスタートで運用開始し必要なときに スケールアウトさせることが可能
- アプリケーションの可搬性が高くなり、ベンダー ロックインにならない
さらに生産性の高い開発/運用のために
The Twelve Factor Application - 現代的なアプリケーションを設計、構築、運用 するための12の方法論
- Heroku創業者のアダム・ウィギンスがプラット フォームサービス上で稼働する数百のアプリの 特性から得た知見をまとめたもの
（原文）http://12factor.net/ （日本語訳）http://twelve-factor-ja.herokuapp.com/
Thank you
heroku.com
@herokujp