運用まで考慮したクラウドアーキテクチャ設計できてますか？

by mars_eu

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 ● 名前村瀬善則 ● 前職独立系SIer ● 一言で言うとアプリもわかるインフラアーキテクト ● LIKE リファクタリング、トラブルシューティング、性能改善

Slide 3

Slide 3 text

目次 ● 会社紹介 ● システムが増加していっても耐えられる設計をしよう ● インシデント発生から早期復旧のために ● 踏み台について ● 設定一つで自動的に削除しよう ● まとめ

Slide 4

Slide 4 text

会社紹介

Slide 5

Slide 5 text

特徴

Slide 6

Slide 6 text

TIG(Technology Innovation Group)とはフューチャーにおける技術組織主なミッション ● 最先端、かつ先進的なテクノロジーのプロフェッショナル集団 ● プロジェクト品質と生産性の向上 ● 自社サービス事業の立ち上げ TIG CSIG SAIG AI特化セキュリティ特化 Security IoT ・・・ BigData AI Cloud

Slide 7

Slide 7 text

宣伝

Slide 8

Slide 8 text

おことわりこれからご紹介する内容は個人の見解を含みます。

Slide 9

Slide 9 text

システムが増加していっても耐えられる設計をしよう

Slide 10

Slide 10 text

サービスリリース時は良かったものの… AWS Cloud VPC SystemA

Slide 11

Slide 11 text

成長、時間経過とともに… AWS Cloud VPC SystemA VPC SystemB … システムの肥大化別システムの追加 NEW

Slide 12

Slide 12 text

問題が発生する 💀上限緩和の限界 💀スロットリングの頻発 💀IaCの実行が遅くなっていく 💀管理外のシステムを変更してしまう 💀権限制御が複雑

Slide 13

Slide 13 text

上限緩和の限界 AWSの各サービスの上限は上限緩和申請によって増加させることができる。しかし、無制限に緩和可能なわけではない。たとえばS3のバケットは1,000個までしか作成できない。

Slide 14

Slide 14 text

スロットリングの頻発 AWSサービスによってはコンポーネント単位ではなくアカウント、リージョン単位でスロットリングの閾値を持っているものがある。あるシステムで発生したスロットリングが別のシステムに影響することが発生しうる。以前はパラメータストアは10tps程度であった。 (現在は1000tpsまで拡張可能)

Slide 15

Slide 15 text

IaCの実行が遅くなっていくインフラをコードで管理できるのでIaCはとても便利◎ システムが肥大化するとプランやデプロイに掛かる時間が長くなる。最初は数十秒で完了していた処理が気がつけば数十分になっていることも。

Slide 16

Slide 16 text

管理外のシステムを変更してしまう権限制御が適切になされていないと、管理外のシステムを変更・削除できてしまい、本番環境であればサービス影響が発生しうる。

Slide 17

Slide 17 text

権限制御が複雑先の問題を解消するため、IAMによる権限制御を実施しようとした場合、割に合わない作業が発生する。

Slide 18

Slide 18 text

これらの問題を解消します！

Slide 19

Slide 19 text

解消方法 ● AWS Organizations ● SCP(Service Control Policy) ● Switch Role ● IaCの分離

Slide 20

Slide 20 text

AWS Organizations & SCP AWSアカウントを複数作成・管理でき各AWSアカウントのroot,adminよりも強い権限制御が可能。引用 https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_getting-started_concepts.html

Slide 21

Slide 21 text

AWS Organizations & SCP おすすめの設定 ● 本番用のOUを作成し、初期構築後のクリティカルな変更を禁止する。 ○ KMSの削除禁止 ○ CloudTrailの変更禁止 ○ S3バケットの削除禁止 ○ RDSの削除禁止 ● サンドボックス用のOUを作成し、利用させたくないAWSサービス、高額なインスタンスタイプを禁止する。

Slide 22

Slide 22 text

一度のログインで複数アカウントを利用 jump develop staging production Develop Role Staging IAM Production Role IAM User login(ID/PW) Switch Role

Slide 23

Slide 23 text

システム・環境ごとにアカウントを用意 jump SystemA develop SystemA staging SystemA production Develop Role Staging IAM Production Role IAM User login(ID/PW) SystemB develop SystemB staging SystemB production Develop Role Staging IAM Production Role Switch Role

Slide 24

Slide 24 text

IaCの分離システムの規模・特性にもよるが、適切な分離をする。 ● サービス提供 ● CI/CDパイプライン ● 監視メリット ● IaCのプラン、デプロイ時間の短縮 ● サービス提供に直接関係ない部分の更新が気楽

Slide 25

Slide 25 text

問題の解消上限緩和の限界スロットリング IaCの実行が遅くなっていく管理外のシステムを更新・削除してしまう権限制御が複雑システムごとにAWSアカウントを用意する IaCの分離 AWS Organizationsの利用 SCPの利用問題解消法

Slide 26

Slide 26 text

インシデント発生から早期復旧のために

Slide 27

Slide 27 text

インシデント発生から復旧までインシデント検知、原因特定、不具合解消の時間を短縮することで復旧までの時間が短縮可能。復旧不具合解消原因特定インシデント検知インシデント発生フロー早期復旧のために

Slide 28

Slide 28 text

インシデント検知の勘所検知の目的問題に気付き、対応をする監視項目 ● 異常監視発生した異常を通知する。 ● 予兆監視このまま放置すると障害が発生することを通知する。

Slide 29

Slide 29 text

ありがちな失敗何でもかんでも通知し、重要な通知を見逃す。

Slide 30

Slide 30 text

監視対象 LB DB compute USERS POINT1 エラーレスポンス、応答時間を監視するのはクライアントに一番近い個所。なぜなら後方のエラーレスポンス、応答時間よりも確実に大きいため例 Aurora 50msec < EC2 80msec < ALB 100msec サービス特性によるが単位時間あたりにアクセスが一度も来ないのも異常。 POINT4 空きストレージ容量が枯渇しないよう早期に予兆監視する。 POINT2 computeに関してはメトリクスではなくエラーログを監視する。対応不要なものは通知しない。 POINT3 CPU、memoryが高くてもパフォーマンスが良好であれば問題ない。

Slide 31

Slide 31 text

原因特定の勘所モノリシックとは異なり、マイクロサービスでサービスが作成されている場合、問題発生時にコンポーネントを一つ一つ確認していくと不具合箇所の特定に時間を要する。

Slide 32

Slide 32 text

X-Ray(APM)を利用しよう俯瞰的に関連、エラー種別、実行速度が可視化可能。引用 https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/aws-xray.html https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-concepts.html 緑は、正常な呼び出し赤は、サーバー障害 (500 系のエラー) 黄色は、クライアントエラー (400 系のエラー) 紫は、スロットリングエラー (429 リクエストが多すぎる)

Slide 33

Slide 33 text

アプリのエラーログを出力しよう問題のアプリがわかったとして、どの機能で問題が発生しているかはエラーログを見るべき。適切なログが出力されてないと切り分けは難しい。エラー発生時には必要な情報と共にログを出力するよう設計段階からもれなく実施する。

Slide 34

Slide 34 text

インシデント発生時に備え用意しよう復旧不具合解消原因特定インシデント検知インシデント発生アプリエラーメトリクス異常アプリログ監視メトリクス監視アプリログ確認 X-Rayで特定アプリ修正データ修正アプリ修正データ修正チューニングセキュリティ本日は話しません。機会があればいつかどこかで

Slide 35

Slide 35 text

踏み台について

Slide 36

Slide 36 text

よくある問題 ● 長い間セキュリティパッチがあたっていない。もしかしてマルウェアが混入しているかも？ ● 不要なデータが放置される。ストレージ容量が不足していて大きなデータを扱えない。

Slide 37

Slide 37 text

踏み台を使い捨てにしよう業務特性にもよるが常時踏み台を用意する必要はない。必要な際に設定済みのイメージから踏み台を生成し、不要になったタイミングで破棄する。メリット ● セキュリティの向上 ● セキュリティパッチのメンテナンスが不要 ● コスト低減デメリット ● Historyが毎回削除される。

Slide 38

Slide 38 text

内部犯行の抑止 DBへアクセスできるため便利な一方で、情報持ち出しなど内部犯行に利用されうる。内部犯行させないため、以下の対応が有効。監査ログの保全 ● CloudWatchLogsやS3にログを出力し削除させない。ログインしたことがバレるようにする。 ● slackなど皆が容易に確認可能なツールに投稿する。

Slide 39

Slide 39 text

設定一つで自動的に削除しよう

Slide 40

Slide 40 text

背景と目的データやログに関して一定期間は保持しなければならないが、期間を過ぎた場合には不要になる。ストレージコストの低減や検索速度の向上を図りたい。

Slide 41

Slide 41 text

実現方法 AWSではサービスの機能として用意されている。 ● S3 ライフサイクルポリシーの設定 ● DynamoDB TTLの設定 ● CloudWatchLogs 保持期限の設定便利な機能は積極利用。無駄なことはやめよう。

Slide 42

Slide 42 text

まとめ

Slide 43

Slide 43 text

まとめ運用まで考慮した設計について説明しました。 ● システムが増加していっても耐えられるようAWS Organizations、SCPを利用しましょう。 ● インシデントの早期復旧のため適切な監視、X-Rayの利用、アプリログを出力しましょう。 ● 踏み台は内部犯行を抑止しましょう。使い捨てにするのもいいかも。 ● 削除に関して便利な機能を利用しましょう。

Slide 44

Slide 44 text

Thank you for listening.