2020年5月8日まで開催しているAWS Startup Day 2020に参加しました。
スタートアップ向けのオンラインカンファレンスであり、実践的な内容のセッションを無料で視聴できます。1セッションあたり約30分で、10以上のセッションが用意されています。
今回はコンテナ関連のセッションを2つ視聴しましたのでレポートします。
目次
[T-2] スタートアップのためのコンテナ入門
概要
セッションレポート
1. コンテナ化するコンポーネントを選定する
- 全体のコンポーネントを把握する
- 複数のコンポーネントとが相乗りしている場合は分ける
- Application Server (Ruby on Rails 等)や、Job Worker (Sidekiq 等)
- コンポーネントを限定して移行するのがおすすめ
2. アプリケーションをコンテナに最適化する
- AutoScaling 対応出来ているかが大事
- インスタンスを横に並べただけだと、保管しているデータに違いが出る
- インスタンスの外へデータを保管しステートレスにする
- データベース → Amazon Aurora
- セッション → Amazon ElastiCache
- 画像等 → Amazon S3
- ログ → Amazon CloudWatch Logs
3.コンテナイメージの作成
- Dockerfile があれば、再現性のあるビルドが容易に
- まずは動く状態に持っていくのが最優先
- ステートレスなコンテナを作る
- 1コンテナ1プロセス
- アプリのログは標準出、標準エラー出力
- 設定ファイルではなく環境変数を利用する
4.イメージレジストリに登録
- イメージレジストリに登録しないとコンテナが手元にあっても利用しづらい
5.本番環境の構成を考え、実装する
- 最初はクラスターの事前準備が不要な Amazon ECS / AWS Fargate がオススメ
6.デプロイフローの自動化
- コンテナワークロードにおいて、コンテナ イメージを作成し、配布することは基本
- ビルドされていないコンテナイメージは利用できない
- 自動化しないとオペレーションミスに繋がる
- ソースコード更新時に最新のイメージを配布
- インスタンスもコンテナも同じ運用
まとめ
- オーケストレーションツールは「5.本番環境の構成を考え、実装する」から関わるので、「4.イメージレジストリに登録」までのコンテナ化した後に決定でも良い
- 「2. アプリケーションをコンテナに最適化する」と「. デプロイフローの自動化」は仮想マシンとコンテナで考え方は大きく変わらない
[T-3] PCIDSS で疲弊しないための Fargate 活用
概要
1. コイニーとPCI DSS
- FinTech系サービスには、とにかく「信頼」が求められる
- 旧アプリはEC2で稼働している
- PCI DSSは大まかに12要件あって、詳細まで含めると400件ある
2. これまでのセキュリティ対策
- 要件 5：ウイルス対策についての要件
- 対策
- ClamAVで日次スキャン
- スキャンログはCloudWatchLogsに転送し、問題を検知したら管理者にメール
- 課題
- ClamAV のソフトウェア自体の更新作業は別途行う必要がある
- 各ロググループからのログ収集が大変
- 対策
- 要件 6：ミドルウェアの脆弱性についての要件
- 対策
- Amazon Inspectorで週次スキャン
- 脆弱性が見つかったらミドルウェアを更新
- 課題
- Amazon Inspectorがやってくれるのは「検知」までなので、ssh ログインして yum update をかける必要がある
- 手順を誤るとサービスが停止するリスクがある
- 対策
- 要件 11：侵入検知・変更検出についての要件
- 対策
- DeepSecurityを導入しリアルタイムで検知する
- 課題
- ライセンス費用が高い
- 対策
監査は準拠するまでだけでなく準拠した後も大変
しかし、これらは差別化につながらない重労働でありサービス価値は上がらない
3. コイニーでのAWS Fargate導入
- EC2 VS Fargate
- EC2 起動タイプだと、足元で動いている EC2 を意識する必要がある
- Fargate 起動タイプだと、EC2 を意識する必要がなくなる
- Fargateにしたことでセキュリティ対策が変わった
- 要件 5：ウイルス対策についての要件
- 対策
- 追加作業なし
- 考えかた
- Fargate を使う場合、コンテナを動かすためのインフラストラクチャを抽象化できるため、サーバに対するウイルス対策は不要と判断
- 対策
- 要件 6：ミドルウェアの脆弱性についての要件
- 対策
- Amazon ECR イメージスキャンで週次スキャン
- 脆弱性が見つかったらコンテナイメージを更新
- 考えかた
- Fargate を使う場合、コンテナを動かすためのインフラストラクチャを抽象化できるため、サーバ自体のOS・ミドルウェアの脆弱性対策は不要と判断
- ただし、コンテナイメージの管理については利用者の責任範囲
- 対策
- 要件 11：侵入検知・変更検出についての要件
- 対策
- 追加作業なし
- 考えかた
- Fargate を使う場合、コンテナを動かすためのインフラストラクチャを抽象化できるため、サーバ自体の侵入検知・変更検出についての対策は不要と判断
- 対策
まとめ
- PCI DSS に耐えうるインフラの構築には、マネージドサービスの活用が鍵
- 監査業務を省力化して、プロダクトの価値向上にフォーカス
感想
仮想マシンをコンテナに移行するために、まずはAutoScaling対応させることが重要だと理解できました。また、Fargateを利用することでセキュリティや監査業務を省力化できるのは眼から鱗でした。今の現場でも同様の課題があるため、今回の内容を活かした提案をしていこうと思います。