Upgrade to Pro — share decks privately, control downloads, hide ads and more …

2022/10/21 bitstar CROSS 2022 in EZO AWS ECSでのバ...

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

murakami0923

October 20, 2022
Tweet

More Decks by murakami0923

Other Decks in Technology

Transcript

  1. 2 はじめに~今回の内容~ • あるシステム開発の案件でバックエンド側の機能要件 • 演算処理、グラフ・レポート作成など、時間がかかる ※一連の処理で2分以上 • ユーザーからの要求に応じてオンデマンドで実行 ※できるだけ早く結果を見たい

    • 最初はデータが少ないので順に実行するように実装して問題なし (要求が複数来たら順番待ち) • データ量の増加により、順番待ちの時間が長くなり、運用に支障 (とまで言わなくても不便と感じるように) • 並列で処理できる数を増やし、待ち時間を短縮したい この課題をAWSのECSで解決したので、事例を紹介します。
  2. 目次 4 BS150105 • 自己紹介 • 開発の背景 • システムの概要 •

    Amazon ECSで構築する前 • Amazon ECSでの構成(1) • 新たな問題発生 • Amazon ECSでの構成(2) • まとめ
  3. 5 自己紹介 • ビットスター株式会社 サービス事業部 第1事業グループに所属する、 村上 將志(むらかみ まさし)と申します。 •

    北海道出身で7年ほど北海道勤務でしたが、2019年春に大阪へ転勤とな り、大阪市住吉区(一番南の区)に生息しています。 • 開発チームで、主にWebシステムの開発に携わっています。 • 好きなAWSサービスは、ECS Fargate、CloudFormationです。 名刺 Facebook • 今日の話について詳しく話してみたい、などありましたら、ご連絡くだ さい。
  4. 7 開発の背景 • 開発したシステム(概要) • 医療検査機器を開発するスタートアップのお客様からシステム開発を受注 ※検査データの解析サービスを医療機関等へ提供 • システムのユーザーは医療機関の医師、看護師、上記お客様 •

    検査機器で計測してできたバイナリデータを処理し、レポートを自動で作成 • 開発概要 • 2013年秋から開発し、2014年春に本番稼働を開始しました。 • CentOS6、PHP、ビットスター独自フレームワーク、MySQL • 岩見沢iDCにサーバ設置、運用していました。
  5. 8 開発の背景 • 2018年秋ごろ、お客様からセキュリティについてご要望をいただきました。 • 「医療情報システムの安全管理に関するガイドライン」への対応 • 経済産業省、厚生労働省、総務省の3省から • 新たなOSでの構築(CentOS

    7、あるいはそれ以降) ※CentOS6 : 2020年11月でサポート終了 • OSパッケージ、ライブラリ、フレームワーク等にセキュリティに問題が あっても、パッチが出てシステムに適用可能なこと • お客様のご要望を受けて、下記方針で開発することになりました。 • AWSに移行 ※上記ガイドラインへの対応リファレンスが明示されているため • OSはAmazon Linux 2を採用(CentOS 7互換) ※サポート期限:2024/06/30 • 世界で広く使われているPython Djagoでリプレース ※当社で開発実績あり
  6. 10 システムの概要 • 開発したシステム(概要) • 医療検査機器を開発するスタートアップのお客様からシステム開発を受注 ※医療機関等に対して検査データの解析サービス • システムのユーザーは医療機関の医師、看護師、上記お客様 •

    検査機器で計測してできたバイナリデータを処理し、レポートを自動で作成 • この処理をバックエンドとして開発 • バイナリデータ解析のコアプログラムは別の専門家が開発 →システムからOSコマンドで呼び出す →解析結果をテキストファイルに出力してくれる • その結果を元に、集計・演算、グラフとレポートを作成
  7. 13 システムの概要 2分 一 連 の タ ス ク を

    、 こ の 青 い 帯 で 表 現 し 、 このタスクがどのような順で実行されるか、 ここから先紹介していきます。 一連の処理で、平均して2分ほどかかる。 ※レポートの種類、言語によっては2分半
  8. 0分 1分 2分 4分 5分 6分 7分 8分 9分 3分

    10分 15 Amazon ECSで構築する前 • Webサーバ(操作画面でのリクエストを受け付ける)とは別に、解析サーバを 構築し、常時起動 • cronで15秒ごとに処理待ちのタスクがないかチェック • 処理待ちのタスクがある場合、バックエンドのタスクを実行 • 同時に2つまでバックエンドタスクを実行可能 例:10個のデータをアップロードされた場合 1 2 3 4 5 6 7 8 9 10 • タスク10個:10分少々 • タスク100個:約100分(単純計算)
  9. • Amazon ECSとは? • Amazon Elastic Container Serviceの略 • AmazonがAWSの中で提供する、フルマネージドのコンテナのオーケストレー

    ションサービス ※Kubernetesよりシンプルな構成に適しており、使いやすいです。 • コンテナの起動タイプは2種類あります。 • EC2ホスト:コンテナのホストとなるEC2インスタンスをユーザーが用意 し、その中で実行 • ホストのインスタンスの起動時間に応じて課金 • Fargate:サーバーレス(ホストはAWS側で管理) • コンテナイメージダウンロード開始~コンテナ終了まで 18 Amazon ECSでの構成(1)
  10. • Amazon ECSとは? • Amazon Elastic Container Serviceの略 • AmazonがAWSの中で提供する、フルマネージドのコンテナのオーケストレー

    ションサービス ※Kubernetesよりシンプルな構成に適しており、学習コストが低い • コンテナの起動タイプは2種類 • EC2ホスト:コンテナのホストとなるEC2インスタンスをユーザーが用意 し、その中で実行 • ホストのインスタンスの起動時間に応じて課金 • Fargate:サーバーレス(ホストはAWS側で管理) • コンテナイメージダウンロード開始~コンテナ終了まで 19 Amazon ECSでの構成(1) Fargateを使えば、 • バックエンドのタスクを複数同時に並列で処理できる • 終了したらコンテナを破棄することでコストも抑えられる! • 開発環境をDockerで構築しているため、その定義のベース を流用して本番用のDockerfileを作れる これは使える!!
  11. • Amazon ECSの使い方 • あらかじめ • ECR (Elastic Container Repositoryの略で、DockerHubみたいなもの)

    にイメージをpushしておきます。 • ECSクラスタ、タスク定義を作成しておきます。 • 処理の依頼が来たら、コンテナのタスクを起動します。 • AWS CLIで起動 • プログラムからSDKで起動 ※コンテナのタスクは複数起動できます。 20 Amazon ECSでの構成(1)
  12. 22 Amazon ECSでの構成(1)~Fargateを使用した場合のバックエンド処理の流れ~ ① (Webサーバ01) 処理待ちのタスクがな いか、監視(cron) ※解析サーバがないの で、ここで監視 ②

    (Webサーバ01) タスクがある場合、ECS のタスクを開始 ③ (ECS内部) ECRからコンテナのイ メージをダウンロード ④ (ECS内部) イメージがダウンロード できたらタスク(コンテ ナ)を開始 ⑤ (コンテナ内) 処理を実行 ⑥ (コンテナ内) 処理完了時に、ほかの処理待ちのタスクが ある場合→次のタスク⑤へ ない場合→コンテナを終了・破棄
  13. 9 0分 1分 2分 4分 5分 6分 7分 8分 9分

    3分 10分 23 Amazon ECSでの構成(1)~並行処理の動作の予測、期待~ 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と した場合
  14. 9 0分 1分 2分 4分 5分 6分 7分 8分 9分

    3分 10分 24 Amazon ECSでの構成(1)~並行処理の動作の予測、期待~ 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 このような動きを期待したが、 現実は甘くなかった・・・。 →新たな問題発生
  15. 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と した場合
  16. 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 お客様
  17. 28 新たな問題発生~なぜ起動に時間がかかる?~ Fargateはサーバーレスのため、イメージをキャッシュ せず、毎回イメージをダウンロード →タスクの起動に時間がかかる ① (Webサーバ01) 処理待ちのタスクがな いか、監視(cron) ※解析サーバがないの

    で、ここで監視 ② (Webサーバ01) タスクがある場合、ECS のタスクを開始 ③ (ECS内部) ECRからコンテナのイ メージをダウンロード ④ (ECS内部) イメージがダウンロード できたらタスク(コンテ ナ)を開始 ⑤ (コンテナ内) 処理を実行 ⑥ (コンテナ内) 処理完了時に、ほかの処理待ちのタスクが ある場合→次のタスク⑤へ ない場合→コンテナを終了・破棄
  18. 31 Amazon ECSでの構成(2)~EC2ホストとFargateの併用~ ① (Webサーバ01) 処理待ちのタスクがな いか、監視(cron) ② (Webサーバ01) タスクがある場合、ホ

    ストEC2内のタスクが 上限に達してなければ ホストEC2でECSのタ スクを開始 ③ (ECS内部) 初回、ECRからコンテナのイメージ をダウンロード →ホストEC2内にキャッシュされる →次回起動が速くなる ④ (ECS内部) イメージがダウンロードできたら、 あるいは、EC2の中にイメージの キャッシュがあれば、 タスクを開始 ⑥ (ECS内部) Fargateで起動された場合は、ECRか らコンテナのイメージをダウンロー ドしてタスクを起動 ⑤ (Webサーバ01) タスクがある場合、 EC2ホストのタスクが 上限に達していれば、 FargateのECSのタス クを開始 ※同時起動:4に制限
  19. 21 0分 1分 2分 4分 5分 6分 7分 8分 9分

    3分 10分 32 Amazon ECSでの構成(2)~即時起動+並列処理の実現~ 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
  20. 0分 1分 2分 4分 5分 6分 7分 8分 9分 3分

    10分 33 Amazon ECSでの構成(2)~即時起動+並列処理の実現~ 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で並列で処理することができた。 ↓ データ増にも対応できた!
  21. 34 AWSコスト • ECSのホストEC2(第2構成案で追加) • t3.mediumで構築 • CPU+メモリ:約40 USD/月 •

    バーストによるCPUクレジット:約8~10 USD/月 • EBS(ディスク):3.6 USD/月 • 合計50~55 USD/月 ※月の日数、および、バースト(ベースラインを超えたCPU使用率が使用できる状況) の状況によ り度変動します。 • 月ごとにかかるコストはほぼ横ばいです。 • 今回は、このコストをかけてでも、すぐに処理が始まることを優先しました。 • ECS Fargate • コンテナの起動時間に応じて従量課金となります。
  22. 36 まとめ • 演算やグラフ・レポート生成などの処理を、ユーザーからの要求に応じてオン デマンドで順次実行していきたいという場合、Amazon ECSにより並行して処 理を行うことができます。 • ECS Fargateでは処理時間での従量課金になるため、オンデマンドでのバック

    エンド処理を並列で行いたいときに有効でしょう。 • ただし、Fargateでは、コンテナのイメージが大きい場合にイメージのダウン ロードに時間がかかるため、実際の処理開始まで待たされることがあります。 • オンデマンドでの処理をすぐに開始したい場合、Fargateだけではなく、EC2を ホストとしたタイプも併用することで、実際の処理開始までの時間を短縮する ことができます。 • ホストEC2を常時起動すると、月あたり数千円以上の料金がかかるため、処理開 始までの時間短縮とコストのどちらを取るか、検討しましょう。 ※お客様の合意が必須となります。 • 今回はしませんでしたが、夜間や休日は処理開始まで待たされてもいい場合、 Lambdaなどで決まった時間にホストのEC2の起動、停止を行うことも有効で しょう。(コスト最適化)