belltreee

# レセプトサービスのインフラキャパシティプランニング ## 概要 * プロダクトチームと開発チームを巻き込み、クラウドリソースに対する意識改革を推進し、レセプトサービスのパフォーマンス最適化を実現しました ## 使用技術 * Datadog、AWS(Aurora、ECS) ## 業務詳細 * レセプトサービスのインフラリソース利用状況を詳細に分析 * パフォーマンス問題の根本原因を特定するため、分析ダッシュボードを作成 * パフォーマンス、コスト、ユーザー体験を合わせたキャパシティプランニングを作成し、プロダクトチーム、開発チームと検討会を実施 ## 課題 * 開発チーム内でインフラコストに対する意識が低く、非効率な実装がコスト増加につながっていた ## 取り組み * Datadogを活用し、過去6ヶ月のリソース使用傾向を分析 * キャパシティプランニング資料を作成し、プロダクトチーム・開発チームに現状と必要な対策を共有 * 開発チームと協力して、特に負荷の高いクエリとAPI呼び出しを特定し最適化 ## 工夫した点 * 観測データに基づくサービスの今後1年間のインフラリソース利用状況を予測、コストシミュレーションを含む資料を作成し、 お金でパフォーマンスを解決した場合とそうでない場合を比較し、メリット・デメリットを説明 * 定期的なモニタリングレポートを作成し、プロダクト、開発、技術横断の3チームが月1回インフラリソース使用状況を確認する体制を構築し、継続的な最適化活動を実施 ## 成果 * 応答速度が最大80%向上し、ユーザー体験が大幅に改善 * データベース負荷が最大50%削減され、リソース効率が向上 * モニタリングレポートを通して毎月、サービスのパフォーマンスについて関係者同士で自然に会話が始まる状況を構築 * チーム全体のインフラコスト意識が向上し、新機能開発時にも効率性を考慮

# 負荷試験導入 ## 概要 * サービス拡大フェーズに向けて、CIテストでは発見できないアプリケーションとインフラの潜在的な課題を早期発見・対応するための負荷試験環境を構築しました ## 使用技術 * k6、Aurora(AWS)、ECS Fargate(AWS)、Datadog、Docker、CDK ## 業務詳細 * 開発部長に提案し、開発者一名を負荷試験のシナリオスクリプト作成担当として巻き込む体制を構築 * 負荷試験ツールの選定 * 負荷試験の目的、スコープ、成功基準を明確に定義し、関係者間で合意形成を図る ## 課題 * 負荷試験の経験者がチーム内におらず、知見やノウハウが不足 * k6を利用したいが、k6を利用する場合、世間一般では基盤はk8sのものがほとんどであった(k8sは弊社にはアンマッチ) ## 取り組み * 負荷試験に関する業界標準やベストプラクティスを調査し、自社のニーズに合わせたアプローチを設計 * 実際のユーザーアクセス数から、現実的な負荷テストシナリオを開発 * 負荷試験専用環境を準備 * 開発チームと技術横断チームの協力体制を構築し、定期的な進捗共有ミーティングを実施 ## 工夫した点 * アプリケーション側（シナリオ作成含む）とインフラ側で担当を分け、効率的なタスク分担を行 * 負荷試験の目的と期待される成果を明確にし、関係者全員の理解と協力を得られるよう取り組む * 開発者がシナリオ作成に積極的に参加できるよう、知見のある言語でシナリオを書くツールを選定 * 小規模テストから始めて、まずはナレッジをためていくアプローチを採用 * k6を利用する場合、世間一般では基盤はk8sのものがほとんどであったが、弊社のフェーズや開発者でも運用できることを考慮し、サービスで利用していて知見のある「ECS Fargate」を採用 * 負荷試験は「ECS Fargate」に直接ログインし操作できるようにし、その場で負荷パラメータを調整しながら何度も試験可能にし、負荷パラメータ修正に伴うコンテナイメージの再作成の時間を無くした * 負荷試験を実施し、結果から見つかったシステム課題の調査・改善に取り組むまでをゴールとすることで、今後汎用的に使える負荷試験の全工程のテンプレートを作成 ## 成果 * CIテストでは検出できなかったパフォーマンスのボトルネックを複数発見し対応 * アプリケーションとインフラの最大処理能力を明確に把握し、今後の拡張計画の基礎データを得る