EC2で稼働していたRailsアプリを ECSに移⾏した話 Sansan株式会社 DSOC 技術本部 サービス開発部 Infrastructure Group 藤⽥ ⻫ 2021.11.05 CloudNative Days Tokyo 2021 

Data Strategy and Operation Center ⾃⼰紹介 藤⽥ ⻫ Hitoshi Fujita Sansan株式会社 技術本部 サービス開発部 Infrastructure group • 前職では独⽴系SIerで主に⾦融系のインフラ構築に従事 • 2018年にSansan株式会社へ⼊社 • DSOCが提供する各種サービスのインフラ構築・運⽤を担当 • 趣味はバスケットボールとTVゲーム 

Data Strategy and Operation Center アジェンダ・ゴール 2 w アジェンダ w 背景、モチベーション w 設計、実装 w 移⾏後の課題 w ゴール w 事例・TIPSを共有し、どこかで皆様のお役に⽴てば嬉しいです 

背景、モチベーション 

Data Strategy and Operation Center 名刺データ化システムとは 4 マイクロタスク×マルチソーシングによる独⾃の名刺データ化システム 名刺取り込み 背景分離 画像補正 1 項目分割 2 セキュリティー項目細分割、項目入力 3 チェック＆補正 5 マージ 4 セキュアな環境を構築 

Data Strategy and Operation Center システム構成 5 サービス構成 w 各プロセスをサービスに切り出し、それぞれWeb APIと複数の⾮同期ワーカーで構成 w ⾮同期ワーカーはSidekiqキュー、SWFキュー、データベースから読み込み w バッチ処理などのスケジュール実⾏はRundeckで制御 インフラ構成 w EC2で稼働 > Webサーバ、Batchサーバ、管理Webサーバ、etc... w 1台のBatchサーバには複数サービスのワーカーが配置される > ワーカー数は独⾃に開発した管理ツールで運⽤ 技術スタック w Ruby, Ruby on Rails > EC2, RDS, S3, ElastiCache, Elasticsearch, SWF, etc… 

Data Strategy and Operation Center ワーカー運⽤の課題 6 ① 空きリソースを確認 ワーカー 管理ツール ② 指定したホストに ⼿動で追加 EC2 Instance EC2 Instance EC2 Instance Worker 1 Worker 3 Worker 3 Worker 3 Worker 2 Worker 2 Worker 1 Worker 4 Worker 4 Worker 4 ワーカーの追加、削除の運⽤負荷が⾼い 

Data Strategy and Operation Center ワーカー運⽤の課題 7 ① 空きリソースを確認 ワーカー 管理ツール ② 指定したホストに ⼿動で追加 EC2 Instance EC2 Instance EC2 Instance Worker 1 Worker 3 Worker 3 Worker 3 Worker 2 Worker 2 Worker 1 Worker 4 Worker 4 Worker 4 ワーカーをコンテナ化、オートスケーリングで 運⽤負荷を減らしたい！ ワーカーの追加、削除の運⽤負荷が⾼い 

設計、実装 

Data Strategy and Operation Center 実装のポイント 9 w コンテナ管理 w データプレーン w オートスケーリング w スケジュール実⾏ w デプロイ管理 w Rails Console 

Data Strategy and Operation Center ECSを選定 コンテナ管理 10 ECS · パワフル&シンプル > サービスの責任範囲が明確、他AWSサービスとの親和性が⾼い EKS · オープン&フレキシブル > 豊富なエコシステム、活発なコミュニティ • Kubernetesでしか達成できないことが無かった • 半年期に⼀回のアップデートに追従できるリソースが無かった 参考: AWS Black Belt Online Seminar 

Data Strategy and Operation Center EC2を選定 データプレーン 11 Fargate · EC2の管理不要 · よりセキュアな実⾏環境 EC2 · CPU/MEMの組み合わせに制限なし · GPUの利⽤が可能 • サービス毎に性能要件にばらつきがあり、Fargateでは⼤幅にコスト増 • Scheduled TaskではFargateを採⽤ • ECS Cluster Auto Scalingを利⽤することでインスタンス管理コストを低減 

Data Strategy and Operation Center データプレーン 12 ECS Task EC2 Application Auto Scaling EC2 Auto Scaling ECS Task EC2 Application Auto Scaling ECS Cluster Auto Scaling CapacityProvider ECS Cluster Auto Scalingなし ECS Cluster Auto Scalingあり w EC2はECSと独⽴しており、 CPUやMEMの使⽤率などを元に オートスケール w Capacity Providerを利⽤することで、 ECSのタスク数と連動して EC2インスタンスをオートスケール 

Data Strategy and Operation Center オートスケーリング 13 Target Tracking Scaling w メトリクスが⽬標値を保つようにタスク数を調整 > 時間あたりの⽬標処理量が決まっているものにマッチ w Webコンテナに利⽤（リクエスト数、CPU使⽤率） Step Scaling w しきい値を上回った or 下回ったとき、指定した値に基づきタスク数を調整 w ⾮同期ワーカーに利⽤（Sidekiqキュー、SWFキュー） > キューは常に0を⽬指すため、しきい値を超えた場合にスケールアウトし続ける > SidekiqのキューはECS Scheduled Taskでカスタムメトリクスに登録 

Data Strategy and Operation Center オートスケーリング 14 Schedule Scaling w スケジュールに沿ってタスクの最低/最⼤起動数を調整 > 予測されるリクエストのバーストに対応 

Data Strategy and Operation Center オートスケーリング 15 Worker EC2 Batch Instances CloudWatch Metrics Auto Scaling group (Capacity Provider) Web EC2 Web Instances Datadog Agent Fluentd Scheduled Task Fargate Datadog Agent Fluentd Auto Scaling group (Capacity Provider) Application Auto Scaling Post custom metrics Application Load Balancer Get metrics Step Scaling Target Tracking Scaling Scheduled Scaling 

Data Strategy and Operation Center スケジュール実⾏ 16 ECS Scheduled Taskをecscheduleで管理 w Scheduled Taskの実態はEventBridgeからECSタスクの実⾏ > EventBridgeは最低1回の実⾏保証のため、アプリケーション側で対応が必要 w 設定管理はecscheduleを利⽤、ジョブ構成をGitHub上で管理可能に > EventBridge、ECSタスク定義それぞれ管理が必要 > アプリケーションのライフサイクルに依存するためTerraformではミスマッチ > 適⽤はデプロイパイプラインへ組み込み、CodeBuildで実⾏ Amazon ECS Amazon EventBridge AWS CodeBuild Create/Modify by ecschedule Run Task AWS CodePipeline 

Data Strategy and Operation Center デプロイ管理 17 CodePipeline + CodeBuild + ecs-cliで実装 w CodePipeline/CodeBuild > 複数アプリケーションの同時デプロイ、デプロイフェーズをコントロール > ⼿動承認をAPI Gateway + LambdaでSlackから · 現在ならSlackのSocket Modeを利⽤することでFargateで置き換えれそう > CodeBuildで各サービスごとにecs-cliでデプロイ w ecs-cli > AWS公式かつ、docker-composeと互換性あり開発者との親和性が⾼いと思い採⽤ · ただし、現在はほとんど更新されていない > 今からであればecspressoがおすすめ > シンプルな構成であればそもそもCLIツールは不要 

Data Strategy and Operation Center デプロイ管理 18 

Data Strategy and Operation Center Rails Console 19 背景 w 調査、障害対応などでRails Consoleを利⽤することがある w アプリケーションコンテナに `docker exec` するのは避けたい w 本番稼働に不要なツールを配置したくない 対応 w アプリケーションコンテナとは別にRails Console⽤コンテナを作成 w 起動スクリプトで必要なツールをコンテナ起動時にインストール w EFS、S3を利⽤して⼀時ファイルの保管場所を準備 

Data Strategy and Operation Center Rails Console 20 

Data Strategy and Operation Center 実装のまとめ 21 コンテナ管理、データプレーン w エンジニアリソース、サービス毎の特性を考慮して ECS on EC2を採⽤ w EC2はCapacity Providerを利⽤して運⽤コストを削減 オートスケーリング w それぞれの特性に合わせた⽅式を採⽤ スケジュール実⾏ w ECS Scheduled Task + ecscheduleでジョブ構成をGitHubで管理可能に デプロイ管理 w CodePipeline + Codebuild + ecs-cliで承認を組み込んだデプロイを実装 Rails Console w 独⽴したECSサービスとして準備 

移⾏後の課題 

Data Strategy and Operation Center スケールインされない スケールインされる Deep Dive on Amazon ECS Cluster Auto Scaling 課題 w EC2全体で⾒るとリソースに余剰があってもスケールインが発⽣しない w 各EC2で1つでもタスクが動いている場合、スケールイン/アウトが不要と判断される 対策 w リソース使⽤率の低いEC2をドレインさせる仕組みが必要（未対応） ECS Cluster Auto Scalingのスケールイン 23 

Data Strategy and Operation Center コンテナのOut Of Memory 24 課題 w 稀に⾮同期ワーカーでOut Of Memoryが発⽣、メモリ使⽤率が上昇し続ける事象も w Out Of MemoryʹͳΔͱਖ਼͘͠ऴྃॲཧ͕࣮ࢪ͞Εͣɺ੔߹ੑ͕औΕͳ͍͜ͱ΋ w શ෦͕ͳΔΘ͚Ͱ͸ͳ͍ͨΊɺ༧ΊଟΊʹϦιʔεΛ༧໿͢Δͱίετ͕େ෯ʹ૿Ճ 対策（ワークアラウンド） w EC2でSwapを有効化 w λεΫఆٛͰϝϞϦͷsoft_limitͷΈΛઃఆ w 定期的にワーカーを再起動 

No content

We are hiring！ 新規事業開発 新規事業開発エンジニア ウェブアプリケーションエンジニア PdM（プロダクトマネジャー） コーポレート 社内SRE セキュリティエンジニア （SOC、社内教育・監査） DSOC / 研究開発 インフラエンジニア ⾃然⾔語処理 研究員 社会科学分野 研究員 機械学習 研究員 OCR開発技術者 R&D DevOpsエンジニア データエンジニア サービス基盤エンジニア データサイエンティスト サービス開発 SETエンジニア サービス開発エンジニア ウェブアプリケーションエンジニア インフラエンジニア iOSエンジニア Android エンジニア ブランディング・マーケティング フロントエンドエンジニア 募集職種⼀覧はこちらから https://jp.corp-sansan.com/engineering/recruit/