この記事で伝えたいこと
- Beanstalk は便利！
- ワーカー環境最高！
Beanstalkの特徴
- ウェブアプリケーションの動作環境をまるっと構築するサービス
- PaaSではないが、AWSの中でPaaSに最も近い
- ロードバランサやEC2を一発で構築してくれる
- 各種言語に対応したテンプレート環境がある
- クロンとジョブキューを提供するワーカー環境がある
- 全てのリソースは通常のAWSのリソースとして作成され、自由に設定変更できる
Beanstalk採用の背景
- 個人環境やdev環境などをサクサク作りたい -インフラ担当無しでやりたかった
- 以前、terraformの運用が大変だった(冪等性の確保が大変だった)
- 当初はGCPのGAE(Google App Engine)も検討していた
- 既存AWSのDBへの接続が必要なのでAWSにした
- 担当者(私)がAWSにそこまで詳しくはない
- フルマネージドなキューワーカーがほしい
- クロンやワーカー環境は自作すると容易にスケーラビリティが無くなりSPOFにもなる
どんな風に使っているか
- 言語： PHP
- 環境: 個人、dev、RC(リリース候補)、本番
コンソール画面例 01
コンソール画面例 02
コンソール画面例 設定
コンソール画面例 モニタリング
設定ファイル例 01
設定ファイル例 02
設定ファイル例 03
デプロイの様子
どう便利だったか
- 環境をさくっと作ってさくっと潰せる
- デプロイがコマンド1発
- ワーカー環境が超おすすめ
ワーカー環境とは
- 環境にはアプリケーション環境とワーカー環境の2タイプがある
- ワーカー環境でできること
- クロンの実行
- キューワーカーの実行
ワーカー環境はどう動くか
- クロンが複数インスタンスで単一実行される
- 複数インスタンスを立てて同じクロンを設定しても、どれか一台を選んで実行してくれる
- キューも処理できる
- SQSにキューを投げるだけ。分散も自動
- HTTPリクエストとしてアプリケーションは受け取る
- 内部ではsqsdというプロセスがキューを監視している
- 処理の勢いやリトライなど基本的なことはBeanstalk側で設定可能
ハマったポイント
- 環境変数の設定ポイントが3種類ある
- コンソール画面、API、ソースコード(設定ファイル)
- 設定値をソースコードに含める場合、アンドキュメントな仕様があった
- 直下ディレクトリ以外のサブディレクトリのファイルも読み込まれていた
- AWSサポートに確認してもらった。サポートは優秀
気になるポイント
- 言対応語、プラットフォーム
- PHP, Python, Ruby, Node.js, Java, Golang, .NET, etc…
- Docker
- ロードバランサ、ドメイン、SSL
- CLBとALBの両方が使える
- 無しにもできる(EC2直接続になる。開発用など)
- ロードバランサがあると独自ドメインとSSLが使える
- AWSのサブドメインも提供される
- SSH
- EC2インスタンスに普通にSSHログインできる
- アクセスコントロール
- VPC、ロードバランサ、EC2などにセキュリティグループやACLをBeanstalk外から設定する
気になるポイント
- 監視
- 標準でメール通知あり (SNSトピック経由)
- ヘルス異常やデプロイを通知してくれる。応答が悪くなった、キューが溜まった、など。
- SNSトピックにLambdaを設定すればあとはSlackへでも何でも。
- ログ
- 直近のログであればコンソールからまとめてダウンロードできる
- アクセスログはロードバランサを直接設定してS3に永続保存するのがおすすめ
- セキュリティパッチ
- 自動。メンテナンスウィンドウ期間に行われる。インスタンスを2台以上設定しておけば無停止だと思われる。
まとめ
- 大枠を自動構築してくれるのでインフラ担当無しで運用できる
- 細かい点はコンソールから手動でOK（terraform化すればなおよし）
- ワーカー環境は超便利
- SPOFを無くそう！