AWS Well-Architected Partner Virtual Bootcamp に参加してきました

先日、12/22 に行われたAWS Well-Architected Partner Virtual Bootcamp に参加してきました。

これはAPNパートナー向けにWell-Archtected のワークショップをオンラインで行うというものです。 Well-Architected Framework は以下のリンクからアクセスできます（言語設定を英語にするとSaaSレンズが確認できます）。

aws.amazon.com

今まではAPNパートナー向けに開催するケースはそこまで多くなく、2回目（かつオンラインでは初）の試みだったようです。

他社の方とワークショップを行う機会はなかなかなく、良かったのでそのレポートです。

ワークショップの流れ

一週間くらい前に事前に登録を行い、参加しました。 前日に、当日利用する資料が届き、当日はAmazon chime でワークショップが行われました。

当日は次のようなスケジュールで進行されました。

時間 内容
10:00 ~ 11:50 Well-Architected フレームワークについてのおさらい
11:50 ~ 13:00 ワークショップの題材となる資料の読み込み、お昼休憩
13:00 ~ 14:25 運用上の優秀性の柱の説明とグループディスカッション＆発表
14:30 ~ 15:35 セキュリティの柱の説明とグループディスカッション＆発表
15:45 ~ 16:40 信頼性の柱の説明とグループディスカッション＆発表
16:45 ~ 17:30 パフォーマンス効率の柱の説明とグループディスカッション＆発表
17:30 ~ 18:00 コスト最適化の柱の説明とグループディスカッション＆発表

内容

午前中

Well-Architected フレームワークの起こりからどのようにLens の観点が増えていったといった説明から Well-Architected の概要について学んでいきました。

以下の話が印象に残りました。

  • well-architected が開始したのは2012年
    2015年にframework を公開した。このタイミングでは4つの柱だった。 2016年に運用上の優秀性の柱が追加された
  • Well-Architected Framework(W-A)とは、
    システム設計・運用の”大局的な”考え方とベストプラクティス集
  • Well Architected Frameworkはチェックリストではない
    情報を提供しているだけで、ユーザは理解したうえで活用して行く必要があります。 ベストプラクティスを知った上で、「ビジネス的な判断をする」ための手法。リスクや改善点の”顕在化”を目的にしている
  • Well-Architected フレームワークによるレビューはAWS による監査ではない
  • レビューは一日や数時間で終わるもの（数日かかるようなものは何かがおかしい）。短時間で効率的にディスカッションを行う。
  • 一回限りではなく、定期的にチェックを行って、継続的に改善していく
    • 後で変更が困難な一方通行のドアのような変更を避けるために、初期の段階でレビューしていく
    • 新しい機能の追加や本番の運用にのったときなどのライフサイクルに変更が出たタイミングで継続的に行うのが良い
  • どの段階でどのように利用していくのがよいか
    1. 設計前の段階でホワイトペーパーを読む
      • 100ページくらいあるので大変なので、少なくとも質問は読んでおく
    2. 定期的な見直し
      • 要件検討（ホワイトペーパーを活用）
      • 設計段階
      • リリース前
      • 運用フェーズ
  • 悪い決断をしてしまった場合は？
    -> 継続的な改善プロセスの途中となり、決定とみなされない
  • クラウド向けの設計をするためには
    • AWSのベストプラクティスを学ぶ
    • オンプレだったらクラウドネイティブへの移行を検討
    • 多くのリソースがある場合は優先順位を決めて、改善点を特定する
    • 事情があって今回改善できない場合は、次のワークロードに生かす

Well-Architected Labs というページで実際にベストプラクティスをハンズオン形式で学ぶことができるとの紹介もありました。柱ごとに100・200・300といったようにレベルが設定してあるので、とっつきやすいと思いました。

www.wellarchitectedlabs.com

お昼休憩の時間では少し長めに休憩を取り、資料の読み込みも行いました。 資料は午後からディスカッションを行うための仮想顧客のアーキテクチャを説明したものです。 この資料を基に午後のディスカッションが進行していきます。

午後

午後からはグループに分かれてディスカッションを行いました。

トピック1

1つ目のトピックは運用上の優秀性の柱でした。
設計原則は次の5つです。

  • 運用をコードとして実行する
  • 小規模かつ可逆的な変更を頻繁に行う（定期的なデプロイ）
  • 運用手順を定期的に改善する
  • 障害を予想する
  • 運用上のすべての障害から学ぶ

これらの説明を10分程度で解説してもらい、各グループに分かれて20分程度ディスカッションをするという形式で行われていきました。 3,4 名で一つのグループなり、考慮事項の一つのトピックに焦点を当ててディスカッションを行っていく形です。 資料の説明では漠然としていて、（実業務で出くわすような）ざっくりとしていて情報が欠落しているため、様々な角度から議論できるようになっている題材でした。

トピック2

2つ目のトピックはセキュリティの柱でした。
設計原則は次の7つです。

  • 強力なアイデンティティの基盤を導入
    • 最小権限の原則
    • ID管理を一元化
  • トレーサビリティの実現
    • 誰がどの変更を実施したのか、個人を特定できる形で後から変更点がわかるようにしておく
    • 必要な情報を収集しておいて、自動的に分析やそれをトリガーになにかするようにする
  • 全レイヤーにセキュリティを適用する
    • 深層防御のアプローチ
  • セキュリティのベストプラクティスを自動化
  • 伝送中のデータと保管中のデータの保護
    • リスク評価を行い、必要に応じて暗号化
  • データに人を近づけない
    • 人をシステムやデータから遠ざける仕組みを構築する
  • セキュリティイベントに備える
    • 組織の要件に合わせてインシデントタイムシュミレーションを行っておく
    • Game Day を行う

セキュリティイベントを把握するのがまず大事でそのあとに分析を行っていく必要があるという話もありました。 SIEM(Security Information and Event Management) を行うAWSのソリューション（SIEM on Amazon Elasticsearch Service）は初めて知りました。

aws.amazon.com

AWSではコンピューティングリソースを保護するマネージドサービスがないので、DeepSecurity などを入れている企業も多いという話を伺いました。 GuardDuty での検知（発見的統制）はあるので、発見後に封じ込めることが必要であるという話もディスカッション中に出てきました。

GuardDuty（脅威検出） や Detective（インシデント調査）、Macie（機密情報の検出・保護）などのサービスはあるので、レビューをしていくうえで足りない部分をサードパーティ製のソリューションで補うのがよいのではと考えました。

トピック3

3つ目のトピックは信頼性の柱でした。
一言でいうと、「期待されるタイミングで、意図した機能を正確かつ一貫して実行するワークロードの能力（ライフサイクル全体を通してワークロードを運用及びテストする機能が含む）」です。
設計原則は次の5つです。

  • 障害からの復旧を自動化する
    • 閾値ベースで復旧（slack通知やトリガー）
  • 復旧手順をテストする
    • 本番相当の環境で障害を起こしてテストできる
  • システム全体の可用性を向上させるために水平方向にスケールする
  • キャパシティの判断を勘に頼らない
    • 計測する
    • 常に最適なリソースを用意する
  • オートメーションで変更を管理する
    • IaCで管理できる(CloudFormation, AWS-CDK)
    • 人の手ではなく環境を立てることができ、ヒューマンエラーを排除できる

トピック4

4つ目のトピックは信頼性の柱でした。
一言でいうのと、「システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力」のことです。
設計原則は次の5つです。

  • 最新のテクノロジーを標準化する
    • 新しいサービスが出てくるので、その時にあった選択をする
  • わずか数分でグローバル展開する
  • サーバレスアーキテクチャを使用する
  • より頻繁に実験する
    • IaC で簡単に環境を立てて実験できるようになっている
  • システムに対する精通の程度を考慮する
    • 最新のテクノロジーのメリットもあるが、リスクもあるので、無理に新しいから使うのではなく、勉強したうえで利用する

また「昔のアンチパターンが時ともに変化する。定期的なレビューにより、時代に合った選択を行いパフォーマンスを維持する」という話もあり、 Lambda + RDS のアンチパターンがそうではなくなった話を思い出しました。

トピック5

最後のトピックは信頼性の柱でした。
設計原則は次の5つです。

  • クラウド財務管理の実装
  • 消費モデルを導入する
  • 全体的な効率を測定する
  • 差別化につながらない交付かの作業に費用をかけるのを病める
  • 費用を分析し、帰属させる

感想

（意図的に）色々な突っ込みどころを持ったアーキテクチャや概要説明であったので、グループメンバとのディスカッションを広がりを持ってやることができてとても有意義でした。
3つ目のトピックくらいから疲れてきましたが、他社さんの話や自分の中になかった考え方を知れて勉強になりました。
CommentScreen に匿名でメッセージを投稿できて、SAの方にほとんど拾っていただけたので、ざっくばらんな内容のメッセージも投稿できたのがよかったです（「やりたいけど、できてないです」というのは匿名だといいやすかったです）。
また、ディスカッション中にもSAの方がファシリテートしてくれたので短い時間でしたが活発に議論できて、あっという間にワークの時間が過ぎていきました。
内容が良かったので、次回があったら同僚にようと思います。 Well-Architected tool も実業務で同僚が使っているのを見たことしかなかったので、今度自分で触る機会を作ってみようと思いました。

aws.amazon.com