Well-Architected 勉強会にいってみた

こんにちは、ロジカル・アーツの井川です。

2/5に開催されたWell-Architected 勉強会に参加してきました。今日は、その際に学んだことや発表資料(公開されている方だけですが)をまとめてみました。

jawsugosaka.doorkeeper.jp

Well-Architectedとは？

みなさんは「AWS Well-Architected フレームワーク」略してウェルアーキをご存知ですか？ウェルアーキはAWSが公開しているクラウド設計・運用のベストプラクティス集であり、参考にすることで運用／セキュリティ／信頼性／パフォーマンス／コストを最適化することができます。これとは逆を「アンチパターン」といい、知らずにアンチパターンで設計してしまうと思った性能が出なかったり、課金がすごいことになったり、いろいろ大変な目に遭ってしまうことも。

Well-Architected概論

Speaker: AWSJ 清水崇之さん

• White paper 日本語対応済み
• Well-Architected Tools 日本語化対応済み -> ベストプラクティスに対する改善方法が分かる

AWS Well-Architected フレームワークの5つの柱

• クラウド上でシステムを設計するにあたって、指針となる設計原則がある。ウェルアーキではそれぞれを柱と称し、軸を設けている。

• 運用上の優秀性

  • ビジネス価値を提供し、サポートのプロセスと手順を継続的に向上させるためにシステムを稼働及びモニタリングする能力

• セキュリティ

  • リスク評価とリスク軽減の戦略を通してビジネスに価値をもたらす、情報、システム、アセットのセキュリティ保護機能

• 信頼性

  • インフラやサービスの中断から復旧し、需要に適したコンピューティングリソースを動的に獲得し、誤設定や一時的なネットワークの問題といった中断の影響を緩和する能力

• パフォーマンス効率

  • システム要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力

• コスト最適化

  • 最も低い価格でシステムを運用してビジネス価値を実現する能力

一般的な設計の原則

• 必要なキャパシティを勘に頼らない
• 本番規模でテストを実施する
• アーキテクチャ試行回数を増やす　等々
• こうした原則は質問及び回答形式でベストプラクティスを示している。以下は軸の1つとなるセキュリティにおける例。

SEC 1: 認証情報と認証をどのように管理していますか？

• 認証情報と認証メカニズムには、ワークロードにおいてアクセス権を直接的または間接的に付与するパスワード、トークン、キーなどが含まれる。適切なメカニズムで認証情報を保護することで、不注意または悪意による不正利用のリスクを減らすことが出来る。

SEC 2: 人為的なアクセスをどのように制御していますか？

• 定義されたビジネス要件に合致するコントロールを実装することで人為的なアクセスを制御し、リスクと不正アクセスの影響を軽減する。これは特権ユーザーとAWSアカウントの管理者に適用される。また、アプリケーションのエンドユーザーにも適用される。

Well-Architected フレームワークの使い方

• 上記のような質問からリスクや改善点を考える
• ベストプラクティスを理解した上でビジネス材料の判断として頂きたい

活用場所

• 要件検討
  • RPO(目標復旧時点)やRTO(目標復旧時間)をどう設定するのか
  • どういった対策復旧対応を行うのか
• 設計
• 構築
• 運用

活用のポイント

• 新サービスの定期的な見直しがおすすめ

  • 半年に1回など、頻度を決めて行うことで不必要なコストを下げられる可能性がある
  • 例えばEC2を使っていて、新しいインスタンスタイプに置き換えることでコスト削減等

• マネージドサービスの活用

  • インフラストラクチャを意識する必要がなく、コストが減る
  • 特にセキュリティサービスの活用
  • 近年の re:Invent ではセキュリティ向けの新しいサービスが多数ローンチされている

• ホワイトペーパー及びWell-Architected フレームワークのチェックリストをセルフレビューしたのち、AWS SAにレビューを依頼するのもオススメ

レビューの進め方

• レビューはとても重要なのでホワイトペーパーにおいても3ページにわたってレビュー方法を記載している
• 「誰も責めない」心構えが大切。責められると思うと継続が困難になる
• 適切な関係者がその対話の場に参加できるように手配することが大切
• 継続的に Well-Architected を使ってレビューする取り組みが必要
  • 状況は時と共に変わっていくため定期的なレビューがとても大切

サーバレスのウェルアーキを知ろう～サーバレスレンズ～

Speaker: AWSJ 西谷圭介さん

発表資料

speakerdeck.com

Serverless Application Lensについて

• ワークロード固有の考え方やサーバーレスのベストプラクティスにフォーカスを当てた Well-Architected フレームワークであるレンズ(Lens)
• サーバーレスワークロードを構築する際に考慮すべき領域が定義してある

詳しくは下記に記載してあります※日本語

AWS Well-Architected フレームワーク Serverless Application Lens

定義: レイヤー

• レイヤーとはサーバーレスのワークロードを構築する際に考慮すべき領域のことです。全部で7つあります。

• コンピューティングレイヤー

  • ビジネスロジックがデプロイ及び実行されるランタイム環境
  • Lambda
  • API Gateway
  • Step Functions

• データレイヤー

  • ビジネスロジックが必要とする状態を保存する為の安全なメカニズムを提供
  • DynamoDB
  • S3
  • Elasticsearch Service
  • AppSync

• メッセージングおよびストリーミングレイヤー

  • コンポーネント間及びストリーミングデータのリアルタイム分析と処理を管理
  • SNS
  • Kinesis Data Streams
  • Kinesis Data Analytics
  • Kinesis Data Firehose

• ユーザー管理とIDレイヤー

  • インターフェイスの外部顧客と内部顧客の両方に ID、認証、認可を提供
  • Cognito

• エッジレイヤー

  • プレゼンテーションレイヤー及び外部顧客への接続を管理
  • 異なる地理的場所に居住する外部顧客への効率的な配信
  • CloudFront

• システムのモニタリングとデプロイ

  • システムモニタリングレイヤー:　メトリクスを通じてシステムの可視性を管理
    • CloudWatch
    • X-Ray

• デプロイレイヤー:　リリース管理プロセスを通じてワークロードの変更を昇格させる方法を定義

  • Serverless Application Model(SAM)

定義: デプロイ

1. All at Once

   • すべてを一度に実行
   • 古いバージョンを再デプロイ
   • 適したイベントモデル: 同時実行数が少ないもの、メンテナンス時間が確保できない場合におすすめ
   • 即時対応可能

2. Blue / Green

   • 前もってあるレベルの本番環境テストですべてを一度に実行
   • 新旧環境を用意してトラフィックを切り替えるため、ダウンタイムが0に近い
   • インフラストラクチャに関する依存が少ないためサーバーレスは行いやすい
   • トラフィックを以前の環境に戻す
   • 適したイベントモデル: 中程度の同時実行ワークロードでの非同期及び同期のイベントモデル
   • 反映時間が数分～数時間の検証を行い、その後すぐにでも顧客に対応する

3. Canary / Linear

   • 1~10% の一般的な初期トラフィックシフト、その後段階的に増加、または一度にすべて増加
   • トラフィックの100％を以前のデプロイに戻す
   • 適したイベントモデル: リクエストが多くて同時実効性の高いワークロードにおすすめ
   • 反映時間がゆっくりで数分～数時間かかる

Lambda のバージョン管理

• エイリアスと特定のバージョンを紐づけられる。
• 新しいアプリケーションを使用する際などに安全なデプロイを実現できる
• 例えば API Gateway のLATESTを使用すると、自動的に変更が反映されるが、誤ったデプロイをしたときの影響を減らすため、変更不可能な特定のバージョン(エイリアス)を使用することでリスク回避が可能

設計の原則

• スピーディ、シンプル、単数 -> 関数は簡潔で短く、単一の目的のものにすると良い
• 合計リクエストではなく、同時リクエストでの使用を検討する
• 共有しない -> 関数のランタイム環境基盤となるインフラストラクチャは短命であり、ローカルリソースの保証
• ハードウェアアフィニティがないと仮定する -> ハードウェア依存をする実装は行わない
• 状態確保のために Step Functions の使用を検討する

ウェルアーキしくじりLT

アンチパターンでしくじった経験のある方々が5分間のLTをしてくださいました。

LT 1: 小西 宏樹 さん

サイバーエージェントの方で、JAWS-UG の関西メンバーだそう。サーバーレスなど様々な構成を試した上で、結局最良の選択はEC2であったというしくじりエピソードを頂きました。興味のある方は以下の発表資料をご覧ください。

発表資料

AWSしくじり先生 Jawsug kyoto 20200205 from ひろき こにし

www.slideshare.net

LT 2: すみひろし さん

京都のゲーム会社で働いているすみひろしさんのLT。 Well-Architected フレームワークを導入しようとして様々な課題に直面されたようです。

• ボリュームが多い
  • 256個の質問があり、しんどい
  • 対策-> 柱ごとに分けて段階的に導入していく
• 実施後の結果から目をそむけたくなる
  • セキュリティの柱をチェックした結果、質問項目10に対しほぼオールレッド(9)
  • 対策-> 改善すべき道筋が出来たと受け止める
• 何をすればよいのか分かりづらい
  • 対策-> わからないことはAWSのSAさんに聞いてみる

LT 3: Hidetaka Okamoto さん

岡本さんはアレクサのやらかしエピソードについてLTしてくださいました。

• ASK CLI -> アレクサのリソース管理におすすめ
  • SDK を内部で生成する
  • スキルを作るたびに Lambda が大量にできてしまう
• Code Star を使うと CI/CD を自動化出来て楽しい
• VUI界隈ではAWSがあまり有名ではないのでもっと頑張ってほしいとのこと

LT 4: そなー さん

そなーさんはAWSのあるあるしくじり集を紹介してくださいました。

• AWS リソース編
  • リージョンをオレゴンのまま構築
  • インスタンスを停止状態のままアカウントを削除(リソースが残ったまま？)
• お金編
  • 止め忘れ・消し忘れ多数　-> 定期チェックが大切
  • RDSのTypeが勝手にプロビジョンドIOPSになっていた
  • Windows OS のインスタンスでとても高いやつになっていた
• ループ編
  • よくないAMIによりAuto Scalingが無限ループ
  • Lambda でスポットインスタンスのイベントソースが無限リトライ
  • VPCエンドポイントを追加してS3に繋がらない
  • RDS消したらシステムスナップショットも消えてしまった -> 現在はコンソールに注意喚起あり
• セキュリティ編
  • t2.micro のまま本番環境を公開(トラフィック急増)
  • Git Hub にシークレットアクセスキー、アクセスキーを放置したままPush

LT 5: 野崎敏彦 さん

星野リゾートさんなどでお仕事されている野崎さんのLT。振り返りの大切さについてLTくださいました。詳細は下記の発表資料をご覧ください。

発表資料

speakerdeck.com

突然のじゃんけん大会

LTが終わった後、突然じゃんけん大会が始まりました。

写真は主催者である株式会社KYOSOの辻さん

少し遅れて参加した私は、何のことやら？と思って見ていたのですが、どうやらAWSよりカレンダーがもらえるとのこと。

その結果。。。。

私も何とか頂くことができました。嬉しいです。

最後に

コロナウィルスの影響で、皆マスクをしてでの参加であったり、懇親会が中止になったりと、ハプニングが多い勉強会でしたが、AWSの清水さんや西谷さんが参加されるセミナーは関西では貴重でしたので、参加出来てよかったです。参加したことによって、設計を行う際の指針となる Well-Architected をさらに意識することが出来ました。

参考サイト

AWS Well-Architected – 安全で効率的なクラウド対応アプリケーション

Introduction to Serverless Application Lens - Speaker Deck

JAWS-UG 京都 ウェルアーキ勉強会 LT / ワークロードの陳腐化と戦えなかった - Speaker Deck

いまさら聞けないRPO（目標復旧時点）とRTO（目標復旧時間）の違い (1/2)：「RPO6時間前、RTO15分」が両立する理由 - TechTargetジャパン システム運用管理