ElasticBeanstalkでのRailsアプリ運用

ElasticBeanstalkでのRailsアプリ運用第7回 Amazonクラウド（JAWS-UG） 岡山

自己紹介

小西雅也

株式会社リゾーム勤務

Webアプリケーション開発 Webアプリケーション運用

今日話すこと

ElasticBeanStalkとは EBで運用しているアプリの概要 EBで運用することにした理由 EB上のアプリケーションサーバーのセットアップ バッチ処理について

cronWorker Tier

ElasticBeanStalkAWSにWebアプリケーションをデプロイできるEC2, RDS, ELB, SQSなどで構成された環境を作れるアプリケーションサーバーのAuto Scaleも可能スケールする条件を色々設定出来る(CPU稼働率, Disk IO, Network etc)

今日話すこと

ElasticBeanStalkとは EBで運用しているアプリの概要 EBで運用することにした理由 EB上のアプリケーションサーバーのセットアップ バッチ処理について

cronWorker Tier

EBで運用しているアプリアプリケーション間のデータ連携を管理する

RDB→JSON  データ変換機能JSONの準備完了を連携先へ通知

SC GATE(連携元アプリケーション)

MallNavi(連携先アプリケーション)

配布管理

配布管理の概要配布管理の構成

Heroku

AWS

EB

SC GATE«Database»データベース

«Storage»S3

配布管理«Database»RDS

MallNavi アプリケーションA

配布管理の要件

SC GATEとは独立したアプリケーションにしたいデータ連携側の仕様変更などの場合に、SC GATEのリリーススケジュールの調整をしたくない

連携先のアプリケーション登録UI  →  Railsで構築Heroku Toolbeltの実行(SC GATEのDBダンプを取得するため)SC GATEのDBダンプをRDSへリストアリストアされたRDSをRailsのModelのto_jsonでJSONエクスポート当初はSC GATEのDBダンプをローカルに持ってきて手動でJSONを作っていたので、同じ形式のデータを作りたかった

今日話すこと

ElasticBeanStalkとは EBで運用しているアプリの概要 EBで運用することにした理由 EB上のアプリケーションサーバーのセットアップ バッチ処理について

cronWorker Tier

EBになった理由要件的に外部コマンドを呼んで実行するバッチになりそう

なので最初はEC2単体 or その他VPSに構築するつもりだった既に社内でEBの利用事例があった(Mall Navi)環境変数の管理

社内でのRails運用環境の別パターンを押さえておきたかった

今日話すこと

ElasticBeanStalkとは EBで運用しているアプリの概要 EBで運用することにした理由 EB上のアプリケーションサーバーのセットアップ バッチ処理について

cronWorker Tier

ebextensionsソースコード上に追加するElasticBeanStalkの設定ファイルElasticBeanStalk上のAWSのリソースをカスタマイズ出来るアプリケーションが稼働するEC2上に必要なパッケージを入れたりするのに使用EC2にssh出来るがそこで直接サーバーをセットアップしたら駄目 (セットアップ中に色々試すのは逆にsshしてやってみたほうがいいかも)今日の話のメイン

ebextensions

ファイル名順に実行される

ebextensionsサーバーのタイムゾーン設定

commands:   set_time_zone:     command: ln -f -s /usr/share/zoneinfo/Japan /etc/localtime

必要パッケージのインストール

packages:   yum:     jq: []    libxml2-devel: []    libxslt-devel: []

ebextensionsEBの環境変数を ebextensionsで使う方法

files:   "/home/ec2-user/pgpass.sh":     mode: "000755"    owner: root    group: root    content: |      #!/bin/bash      jq  -r "to_entries|map(\"\(.key)=\(.value|tostring)\")|.[]" <(/opt/elasticbeanstalk/bin/get-config environment) > /tmp/envs      . /tmp/envs      echo $RDS_HOSTNAME:$RDS_PORT:scgate:$RDS_USERNAME:$RDS_PASSWORD > /home/ec2-user/.pgpass

ebextensionsheroku toolbelt用にパスワードを保管

  "/home/ec2-user/.netrc":     mode: "000600"    owner: ec2-user    group: ec2-user    content: |      machine api.heroku.com        login hoge@hoge.com        password xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx      machine git.heroku.com        login hoge@hoge.com        password xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

ebextensionscommands:   01_heroku_toolbelt_install:     command: /bin/bash -lc 'wget -O- https://toolbelt.heroku.com/install.sh | sh'  02_add_toolbelt_path:     command: echo 'PATH="/usr/local/heroku/bin:$PATH"' >> /home/ec2-user/.bashrc  03_heroku:     command: su - ec2-user -c "/bin/bash -lc '/usr/local/heroku/bin/heroku apps'"    env:       HOME: /home/ec2-user  04_scgate_pgpass_create:     command: /home/ec2-user/pgpass.sh  05_scgate_pgpass_permission:     command: chown ec2-user.ec2-user /home/ec2-user/.pgpass; chmod 600 /home/ec2-user/.pgpass

ebextensions必要な設定が出来たら、最初から環境を作り直して確認する

試行錯誤中の手動操作が前提で動いている可能性がある

簡単にsshしていじれる安心感から、やってしまいがち（やった）

今日話すこと

ElasticBeanStalkとは EBで運用しているアプリの概要 EBで運用することにした理由 EB上のアプリケーションサーバーのセットアップ バッチ処理について

cronWorker Tier

バッチ処理 cron現状の配布管理はこれで管理している

EBのAuto Scalingで複数EC2が動くようになっていると、それぞれのサーバーでcronが動くので良くない

Worker TierアプリケーションがデプロイされたWeb非公開のEC2と、Amazon SQSで構成されるSQSのキューを受け取ると、キューの本文を Worker TierのアプリケーションにPOSTしてくれるアプリ側でPOSTに反応してバッチが動くように作って運用するworker tierはずっと起動している配布管理のバッチは月に数回起動なので、この方法は見送った

それなりに実行することが多いならWorker Tierがいいと思う

試してみたいこと

AWS Batchシェルスクリプトや、コンテナイメージをジョブとして登録して実行出来る

処理している時間だけEC2が稼働する？配布管理のRailsアプリをDockerイメージにしてEBで運用してから、AWS Batchにもするといいのかも？

まとめ

要件としてサーバーに色々と入れないといけないサービスでは、ElasticBeanStalkでRailsを動かすと便利