24時間途切れないサービスで有効なImmutable Infrastructureの運用方法：大規模プッシュ通知基盤大解剖（終）（1/2 ページ）

大規模プッシュ通知基盤について、「Pusna-RS」の実装事例を基にアーキテクチャや運用を解説する連載。今回は、Pusna-RSの運用面や発生した課題について、使用している技術やツール「AWS Elastic Beanstalk」「Jenkins」「Amazon CloudWatch」「GrowthForecast」「fluentd」「Elasticsearch」「Kibana」などの説明を交えながら紹介します。

[樋口勝彦，リクルートテクノロジーズ スマートデバイスグループ]

連載目次

最終回は大規模プッシュ通知基盤の“運用”について

　大規模プッシュ通知基盤について、「Pusna-RS」の実装事例を基にアーキテクチャや運用を解説する本連載。第1回の「プッシュ通知の基礎知識＆秒間1万を超えるプッシュ通知基盤のアーキテクチャと仕組みとは」では、Pusna-RS全体のアーキテクチャ構成について解説しました。

　第2回の「大量データ処理時に知っておきたいAmazon DynamoDB活用テクニック4選」では、Pusna−RSのデータ永続化に使っているAmazon DynamoDB（以下、DynamoDB）の活用テクニックについて解説し、前回の「Node.jsのStream APIで大量プッシュ通知を高速化するテクニック」では、そのDynamoDBからAPNs／GCMへのデータ送信までを高速化させた方法を紹介しました。

　最終回となる今回は、Pusna-RSの運用面や発生した課題について、使用している技術やツールなどの説明を交えながら紹介します。

24時間途切れることない無停止での運用

　あらためてPusna-RSは以下のような特徴を持つシステムです。無停止での運用や高い品質を維持する仕組みが求められています。

• 各アプリからのデバイス情報の更新アクセスが24時間途切れることなく来る
• アプリによってはリアルタイムにプッシュができないとサービスに影響が出る
• 誤配信は個人情報の流出につながる可能性があるため許されない

　一方、多様なアプリに使用されているため、機能追加要望が多く頻繁なリリースを行っています。そのため、無停止リリースの仕組みや、品質を高く保つためのテストの仕組みが重要になります。これらを実現するために活用しているツールや運用方法について紹介していきます。

　まずは前提として、Pusna-RSのデプロイ管理について紹介します。

Elastic Beanstalk

　Pusna-RSではAWS Elastic Beanstalk（以下、Elastic Beanstalk)を利用しています。

　Elastic Beanstalkは特定の言語で開発されたWebアプリケーションやサービスのデプロイやスケーリングを自動かつ、容易に実現できるサービスで、Auto Scaling Group、Security Group、Amazon Elastic Load Balancing（以下、ELB）、Web Serverなどあらかじめ決められた構成の中から必要なものを選択することで、高速に環境を構築できます。

Elastic Beanstalk構成図

　Elastic Beanstalkには以下の特徴があります。

• CPU平均使用率、リクエスト数、平均待ち時間など、デフォルトでリソース監視が可能
• サーバーのログファイルはGUIツール上から確認可能
• Elastic Beanstalk自体には利用料金は掛からない

　Pusna-RSではNode.js＋nginxを採用しており、かつスピード重視で開発する必要があったため、容易にパッケージ構成を作成できるElastic Beanstalkを採用しました。Node.js以外にも以下のプラットフォームに対応しています。

• Java
• Python
• PHP
• .NET
• Ruby
• Docker

　基本的な構成、設定は最小限の作業で作成できますが、アプリケーションサーバーの詳細設定やアプリケーション個別パッケージのインストール（Pusna-RSでいうとfluentdなど）、cronの設定など、基本パッケージ構成外のことをする場合は独自に設定を行う必要があります。

　具体的にはアプリケーションディレクトリ直下に.ebextentionsディレクトリを作成し、「*.config」ファイルを配置することでデプロイ時に設定ファイルの内容が実行されます。

Elastic Beanstalkの用途

　Pusna-RSではカスタム設定を「.ebextensions」内で行っています。「.ebextensions」内に記載する設定ファイルは以下の構成になっています。

• commands
  • サーバーにアプリケーションが配置される前に記述されているコマンドを実行
• files
  • サーバーにアプリケーションが配置される前に記述されている内容を指定のファイルパス配下に出力
• container_commands
  • サーバーにアプリケーションが配置されデプロイされる前に記述されているコマンドを実行
• option_settings
  • 環境変数の設定
• Resources
  • Amazon SQS（以下、SQS）キュー、Amazon CloudWatch（以下、CloudWatch）のアラームなどの追加リソースの設定
• packages
  • yumやrpmなどのパッケージのインストール
• sources
  • 外部からのアーカイブをダウンロードし、指定した場所に展開する
• services
  • サービスの起動や設定変更を行う
• users/groups
  • 任意のユーザー／グループを作成

　Elastic Beanstalkのデプロイ時の挙動は下記の通りです。

1. 設定ファイル内のcommandsセクション
2. アセットのコンパイル
3. 設定ファイル内のcontainer_commandsセクション
4. アプリケーションサーバーの起動
5. バックグラウンドワーカーの起動

　上記の実行が正常に完了すると、デプロイ完了となります。

　設定ファイルについて具体的なサンプルを以下に示します。

commands:
  01-get-instance-id:
    command: curl -s http://xxx.xxx.xxx.xxx/latest/meta-data/instance-id > /var/opt/instance-id
  02-remove-temp-files:
    command: rm -rf /var/tmp/*
  03-remove-temp-files:
    command: rm -rf /tmp/*
 
files:
  "/var/opt/env_port" :
    content: |
      `hogehoge`
 
container_commands:
  01-dump-all-KEYS:
    command: |
      cat << EOF > /var/lib/hogehoge
      export HOGE1=${HOGEHOGE1}
      export HOGE2=${HOGEHOGE2}
      export HOGE2=${HOGEHOGE3}
      EOF

　上記のような設定ファイルは、目的別に複数に分けて作成することもできます。Pusna-RSでは、この設定ファイルを使って以下のような設定を行っています。

• commands
  • アプリケーションで使用するパッケージのインストール（npm）
• option_settings
  • DynamoDBの接続キー名、CloudWatchのトピック名などの環境変数設定
• Resources
  • SQSの作成
  • CloudWatchの設定
• files
  • nginxの設定ファイルの作成
  • fluentdのtd-agentのインストールと設定ファイルの作成
  • cronの設定

　その他の詳細はAWS公式サイトをご覧ください。

Immutable Infrastructure

　リアルタイムなプッシュを必要とするアプリケーションが増えてきているため、リリースのタイミングであってもシステムを停止できません。

　そこでPusna-RSでは一度リリースした環境についてはその状態を変化させず、次回リリース時には古い環境を捨て新しいインフラ環境を新規作成する「Immutable Infrastructure（イミュータブル・インフラストラクチャ）」の概念を導入しています。

　それを実現するためにElastic Beanstalkのswap機能を使い、旧環境と新環境のDNSの向き先を切り替えることでダウンタイムなしでのリリースを実現しています。

　リリース作業は「Elastic Beanstalk API」を使用しJenkinsから実行することで以下の作業を自動化しています。

• upload
  • Gitサーバーからmasterブランチのソースを取得し、Elastic Beanstalk APIを利用し環境を作成
• release
  • swap機能を使い、旧環境・新環境のDNSの向き先を切り替える。ここで動作確認を行う
• destroy
  • 動作確認の結果、問題がない場合は旧環境を削除する。問題があった場合は再度release作業を再度行うことで瞬時に切り戻し作業を行うことが可能

Pusna-RSで行ったImmutable Infrastructure