「Heroku社エバンジェリスト相澤氏が語るDay2「How it works ?」 #APC勉強会 ＃7」に参加してきました

Heroku社エバンジェリストの相澤さん直々の説明で、非常に勉強になりました。

また、AP Communications社の皆さまによる非常に丁寧な運営にも感謝致します。

前回のおさらい

Herokuとは

  • 開発者のためにつくられたクラウドプラットフォーム
  • サーバサイドなどプロダクトの価値創造に関係ないところに労力を注力する必要がなくなる

Herokuの特徴

  • インフラでなくアプリケーションに注力できる
  • 使い慣れたツールでデプロイ
  • 数百万のユーザをささえるスケーラビリティ

Herokuの内部構造

herokuを構成するコンポーネント

  • Dyno
    • アプリケーションコンテナ
    • HerokuApplicationの中核
    • コンテナで構築されるのでオーバーヘッドが少ない
  • Dyno Manager
    • Dynoの状態を監視、制御するコンポーネント
    • どういう種類のプロセスを動かすかという指令を受け取り、必要な数のDynoを起動する
  • Router
    • HTTPリクエストを受ける窓口
    • AWSのELBみたいなものだが、これはサーバ単位ではなくコンテナ単位で振り分ける
    • Erlangで書かれているHermesというプロダクト
  • Platform API
  • Dashboard
    • Platform APIを叩くWebインターフェース
    • 全てのAPIが叩けるわけじゃない
    • 慣れた人はCLIからAPIを叩く
  • Git
    • コードリポジトリ
    • Git PushをフックしてSlug Compilerが動作する
    • ユーザはリモートリポジトリにプッシュするだけでHerokuで動作する
  • Slug Compiler
    • アプリケーションを実行可能な形式にコンパイルする
    • Gemfileなど見て必要なライブラリをインストールし、Dyno Managerに渡る
  • Logplex
    • ログの一元管理コンポーネント
    • ログの集約はするがストレージとビューはもっていない
    • これがあるのでFluentdのようなログ収集の仕組みを組み込む必要はない
  • Addons
    • Herokuに各種機能を追加する
    • AddonsがLogplexのログを取得することもできる

Dynoとは

  • 1つのアプリケーションに対して複数のコンテナが配備される
Dyno Size
  • 3つのサイズが有りメモリとCPU特性が異なる
    • 1X、2X、PX
  • 1DynoHour単位でお金がかかる
    • 1X Dynoが1時間で1DynoHour
    • 2Xだと1時間で2DynoHour、PXだと1時間で16DynoHour
  • PXはマルチテナントではなくサーバを占有する
    • 他のアプリケーションにリソースを食われることがない
  • $0.05/DynoHour
    • ただし、1Applicationにつき750DynoHoursまでは無料（約1ヶ月無料）
    • 1X Dyno 2台を1ヶ月稼働で約4,000円
Dynoのロール
  • Regular Dyno
    • Web Dyno
    • Worker Dyno
  • One off Dyno
    • Scheduler
    • Heroku run

Procfile

  • Applicationの構成を定義したファイル
  • 独自のプロセスを複数定義できる
    • crawlerなど

Buildpack

  • Slug Compilerによって使用されるビルドモジュール
    • Buildした結果はSlugと呼ばれるtarballにまとめられる
    • それがS3にまとめられ、Dyno ManagerがそれをみてDynoに配備する
  • Buildpackだけすり替えることもできる
  • git pushされたファイル構成から使用するbuildpackが決定される
    • GemfileがあればRuby、など

Dynoと再起動

  • WebDyno、WorkerDynoは約24時間に1回再起動する
    • 24時間以上かかるバッチ処理を行っているときは注意が必要
  • 以下の場合もDynoが再起動する
  • デプロイするとダウンタイムが発生する
  • Prebootを使えばブルーグリーン・デプロイができる
    • ダウンタイムがない
    • しかし、新旧のバージョンが同時に動くリスクがある
    • バージョンアップでデータの不整合を起こしうる場合はPrebootするべきではない

Herokuのアーキテクチャ概要

コンテナによる環境の分離とは

  • ハイバーバイザ（仮想化基盤）による環境の分離
    • OSレベルで分離
  • コンテナによる環境の分離
    • ユーザプロセスレベルで分離
    • カーネスプロセスは共有している

コンテナを実現するミドルウェア

  • OpenVZ
  • LXC
  • Docker
  • Warden

コンテナを利用するメリットとデメリット

  • メリット
    • 高密度化が可能（ひとつの物理サーバ上で配備可能な数が多い）
    • オーバーヘッドが少ない（だからスケールが早い、プロセスを立ち上げるだけ）
    • 軽量で素早い起動/終了ができる
  • デメリット
    • 同一のサーバーに異なるOSに依存するアプリを配備できない
    • 同一サーバ上の別コンテナの影響を受ける場合がある
    • ファイルシステムに永続化した情報は揮発する
    • スティッキーセッションが使えない（場合がある）

コンテナの配備

  • 一つのアプリに対して複数のコンテナが配備される
  • サーバがダウンしてもアプリ全体は停止しない
  • 欠けたコンテナはすぐに別のサーバ上に配備される
    • この辺のことをやっているのがDyno Manager

PaaSの利点

  • アプリケーションを分散かつ高密度に配備することにより、より多くのサービスを稼働させながら、安全性と対障害性を高めている
  • 必要なタイミングで素早くスケールイン/アウトをおこなうことができる
  • 上記のような特性を備えた環境を初期投資なしで利用できる

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

設計上の考慮

ストレージの揮発性

  • コンテナの外側に保存する
  • メモリキャッシュ
    • MemCachierアドオンを追加
  • 画像など
    • Cloudinaryアドオンを追加
  • ログ情報
    • ogplexがやってくれる
    • アドオンを導入することでバックアップやビッグデータ連携ができる

スティッキーセッション

  • セッション識別子をロードバランサーなどで検知して同じセッションを同じアプリインスタンスにディスパッチする機能
    • JBoss、WebSphereなどはスティッキーセッションを前提に作られているが、PaaSによる効率的なルーティングがアプリ要因で阻害されることになるため、良い設計とは言えない

タイムアウト

  • 時間応答がないリクエストをタイムアウトで強制終了することがある
    • Herokuの場合は30秒
  • WebSocketの中に何も流れていなければ切られる
  • 対応策
    • 長い時間がかかる処理はキューに登録し、バックグラウンド処理で実行するようにする

PaaSに適した設計

  • アプリケーションがプロセス単位で分散配置され、
  • 個別のプロセスはいつでも不安定になり得る
  • という前提のもと、シェアードナッシングに設計する

得られる利益

  • PaaSが提供する安全で拡張性のある実行環境を初期投資なしで利用可能
  • スモールスタートで運用開始し必要な時にスケールアウトさせることが可能

  • アプリケーションの可搬性が高くなり、ベンダーロックインにならない

  • HerokuはPaaSのパイオニア

    • Herokuで動くシェアードナッシングなアプリケーションは他のベンダーでも動く

さらに生産性の高い開発/運用のために

  • The Twelve Factor Application
    • 現代的なアプリケーションを設計、構築、運用するための12の方法論
    • Heroku創業者がプラットフォームサービス上で数百のアプリの特性から得た知見をまとめたもの
    • 『プロフェッショナルのための実践Heroku入門』には日本語訳が書かれている

その他

f:id:shzero5:20141106002433j:plain

著書の『プロフェッショナルのための実践Heroku入門』にサインを頂きました。