EC2のApache-PHPで動いてたバッチシステムをECS-Fargateに移行して運用してる話.pdf

Transcript

1. EC2のApache/PHPで動いて たバッチシステムを ECS/Fargateに移行して運用 してる話 良太郎（@ryota_hnk）
2. 2 • 名前：小林良太郎（twitter:@ryota_hnk） • 所属：株式会社ウィルゲート インフラユニットマネージャ • 職種：インフラエンジニアとして各サービスのインフラ構築運用 • 経歴：COBOLer→OracleDBA→プライベートクラウド構築→現職 • 1日10分のリングフィットアドベンチャーで筋肉痛 自己紹介
3. 3 • システム構成 • 抱えていた課題 • 検討した解決策 • Fargate移行にあたって考えたこと • 移行したときの苦労 • まとめ 話すこと
4. 4 システム構成
5. システム構成 5 • TACT（https://tact-seo.com/）は SEOのSaaS型ツールで以下の機能が ある ◦ 上位化のための課題発見 ◦ キーワードのグルーピング ◦ 流入キーワードの調査 ◦ 順位計測 • バッチで取得した情報をWeb表示 ◦ バッチの数は50以上 ◦ 夜間バッチが多い • 使っているAWSサービス ◦ EC2 ▪ APサーバ：2台 ▪ Batchサーバ：1台 ▪ JOB管理サーバ：1台 ▪ アプリは全てphp ◦ RDS ◦ Elasticache ◦ DynamoDB AP サーバ Batch サーバ RDS DynamoDB 画面で確認 保存 サイトに関する 様々な情報を 取得・集計 JOB管理 サーバ
6. 抱えていた課題 6
7. 抱えていた課題 7 • バッチサーバのコスト ◦ c5.2xlarge（8vcpu、16GiBメモリ）という、我々には高価なインスタンス ◦ 重いバッチは10GB以上メモリを使うが他はそうでもなく、メモリスカスカの時間帯もある ▪ メモリを10GB以上使うバッチは1日1回しか動かない ▪ 1日中動いてるバッチもあり、夜間だけ動かすというわけにも行かない • バッチサーバの可用性 ◦ 漢の1台構成 ▪ インスタンスで障害が起きるとマズイ ▪ と思ってたら実際に起きた（インスタンスのハングアップ） ▪ 冗長化？しかし高価。。。
8. 8 検討した解決策
9. 検討したこと解決策① 9 • バッチサーバ分割 ◦ 概要 ▪ EC2インスタンスを何種類か用意し、バッチに応じて使い分ける ▪ 大きいインスタンスはバッチを動かす時に起動する ◦ メリット ▪ インスタンスの使用効率上昇 ▪ コストを下げることができる ◦ デメリット ▪ 1台構成が増えるので、運用負荷が増える • 障害が起きた時に影響範囲がわかりにくい • システム全体の見通しの悪さ
10. 検討したこと解決策② 10 • コンテナ化 ◦ 概要 ▪ コンテナのオンデマンドサービスECSを使う ▪ ECSのタスク（コンテナ）実行手段として、EC2とFargateの種類がある 役割 AWSにおける機能の名前 AWSのサービス コンテナのホスト データプレーン EC2、Fargate コンテナのオーケストレー ション コントロールプレーン ECS、EKS
11. 検討したこと解決策② 11 • コンテナ化 ◦ 概要 ▪ コンテナのオンデマンドサービスECSを使う ◦ メリット ▪ 必要な分だけリソースを確保するのでコストが下がる • Fargateの課金体系は使ったvCPUをメモリ課金（秒単位） ▪ Cron型のタスク実行ができるのでJOB管理サーバが不要になる ▪ バッチ実行基盤の可用性はAWSが担保してくれる • Fargateを使えばEC2からも開放される！ ▪ デプロイフローも改善できる • デプロイサーバからデプロイツールを実行していた ◦ デメリット ▪ 経験値の少なさ（コンテナを本番運用したことがない）
12. 12 • Lambda ◦ phpをサポートしてない • AWS Batch ◦ 大規模機械学習向けっぽくてそこまでじゃなさそう（個人の感想です） ◦ （当時は）ECS/EC2しか対応しておらず、EC2から離れたかった我々には合わない ▪ 現在はAWS BatchはFargateに対応しております 検討したこと-その他-
13. 13 Fargate移行にあたって考えたこと
14. Fargate移行にあたって考えたこと • バッチの実行方法 ◦ Before Fargate ▪ LaravelにはArtisanというCLIツールが搭載されていて、そこからバッチを実行できる ▪ JOB管理サーバからバッチサーバ上のArtisanコマンドを定期実行していた ◦ After Fargate ▪ 起動したらバッチが自動起動するコンテナを作ろう • バッチごとにコンテナイメージを作る？ ◦ 40〜50のコンテナイメージを管理することになり煩雑すぎる ⇨コンテナ起動時にバッチを指定できないか 14
15. 15 • コンテナイメージは1つにする • Fargateのタスク作成時にバッ チ名を環境変数に設定する • 環境変数からバッチ名を取得し て実行するようにする • ステージング環境でタスクごと のメモリやvCPUを調節 • Cron型でタスク実行タイミング を設定できるぞ！ JOB管理サーバなんかいらん かったんや コンテナ起動時に バッチを指定したい BATCH_NAME hogehoge コンテナ起動時に実行するシェル バッチ名を環境変数に（Fargateの設定画面）
16. Fargate移行にあたっ て考えたこと 16 • デプロイ方法 ◦ コードのMergeをすると BitbuketPipelineでコン テナイメージを作成し、 ECRにPushする ◦ FargateはECRのコンテ ナイメージをPullして バッチ実行
17. Fargate移行にあたっ て考えたこと 17 • デプロイ方法 ◦ コードのMergeをすると BitbuketPipelineでコン テナイメージを作成し、 ECRにPushする ◦ FargateはECRからコン テにメージをPullして バッチ実行 ◦ bitcucket-pipelines.yml も割と簡単に出来た 実際のbitbucket-pipelines.yml（抜粋）
18. Fargate移行にあたって考えたこと • Fargateの運用監視 ◦ Before Fargate ▪ zabbixでアプリのログを監視 ▪ EC2インスタンスのリソース監視（CPU、メモリ） ▪ Prometheusのprocess-expoorterで各バッチプロセスのメモリ監視 ◦ After Fargate ▪ CloudWachLogsにフィルターを設置し『ERROR』などの文字列を検知してLambdaと SNSを使ってSlackに送信すればヨシ！ ▪ サーバの管理からは開放されたぞ！ヨシ！ ▪ バッチプロセス（Fargateで言うタスク）はCloudwatch（Grafana）で見れる！ヨシ！ 18 slack通知 Grafanaから見るCloudwatch
19. 19 移行したときの苦労
20. Fargate移行にあたって考えたこと（再掲） • Fargateの運用監視 ◦ Before Fargate ▪ zabbixでアプリのログを監視 ▪ EC2インスタンスのリソース監視（CPU、メモリ） ▪ Prometheusのprocess-expoorterで各バッチプロセスのメモリ監視 ◦ After Fargate ▪ CloudWachLogsにフィルターを設置し『ERROR』などの文字列を検知してLambdaと SNSを使ってSlackに送信すればヨシ！ ▪ サーバの管理からは開放されたぞ！ヨシ！ ▪ バッチプロセス（Fargateで言うタスク）はCloudwatch（Grafana）で見れる！ヨシ！ ヨシ！ 20 slack通知 Grafanaから見るCloudwatch
21. 移行してからの苦労 • 通知が来たり来なかったりする ◦ 全く出ないわけじゃなく、同じメッセージでも来たり来なかったり（一番厄介なやつ） ◦ 上限にもあたったというログもない ◦ AWSのサポート入ってないし、本当に困った ◦ 「Laravelから直接slackに通知出して下さい」とアプリにお願い ◦ 対応してくれたアプリチームに感謝 21 混乱する様子
22. 22 • 順序を守らないとダメなバッチが存在 ◦ バッチAが終了後、バッチBが起動しないとダメな組み合わせが発覚 ▪ しかもバッチBはパラレル実行したい ◦ StepFunctionsを使わざるを得ない ▪ JSON辛いけど頑張った 移行したときの苦労 StepFunctionsで定義された タスクのレイアウト画面
23. 23 • コンテナイメージは1つにする • 環境変数からバッチ名を取得し て実行するようにする • Fargateのタスク作成時にバッ チ名を環境変数に設定する • ステージング環境でタスクごと のメモリやvCPUを調節 • Cron型でタスク実行タイミング を設定できるぞ！ JOB管理サーバなんかいらん かったんや （再掲） コンテナ起動時に バッチを指定したい BATCH_NAME hogehoge コンテナ起動時に実行するシェル バッチ名を環境変数に（Fargateの設定画面）
24. 24 • cron登録したバッチが勝手に多重起動する ◦ Fargateにタスクをcron登録するとCloudWatch Eventが作成され、そこからFargateタスクが 実行される ◦ アプリ側が重複して実行される事象を確認 ▪ 12時に1回だけ実行するようにスケジュールしても複数回実行される ▪ 毎回ではなくレアな事象 ▪ 設定どおり1回だけ実行する時もあれば2,3回実行されてしまう時もあった ◦ 以下は CloudWatch イベント のトラブルシューティング からの引用 ◦ 一旦移行を諦める ▪ JOB管理サーバからAWS CLIでFargate起動も考えたが、移行元と移行先でクロスする 関係になるので一旦見送り。バッチサーバ残留 移行したときの苦労 まれに、単一のイベントまたはスケジュールされた期間に対して同じルールを複数回トリガーしたり、 特定のトリガーされたルールに対して同じターゲットを複数回起動したりする場合があります。
25. 25 • 止めたはずのバッチが起動する ◦ バッチを削除しようとしてFargateで登録したタスクを削除したら、なぜか起動して大騒ぎに なる ◦ 以下は Amazon Elastic Container Service 開発者ガイド からの引用 ◦ 消したはずのタスクが実行され続けてしまう 移行したときの苦労 タスク定義リビジョンは登録解除されると、すぐに INACTIVE とマークされます。 INACTIVE タスク定義リビジョンを参照する既存のタスクおよびサービスは、中断す ることなく引き続き実行されます。 まずこの チェックを外 してから
26. 26 • 毎分起動するバッチがあることを知る ◦ Fargateは起動に10秒以上かかるときもあるし、件の多重起動問題と重なると大変なことにな りそうだ ◦ 社内Slackでも「毎分ぐるぐる」と呼ばれ、時々議論の対象になっていた ◦ 課題は認識しているがアプリ改修がネック ◦ バッチサーバに残留 移行したときの苦労
27. 27 まとめ
28. まとめ 28 • 良かった事 ◦ バッチサーバのインスタンスを小さいインスタンスに変更し、費用削減できた ◦ サーバのことを気にしなくて良くなった。精神的に楽。Fargateバンザイ！ ◦ コンテナ運用の経験を得られた ▪ アプリ、インフラそれぞれで得た知見を資料化、共有した ◦ アプリとインフラの協力体制は不可欠と認識できた • 無念 ◦ 全てを移行することが出来なかった ▪ 歴史の長いアプリのプラットフォーム移行は大変 ▪ いい状態ではないので、残りはノンビリ移行中（のはず） ◦ AWSも万能ではない。特性や癖を把握するのは重要 ▪ サポート入ろう！公式文書読もう！
29. まとめ 29 • CloudNativeへの旅 ◦ バッチはサーバ（EC2イ ンスタンス）という箱か ら開放され、必要な時に 必要なコンピューティン グリソースを確保すると いう、クラウド本来の定 義に近づけた ◦ 今回得た知見を他サービ スにも展開していきたい ◦ サービスの成長に最適な 技術を導入できるように アンテナを張っていく https://github.com/cncf/trailmap
30. 30 ご清聴ありがとうございました Thanks