ヘルスケアサービスにおけるEC2⇒ECSへの転換とDevOpsの推進【DeNA TechCon 2022】

ヘルスケアで求められるセキュリティ要件をクリアしつつ、開発のスピードをあげるためクラウドのマネージドサービスへどのように転換し、活用していくか。

長らくオンプレで運用していたヘルスケアシステム kencom を昨年クラウドに移行しました。しかしオンプレと同構成のまま移行したため、依然としてオンプレベースの運用となっており、クラウドをうまく活用できている状態ではありませんでした。

このような状況の中で新たなバッチシステムを構築することになり、既存とは異なる ECS on Fargate を中心とした AWS マネージドサービスを活用した新しいアーキテクチャの上で構築していくことにしました。

本セッションではクラウドネイティブの第一歩として新たなアーキテクチャ上にバッチサービスを構築していくなかで、どのように既存の課題やヘルスケアならではのセキュリティ要件に対応していったのかを中心にお話しします。

◆ You Tube
https://youtu.be/Yzz0Pn40ZDY

◆ You Tube チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2022 公式サイト
https://techcon2022.dena.dev/spring/

Transcript

1. ヘルスケアサービスにおける EC2⇒ECSへの転換とDevOpsの推進 Takahiro Kida
2. 自己紹介 • 木田 貴大 (Takahiro Kida) • DeNA ヘルスケア事業本部 • サーバーサイドエンジニア ◦ 主にヘルスケアサービス kencom の機能開発〜運用・保守
3. 本日お話しすること 1. ヘルスケアサービス kencom のご紹介 2. クラウド移行とその後の課題 3. 改善に向けた取り組み 4. まとめ
4. 1. ヘルスケアサービス kencom のご紹介
5. ヘルスケアエンターテイメントアプリ kencom • 健康意識レベルに関わらず幅広い層を対象とするヘルスケアエンターテイメントアプリ • 健康保険組合・地方自治体など、合計約130団体、約400万人以上に提供 • 自動連携された健康診断結果や処方された薬の履歴を kencom で閲覧することができる
6. サービス紹介：ヘルスケア機能 健康状態に応じた 最新健康情報の レコメンデーション 薬の処方履歴 健康診断結果の閲覧 ライフログ
7. サービス紹介：エンターテインメント機能 みんなで歩活 チームや個人で歩数を競うイベント エアモ ペット育成ゲーム
8. 2. クラウド移行とその後の取り組み
9. • 2020年春にオンプレからクラウドに移行 • オンプレでの構成のまま AWS に移行した、所謂クラウドリフト kencom のクラウド移行 ⇨ 旧環境（オンプレミス） • 物理ネットワーク / ファイアウォール • 物理サーバー + 仮想マシン • 内製ツールによる構成管理 • DBやメールサーバー等も自前で構築・運用 新環境（AWS） • VPC / SG • EC2 • 内製ツールによる構成管理 • DBやメールサーバー等も自前で構築・運用
10. インフラ環境の変更に対してスピーディな対応ができない • 環境変数の追加に数日 • イベントでのリソース変更に数週間 クラウド移行後の課題
11. • 運用負荷が高く、改善活動に工数を割くことができていない ◦ DB / メールサーバーなど自前でコンポーネントを運用 ◦ 障害時の復旧対応 • クラウドのメリットをほとんど享受できていない ◦ マネージドサービスによる運用の委譲 ◦ 柔軟なスケーラビリティ ◦ アジリティの向上 クラウド移行後の課題
12. 3. 改善に向けた取り組み
13. 開発チームの方針を転換 • 開発チームもインフラの運用をする ◦ インフラチームに全てお任せにしない ◦ 開発で出来ることは開発でやることでスピード感を上げる • 一気にリプレイスせずに徐々に改善していく ◦ スモールスタートしてチームにノウハウを蓄える ◦ 失敗しても元に戻せば良いという精神 • マネージドサービスを積極的に使う ◦ マネージドサービスファーストで考える。 ◦ 自分たちで頑張らない ◦ 運用負荷を減らして改善活動に当てる
14. そんな中で kencom で新たなサービスが作られることに • 各サービスから横断的にデータを持ってきてレポート集計するサービス ◦ 比較的軽めのバッチ機能 ◦ 運用で対応していたレポート作成を自動化 ◦ 個人情報を扱うためセキュリティ要件は高い • 既存のバッチサーバー上で稼働することを検討
15. 既存の EC2 からの移行も見据えたリアーキテクチャによる新基盤の構築を決意 スモールスタートする良い機会では...?
16. • スケーラブルでアジリティの高いシステム • 開発チームでも運用可能にする • ヘルスケアならではの高いセキュリティの担保 目指すべき姿
17. • アプリケーション実行基盤 ◦ ECS on Fargate • ジョブ管理 ◦ ECS Scheduled Task • CI/CD ◦ GitHub + CircleCI • ログ基盤 ◦ FireLens ◦ CloudWatch Logs ◦ S3 • 監視・通知 ◦ Subscription Filter ◦ EventBridge ◦ SNS / Lambda アーキテクチャ概要
18. スケーラブルでアジリティの高いシステム EC2 ではなく ECS on Fargate を採用 • アプリケーションはコンテナ化 ◦ 開発でアプリケーション実行環境を管理 ◦ 環境構築が不要 • コンテナオーケストレーションの活用 ◦ スケーラビリティの確保 ◦ デプロイの容易性 • データプレーンに Fargate を採用 ◦ サーバーインスタンス管理から解放 ◦ 必要な時に必要なリソースを確保するのため、バッチ処理との相性も◎ • ECS Scheduled Task によるタスクの定期実行が可能
19. スケーラブルでアジリティの高いシステム ECS Scheduled Task の活用 • cron ライクな記述で管理 ◦ 設定ファイルが json でやや扱いにくい • 管理ツール ecschedule ◦ ECS Scheduled Task を管理する OSS ツール ◦ yaml による記述で設定をコード化 ▪ 開発者でも分かりやすい記述が可能に ▪ cron ライクな実行時間 ▪ タスク定義でのコンテナ設定を上書き • 実行コマンド • 環境変数
20. スケーラブルでアジリティの高いシステム アプリケーションリポジトリで インフラコードを管理・変更 • インフラコードの管理 ◦ Dockerfile ▪ OSミドルウェア管理 ◦ ECS タスク定義 ▪ Secrets 管理 ▪ CPU/メモリのリソース管理 ◦ Scheduled Task 定義(ecschedule yaml) ▪ cron 設定 ▪ 環境変数 • 変更作業 ◦ CI/CD を通じて変更 ◦ コード修正 & PRレビュー ◦ 特定のブランチに Push でデプロイ
21. スケーラブルでアジリティの高いシステム スピーディな対応が可能に • 数十分でインフラリソースの変更が可能
22. 開発チームでも運用可能に 新しい仕組みを試しながら、いつでも戻れる状態に • FireLens ◦ ECS で利用可能なログルーター ◦ 柔軟なログ転送が可能 ◦ 複数の転送先を設定可能 • ログの転送先 ◦ CloudWatch Logs ▪ フルマネージドなログサービス ▪ ログの蓄積・検索・閲覧 • S3 ◦ ストレージサービス ◦ 暗号化 ◦ ログの長期保管 ◦ ライフサイクル管理
23. 開発チームでも運用可能に マネージドサービスを活用して実装 開発だけで設定可能に • タスクの異常終了の検知 ◦ EventBridge ▪ ECS タスクの異常終了イベントを検知 ◦ SNS ▪ イベント内容をメール送信 • ログ監視 ◦ CloudWatch Logs Subscription Filter ▪ 特定のパターンのログを検知 ▪ 検知したログを lambda に転送 ◦ lambda ▪ Slack 通知
24. 開発チームでも運用可能に 運用コストの低い基盤の構築して、小さく運用を始めることができた • マネージドサービスを活用して、極力運用の少ない基盤を構築した • 運用を極力無くすことで、改善に時間を割くことができる状態へ • 小さく運用を始めることで、無理なく運用ノウハウを溜めていく • 徐々に旧基盤から新基盤へ移行して、運用を巻き取っていく
25. 高いセキュリティの担保 ヘルスケアで求められるセキュリティ要件はさまざま • アプリケーション実行環境 ◦ サーバーへのアクセス管理 ◦ OS / ミドルウェアバージョンの最新化 ◦ ユーザーアカウントの管理 • ネットワーク ◦ 本番ネットワークへのアクセス制限 ◦ インターネットからのアクセス制限 • 権限管理 ◦ 最低限の権限のみを付与 ◦ アクセスキーの管理 • データ保護 ◦ 暗号化 ◦ 鍵管理 ◦ Secretsの管理 • 監査 ◦ 操作ログの取得 ◦ ネットワーク関連ログの取得
26. Amazon ECS on Fargate 責任共有モデルを理解 守るべき場所を把握して、しっかりと守る • クラスタやサーバーインスタンスのセキュリティ ◦ AWS が担保 • コンテナ、IAM、ネットワーク、データ保護 ◦ 自身で管理 ▪ AWS サービスをフル活用して対応 引用元：https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/bestpracticesguide/security-shared.html 高いセキュリティの担保
27. 高いセキュリティの担保 うまく AWS サービスを活用して適切にセキュリティを担保 • アプリケーション実行環境 ◦ サーバーへのアクセス管理 ◦ OS / ミドルウェアバージョンの最新化 ◦ ユーザーアカウントの管理 • ネットワーク ◦ 本番ネットワークへのアクセス制限 ◦ インターネットからのアクセス制限 • 権限管理 ◦ 最低限の権限のみを付与 ◦ アクセスキーの管理 • データ保護 ◦ 暗号化 ◦ 鍵管理 ◦ Secretsの管理 • 監査 ◦ 操作ログの取得 ◦ ネットワーク関連ログの取得
28. • データ保護 ◦ データの暗号化 ▪ S3 SSE-KMS ◦ 鍵管理 ▪ KMS ◦ Secrets 管理 ▪ AWS Secrets Manager • 監査 ◦ 操作ログの取得 ▪ CloudTrail ◦ ネットワーク関連ログの取得 ▪ VPC flow logs うまく AWS サービスを活用して適切にセキュリティを担保 • アプリケーション実行環境 ◦ コンテナの保護 ▪ ECR イメージスキャン ▪ ライフサイクルポリシー(古いイメージの削除) • ネットワーク ◦ VPC ネットワークの制限 ▪ AWS Private Link ▪ Security Group • 権限管理 ◦ IAM ポリシー / ロールの適切な設定 ▪ ECS Task の権限 / 実行権限 ▪ 各 AWS リソースへのアクセス権限 ▪ ソース IP による制限 高いセキュリティの担保
29. 4. まとめ
30. 開発チームの方針転換 (再掲) • 開発チームもインフラの運用をする ◦ インフラチームに全てお任せにしない ◦ 開発で出来ることは開発でやることでスピード感を上げる • 一気にリプレイスせずに徐々に改善していく ◦ スモールスタートしてチームにノウハウを蓄える ◦ 失敗しても元に戻せば良いという精神 • マネージドサービスを積極的に使う ◦ マネージドサービスファーストで考える。 ◦ 自分たちで頑張らない ◦ 運用負荷を減らして改善活動に当てる
31. 目指すべき姿 (再掲) • スケーラブルでアジリティの高いシステム ◦ ECS on Fargate を活用してスケーラビリティを確保した ◦ 開発チームも運用することでアジリティを向上できた • 開発チームでも運用可能にする ◦ マネージドサービスを活用することで、運用コストを最小にする ◦ スモールスタートして徐々に開発チームでも運用可能にする • ヘルスケアならではの高いセキュリティの担保 ◦ AWS との責任共有モデルを理解して、出来るだけ AWS に任せる ◦ AWS サービスをうまく活用してセキュリティを担保する
32. • 開発チームも運用をしてみると、アジリティは向上する ◦ 全てをインフラチーム任せにしない、インフラチームと協力した運用 ◦ インフラチームには専門性の高いところに集中してもらう ◦ 理解が深まり、改善について考えるようになる • チーム内にクラウドシフトへの期待感が高まる ◦ スモールスタートして成功体験することで、チーム内に期待感が生まれる ◦ 新しい提案や導入がしやすくなる 最後に
33. ご清聴ありがとうございました。 Cloud Journey will be continued…