[レポート]YAPC::Asia TOKYO 2015 Consul/Strecherで大規模なPULL型デプロイを実現する #yapcasia

スクリーンショット 2015-08-20 23.56.31

YAPC::Asia Tokyo 2015 Day 1に参加してきました。

昼休みを挟んで Consul と Strecher を使ったPULL型デプロイに関する発表が2セッションほどありました。 これらは、テーマ・内容が似通っているため、1記事としてまとめて紹介致します。

前者が任天堂・はてなによる発表で、Capistrano の PUSH 型デプロイから Consul/strecher の PUSH 型デプロイへの変遷(デプロイ時間が 1/40 になった) 後者が strecher 開発者(カヤックの @fujiwara さん)による開発の経緯・導入事例です。

※講演では上記以外のテーマも話されていました

中央 PUSH 型デプロイからPULL 型デプロイへ

中央PUSH型デプロイは

  • デプロイ台数の増加によるデプロイの長時間化
  • サーバごとに同じビルド処理が走り、サーバリソース、デプロイ時間を無駄にしている
  • デプロイ先サーバの動的な変更に追従するのが苦手

といった課題があります。 この課題を解決するために、開発されたのが strecher というデプロイツールです。

strecher はConsul と連携して、これら課題を解決します。

Consul について

Consul は Vagrant や Terraform などで有名な Hashicorp 製の分散型サービスディスカバリツールです。

  • 各ノードのヘルチェック
  • 各ノードへのメッセージ通知
  • Key/Value Store
  • DNS/HTTP をしゃべる

といった特徴があります。

strecher では Consul のこれら機能が活用されています。

Consul の主要機能の詳細は公式サイトの Getting Started をご確認ください。

strecher のアーキテクチャ

stretcher_architecture

大前提として各ノードが Consul の管理下にあるものとします。

デプロイは以下の手順で行われます。

  1. アプリケーションをbuildしてtar.gzにする.依存cpan moduleなどすべて固める
  2. 手順書(manifest)を書く
  3. tar.gz, manifestをS3(or httpd)に上げる
  4. consul event で manifest URLを通知 $ consul event -name deploy s3://

ここまでstretcherではない

ここからstretcherの出番

consul wait でイベント通知を待っている

$ consul watch -type event -name deploy stretcher

  1. event から manifest URLを取得
  2. manifest ファイルからtar.gzを取得してTMPDIRに展開
  3. rsync -av --deleteで更新
  4. command実行

ピンポイントで解説します。

アプリのビルドについて

レポジトリはできるだけソースコードのみを管理し、ビルドしたアプリはレポジトリに含めないようにし、レポジトリの肥大化を防ぎます。 ビルド済みのものを S3 で配布するため、各サーバでビルド処理が走ることはありません。

manifest ファイル

manifest ファイルは次のようになっており

  • ビルドされたアプリのパス
  • インストール手順

などが記述されています。

src: s3://example.com/app.tar.gz
checksum: e0840daaa97cd2cf2175f9e5d133ffb3324a2b93
dest: /home/stretcher/app
commands:
  pre:
    - echo 'staring deploy'
  post:
    - echo 'deploy done'
  success:
    - cat >> /path/to/success.log
  failure:
    - cat >> /path/to/failure.log
excludes:
  - "*.pid"
  - "*.socket"

運用面について

Consul でのプロダクション利用

Consul 0.2 時代から1年以上本番運用しているが、問題なし。

オートスケール時のデプロイ

インスタンスごとにロールが割り振られている。 Consul の KVS には、ロールごとに最新の Manifest 情報がある。 新規追加されたインスタンスは、この Manifest ファイルを参照してアプリケーションを最新の状態にし、PULL デプロイ完了後にクラスターに加わる。

モニタリング

Consul の KVS をブラウザから閲覧して俯瞰できるように UI(ダッシュボード) も開発した。

DNS の stale read

DNS の問い合わせはリーダーノード経由で行われる。

障害などでリーダーノードがこけると、別のリーダーが再選出されるまで、DNS サーバが数秒応答しなくなる。 stale モードで各ノードを稼働させると、リーダー以外のノードも stale cache で応答するようになり、可用性があがる。

その他

strecher が影響を受けたソフトウェア

※strecher 開発当初はまだ CodeDeploy がリリースされていなかったため、利用は検討しなかった。

strecher は AWS に依存しない。 例えば、Manifest 等のファイル置き場は、HTTP サーバ経由でアクセスできれば良い。 ただし、何百MBもあるファイルを100クライアントから同時にダウンロードされてもびくともしない HTTP サーバでなければいけない。

デプロイごとに AMI を作成してインスタンス起動するのはどうか?

AMI 方式だと

  • AMIの作成に10分
  • デプロイに10分

と時間がかかり、一日になんどもデプロイできないのが嫌。

一方で、任天堂はホットフィックスリリースを除けば2週間に一度程度のリリースサイクルのようなので、この制約は無視できるかと。

Netflix は Apagard/animator を使って AMI ベースの Blue-Green デプロイをやっている

The Netflix Tech Blog: Deploying the Netflix API

参考サイト