2022/10/21 bitstar CROSS 2022 in EZO AWS ECSでのバックエンドの開発について

Transcript

1. bitstar CROSS 2022 in EZO AWS ECSでのバックエンドの開発について [2022年10月21日] ビットスター株式会社 サービス事業部 第１事業グループ 村上 將志
2. 2 はじめに～今回の内容～ • あるシステム開発の案件でバックエンド側の機能要件 • 演算処理、グラフ・レポート作成など、時間がかかる ※一連の処理で2分以上 • ユーザーからの要求に応じてオンデマンドで実行 ※できるだけ早く結果を見たい • 最初はデータが少ないので順に実行するように実装して問題なし （要求が複数来たら順番待ち） • データ量の増加により、順番待ちの時間が長くなり、運用に支障 （とまで言わなくても不便と感じるように） • 並列で処理できる数を増やし、待ち時間を短縮したい この課題をAWSのECSで解決したので、事例を紹介します。
3. 3 はじめに 本資料は後日公開します。 ※参加者の皆様にDoorkeeperからメールで資料のURLをお送りする予定です。 今回は細かい実装や難しい理屈の話はありません。 プログラマだけでなく、お客様に提案する方、クラウドの構成やシステムの設 計をする方にも、ぜひご覧いただきたいと思います。
4. 目次 4 BS150105 • 自己紹介 • 開発の背景 • システムの概要 • Amazon ECSで構築する前 • Amazon ECSでの構成（１） • 新たな問題発生 • Amazon ECSでの構成（２） • まとめ
5. 5 自己紹介 • ビットスター株式会社 サービス事業部 第1事業グループに所属する、 村上 將志（むらかみ まさし）と申します。 • 北海道出身で7年ほど北海道勤務でしたが、2019年春に大阪へ転勤とな り、大阪市住吉区（一番南の区）に生息しています。 • 開発チームで、主にWebシステムの開発に携わっています。 • 好きなAWSサービスは、ECS Fargate、CloudFormationです。 名刺 Facebook • 今日の話について詳しく話してみたい、などありましたら、ご連絡くだ さい。
6. 開発の背景 BS150105 6
7. 7 開発の背景 • 開発したシステム（概要） • 医療検査機器を開発するスタートアップのお客様からシステム開発を受注 ※検査データの解析サービスを医療機関等へ提供 • システムのユーザーは医療機関の医師、看護師、上記お客様 • 検査機器で計測してできたバイナリデータを処理し、レポートを自動で作成 • 開発概要 • 2013年秋から開発し、2014年春に本番稼働を開始しました。 • CentOS6、PHP、ビットスター独自フレームワーク、MySQL • 岩見沢iDCにサーバ設置、運用していました。
8. 8 開発の背景 • 2018年秋ごろ、お客様からセキュリティについてご要望をいただきました。 • 「医療情報システムの安全管理に関するガイドライン」への対応 • 経済産業省、厚生労働省、総務省の3省から • 新たなOSでの構築（CentOS 7、あるいはそれ以降） ※CentOS6 : 2020年11月でサポート終了 • OSパッケージ、ライブラリ、フレームワーク等にセキュリティに問題が あっても、パッチが出てシステムに適用可能なこと • お客様のご要望を受けて、下記方針で開発することになりました。 • AWSに移行 ※上記ガイドラインへの対応リファレンスが明示されているため • OSはAmazon Linux 2を採用（CentOS 7互換） ※サポート期限：2024/06/30 • 世界で広く使われているPython Djagoでリプレース ※当社で開発実績あり
9. システムの概要 9
10. 10 システムの概要 • 開発したシステム（概要） • 医療検査機器を開発するスタートアップのお客様からシステム開発を受注 ※医療機関等に対して検査データの解析サービス • システムのユーザーは医療機関の医師、看護師、上記お客様 • 検査機器で計測してできたバイナリデータを処理し、レポートを自動で作成 • この処理をバックエンドとして開発 • バイナリデータ解析のコアプログラムは別の専門家が開発 →システムからOSコマンドで呼び出す →解析結果をテキストファイルに出力してくれる • その結果を元に、集計・演算、グラフとレポートを作成
11. 11 システムの概要
12. 12 システムの概要 一連の処理で、平均して2分ほどかかる。 ※レポートの種類、言語によっては2分半
13. 13 システムの概要 2分 一 連 の タ ス ク を 、 こ の 青 い 帯 で 表 現 し 、 このタスクがどのような順で実行されるか、 ここから先紹介していきます。 一連の処理で、平均して2分ほどかかる。 ※レポートの種類、言語によっては2分半
14. Amazon ECSで構築する前 14
15. 0分 1分 2分 4分 5分 6分 7分 8分 9分 3分 10分 15 Amazon ECSで構築する前 • Webサーバ（操作画面でのリクエストを受け付ける）とは別に、解析サーバを 構築し、常時起動 • cronで15秒ごとに処理待ちのタスクがないかチェック • 処理待ちのタスクがある場合、バックエンドのタスクを実行 • 同時に２つまでバックエンドタスクを実行可能 例：10個のデータをアップロードされた場合 1 2 3 4 5 6 7 8 9 10 • タスク10個：10分少々 • タスク100個：約100分（単純計算）
16. 16 システムの概要 • データ処理の依頼：不定期 • 一度に1000以上の依頼される（単純計算で約17時間かかる）こともあれば まったく処理の依頼がない日もある • 一度に依頼するデータ量が増大し、長時間待たされる日が増えてきた お客様から要望 • できればもっと早く確認したい • なので、同時に処理できる数を増やせないか？ • コストが大幅に増えるのは✘ そこで。。。
17. Amazon ECSでの構成（１） 17
18. • Amazon ECSとは？ • Amazon Elastic Container Serviceの略 • AmazonがAWSの中で提供する、フルマネージドのコンテナのオーケストレー ションサービス ※Kubernetesよりシンプルな構成に適しており、使いやすいです。 • コンテナの起動タイプは２種類あります。 • EC2ホスト：コンテナのホストとなるEC2インスタンスをユーザーが用意 し、その中で実行 • ホストのインスタンスの起動時間に応じて課金 • Fargate：サーバーレス（ホストはAWS側で管理） • コンテナイメージダウンロード開始～コンテナ終了まで 18 Amazon ECSでの構成（１）
19. • Amazon ECSとは？ • Amazon Elastic Container Serviceの略 • AmazonがAWSの中で提供する、フルマネージドのコンテナのオーケストレー ションサービス ※Kubernetesよりシンプルな構成に適しており、学習コストが低い • コンテナの起動タイプは２種類 • EC2ホスト：コンテナのホストとなるEC2インスタンスをユーザーが用意 し、その中で実行 • ホストのインスタンスの起動時間に応じて課金 • Fargate：サーバーレス（ホストはAWS側で管理） • コンテナイメージダウンロード開始～コンテナ終了まで 19 Amazon ECSでの構成（１） Fargateを使えば、 • バックエンドのタスクを複数同時に並列で処理できる • 終了したらコンテナを破棄することでコストも抑えられる！ • 開発環境をDockerで構築しているため、その定義のベース を流用して本番用のDockerfileを作れる これは使える！！
20. • Amazon ECSの使い方 • あらかじめ • ECR (Elastic Container Repositoryの略で、DockerHubみたいなもの） にイメージをpushしておきます。 • ECSクラスタ、タスク定義を作成しておきます。 • 処理の依頼が来たら、コンテナのタスクを起動します。 • AWS CLIで起動 • プログラムからSDKで起動 ※コンテナのタスクは複数起動できます。 20 Amazon ECSでの構成（１）
21. 21 Amazon ECSでの構成（１）～Fargateを使用した場合のバックエンド処理の流れ～
22. 22 Amazon ECSでの構成（１）～Fargateを使用した場合のバックエンド処理の流れ～ ① (Webサーバ01) 処理待ちのタスクがな いか、監視（cron） ※解析サーバがないの で、ここで監視 ② (Webサーバ01) タスクがある場合、ECS のタスクを開始 ③ (ECS内部) ECRからコンテナのイ メージをダウンロード ④ (ECS内部) イメージがダウンロード できたらタスク（コンテ ナ）を開始 ⑤ (コンテナ内) 処理を実行 ⑥ (コンテナ内) 処理完了時に、ほかの処理待ちのタスクが ある場合→次のタスク⑤へ ない場合→コンテナを終了・破棄
23. 9 0分 1分 2分 4分 5分 6分 7分 8分 9分 3分 10分 23 Amazon ECSでの構成（１）～並行処理の動作の予測、期待～ 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 10 12 9 11 13 14 15 16 17 18 20 22 19 21 23 24 25 26 27 28 30 32 29 31 33 34 35 36 37 38 40 42 39 41 以前： ECS Fargate： Fargate起動数 上限を10と した場合
24. 9 0分 1分 2分 4分 5分 6分 7分 8分 9分 3分 10分 24 Amazon ECSでの構成（１）～並行処理の動作の予測、期待～ 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 10 12 9 11 13 14 15 16 17 18 20 22 19 21 23 24 25 26 27 28 30 32 29 31 33 34 35 36 37 38 40 42 39 以前： ECS Fargate： Fargate起動数 上限を10と した場合 41 このような動きを期待したが、 現実は甘くなかった・・・。 →新たな問題発生
25. 新たな問題発生 25
26. 10 0分 1分 2分 4分 5分 6分 7分 8分 9分 3分 10分 26 新たな問題発生～並行処理の現実～ 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 12 9 11 13 14 15 16 17 18 20 22 19 21 23 24 25 26 27 28 30 32 29 31 33 34 以前： コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 1分半 ECS Fargate： Fargate起動数 上限を10と した場合
27. 9 0分 1分 2分 4分 5分 6分 7分 8分 9分 3分 10分 27 新たな問題発生～並行処理の現実～ 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 10 12 9 11 13 14 15 16 17 18 20 22 19 21 23 24 25 26 27 28 30 32 29 31 33 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 以前： ECS Fargate： Fargate起動数 上限を10と した場合 34 以前は要求したらすぐに処理を始めたのに、 AWSにした途端、1分半も待たされる。 現場ではすぐに処理をしてほしい。 緊急の場合に対応が遅れることもあるので、 なんとかしてくれませんか？ by お客様
28. 28 新たな問題発生～なぜ起動に時間がかかる？～ Fargateはサーバーレスのため、イメージをキャッシュ せず、毎回イメージをダウンロード →タスクの起動に時間がかかる ① (Webサーバ01) 処理待ちのタスクがな いか、監視（cron） ※解析サーバがないの で、ここで監視 ② (Webサーバ01) タスクがある場合、ECS のタスクを開始 ③ (ECS内部) ECRからコンテナのイ メージをダウンロード ④ (ECS内部) イメージがダウンロード できたらタスク（コンテ ナ）を開始 ⑤ (コンテナ内) 処理を実行 ⑥ (コンテナ内) 処理完了時に、ほかの処理待ちのタスクが ある場合→次のタスク⑤へ ない場合→コンテナを終了・破棄
29. Amazon ECSでの構成（２） 29
30. 30 Amazon ECSでの構成（２）～EC2ホストとFargateの併用～ ※同時起動：4に制限
31. 31 Amazon ECSでの構成（２）～EC2ホストとFargateの併用～ ① (Webサーバ01) 処理待ちのタスクがな いか、監視（cron） ② (Webサーバ01) タスクがある場合、ホ ストEC2内のタスクが 上限に達してなければ ホストEC2でECSのタ スクを開始 ③ (ECS内部) 初回、ECRからコンテナのイメージ をダウンロード →ホストEC2内にキャッシュされる →次回起動が速くなる ④ (ECS内部) イメージがダウンロードできたら、 あるいは、EC2の中にイメージの キャッシュがあれば、 タスクを開始 ⑥ (ECS内部) Fargateで起動された場合は、ECRか らコンテナのイメージをダウンロー ドしてタスクを起動 ⑤ (Webサーバ01) タスクがある場合、 EC2ホストのタスクが 上限に達していれば、 FargateのECSのタス クを開始 ※同時起動：4に制限
32. 21 0分 1分 2分 4分 5分 6分 7分 8分 9分 3分 10分 32 Amazon ECSでの構成（２）～即時起動+並列処理の実現～ 1 2 3 4 5 6 7 8 9 10 8 10 11 12 13 14 16 18 24 20 23 25 26 27 28 30 32 35 38 34 37 39 40 41 42 44 46 以前： コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 ECS EC2+ Fargate： EC2起動数上限 を4とし、 Fargate起動数 上限を10と した場合 1 2 3 4 5 6 7 9 15 17 19 22 29 31 33 36 43 45
33. 0分 1分 2分 4分 5分 6分 7分 8分 9分 3分 10分 33 Amazon ECSでの構成（２）～即時起動+並列処理の実現～ 1 2 3 4 5 6 7 8 9 10 以前： ECS EC2+ Fargate： EC2起動数上限 を4とし、 Fargate起動数 上限を10と した場合 21 8 10 11 12 13 14 16 18 24 20 23 25 26 27 28 30 32 35 38 34 37 39 40 41 42 44 46 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 コンテナ起動 1 2 3 4 5 6 7 9 15 17 19 22 29 31 33 36 43 45 46 ホストEC2のECSですぐに処理に入ることができた。 ホストEC2内の同時起動数の上限を超えた場合にも Fargateで並列で処理することができた。 ↓ データ増にも対応できた！
34. 34 AWSコスト • ECSのホストEC2（第2構成案で追加） • t3.mediumで構築 • CPU+メモリ：約40 USD/月 • バーストによるCPUクレジット：約8～10 USD/月 • EBS（ディスク）：3.6 USD/月 • 合計50～55 USD/月 ※月の日数、および、バースト（ベースラインを超えたCPU使用率が使用できる状況） の状況によ り度変動します。 • 月ごとにかかるコストはほぼ横ばいです。 • 今回は、このコストをかけてでも、すぐに処理が始まることを優先しました。 • ECS Fargate • コンテナの起動時間に応じて従量課金となります。
35. まとめ 35
36. 36 まとめ • 演算やグラフ・レポート生成などの処理を、ユーザーからの要求に応じてオン デマンドで順次実行していきたいという場合、Amazon ECSにより並行して処 理を行うことができます。 • ECS Fargateでは処理時間での従量課金になるため、オンデマンドでのバック エンド処理を並列で行いたいときに有効でしょう。 • ただし、Fargateでは、コンテナのイメージが大きい場合にイメージのダウン ロードに時間がかかるため、実際の処理開始まで待たされることがあります。 • オンデマンドでの処理をすぐに開始したい場合、Fargateだけではなく、EC2を ホストとしたタイプも併用することで、実際の処理開始までの時間を短縮する ことができます。 • ホストEC2を常時起動すると、月あたり数千円以上の料金がかかるため、処理開 始までの時間短縮とコストのどちらを取るか、検討しましょう。 ※お客様の合意が必須となります。 • 今回はしませんでしたが、夜間や休日は処理開始まで待たされてもいい場合、 Lambdaなどで決まった時間にホストのEC2の起動、停止を行うことも有効で しょう。（コスト最適化）
37. ご清聴ありがとうございました。 37