JAWS DAYS 2021参加メモ

JAWS DAYS 2021メモ

AWS Control Towerを利用したマルチアカウント管理とセキュリティ統制

臼田佳祐

AWSマルチアカウント戦略とマネジメント＆ガバナンス

• セキュリティのためVPC単位ではなくアカウント単位で環境を分ける

  • どうやって管理するか？
  • AWSマルチアカウント戦略

• AWS Organizations

  • 複数のAWSを束ねる仕組み
  • Organization Unit（OU）を定義して配下にアカウントをまとめられる
  • Service Control Policyを利用して強制的なアクセス制御が可能

• AWS Config

  • 設定の検知

• AWS Systems Manager

  • EC2の管理に関する様々な機能

→どういうLanding Zoneを作っていくかが重要

• Landing Zoneとは
  • マルチアカウント管理のベストプラクティスに従った構成の考え方
  • 特定のパターンではない
  • ID管理、ガードレール、ベースラインの展開、ログ管理・監視を組み合わせる
    • AWS Landing Zoneソリューションという名前でAWSソリューションとしてCloudFormationで提供されているが延長サポート中

AWS Control Tower

• AWS Control Tower
  • Landing Zoneを展開するマネージドサービス
  • ID管理
    • AWS SSO
      • ADなどIdPと連携可能
    • Okta, OneLoginなどのIdPサービス
      • SSO可能
    • IAM管理AWSアカウント
      • AWS Organizationsがなくても実現できる
  • ガードレース
    • Service Control Policy
      • 予防的ガードレール
      • OU/アカウントに強制的に適用するポリシー
    • Config Rules
      • 発見的ガードレール
      • ポリシーに違反する設定を検知・自動修復できる
  • ベースライン
    • CloudTrail
    • Config
    • GuardDuty
    • Security Hub
    • IAM Access Analyzer
    • Detective
    • 展開はCloudFormation StackSets, Control Tower, Terraform, CodePipeline
  • ログ管理
    • 集約用S3バケット
    • SIEMなどに連携することも可能
      • SIEM: ログを一元管理し、相関分析を行うことで、インシデントになりうる脅威を検知するソリューション

Control Towerの展開と運用

• 展開する仕組み
  • マネジメント
  • Audit
  • Log Archive
  • Custom
  • Control Towerを有効にしたアカウントが親アカウントとなる
    • CoreOU配下にLog ArchiveとAuditアカウントを作成
    • 任意のOUにアカウントを新規作成
    • 配下のアカウントはSSOでログイン
• 使い方
  • セットアップ
    • 60分掛かるのと、無効化はサポートに申請しないと無効化できないので注意
  • ガードレール
    • SCPとConfig Rules
    • CoreOU特有の必須ガードレールがある
  • アカウントファクトリー
    • AWSアカウントを発行できる
      • デフォルトでNAT Gatewayが作られるので、VPC作成無効化をするのが推奨
  • SSOでアクセス
    • Config Rulesが東京リージョンで使えないので作成時のフックで対応する（？）
  • バージョンアップ
    • 手動のバージョンアップが必要

SIEM On AWS ESが便利

組織でAWSを使い始めるときに考えたいアカウントと請求の管理

Sumi Shiomi

• コスト管理
  • アカウントの整理
    • AWS Organizationsの一括請求 (Consolidated billing)
    • タグで請求を分割してもきっちり分けられない
    • 組織が成長すると無限にアカウントが増えがち
    • 利用目的毎にアカウントを作る
      • タグも活用
      • 案件 * 利用用途で分けるイメージ
    • OUわけ
      • 管理・検証・開発毎にOUを分ける
      • タグルールで命名規則 (dev, Developmentが混在など）
        • おすすめの戦略
          • サービスベースのタグ付け
          • コンプライアンス向けのタグ付け
          • Organizationのタグポリシーを使う
          • 予算設定
            • AWS Budgets
              • 予算を超えた時越えようとしたときにアラートが飛ぶ

医療データレイクで分析基盤の構築

小森谷 一生

• 大量の非構造化データ

  • フォーマットがバラバラ
  • Shift-JIS, ZIP, ヘッダーなし,ダブルクォートされてないカンマ,そもそもファイルがおかしい
  • フィールドエンジニアと医療知識者で構造化する

• 事業毎に分析環境の違い

  • 医療機関や製薬、生保など…

• オンプレ基幹システムをクラウド化したかった

• 構成

  • ETL: Athena, Lambda
    • Lambda: ファイル名からS3Location分類。解凍、文字コード変換、Catalogの作成（GlueのCrawlerは使ってない）、Pandasでデータの訂正
    • Athena: 非エンジニアのSQL資産を活かす。スモールスタートが始めやすい。学習コストが低い。Spark比
      • ADD PARTITIONのQueryが遅かったが、GlueのAPIでPartition作ったら早く行えた
  • DWH: BigQuery, Redshift (低頻度はRedshift Spectrum)
  • BI: QuickSight, タブロー, looker

AWS Lambdaのテストで役立つ各種ツール

鈴木正樹

単体テスト

• AWS-SDK-Mock
  • AWS SDK (JavaScript)の各関数をMock化するためのnpmモジュール
  • AWSリソースにアクセスする部分だけをピンポイントでMock化できる
    • await s3.getObject(param);これだけモック化できる
    • モック化もシンプル
    • エラー時のテストも行いやすくなる
  • 自動読み込みに癖がある
  • ネストされたAWSリソースの扱いが特殊
    • DynamoDB.DocumentClientなど

結合テスト

• Serverless Framework
  • サーバレスアプリオ構築・開発・運用管理をサポートするOSS
  • CloudFormationを利用したリソース管理・環境構築が可能
    • CF比で定義がシンプル
  • 多数のクラウドに対応
  • プラグインによる機能拡張が可能
    • 自作も可能
    • 以降の説明はすべてServerless Frameworkのプラグイン
  • ドキュメントが読みやすい
  • 公式ページのダッシュボードでCI/CI・モニタリングに対応
• Serverless Offline
  • ローカル環境にAPI Gateway + Lambdaの実行環境を構築
  • ローカルホストのエンドポイントURLからLambdaをローカル実行可能
  • メリット
    • 導入がかんたん (npm install, ほぼデフォルト値でいける)
    • ローカルで起動できる
    • 動作環境を判定できる
  • デメリット
    • あくまで動くだけ（AWSリソースの代わりは別途必要）
    • テスト専用ロジックをソースに含める危険性
      • Test Logic in productionアンチパターン
      • テスト専用コードを極力ソースに埋め込まないように外部から注入する
• Serverless-DynamoDB-Local
  • AWS公式のDynamoDB-Localの環境を起動時に構築する
    • serverlessコマンド経由でDynamoDB-Localをインストールする
  • テーブル定義はserverless.ymlの定義をそのまま使用可能（専用の定義は不要）
  • ローカルホストのURLからDynamoDB-Localを操作可能
  • メリット
    • ローカルでテストができる。Mock的なテスト専用コードが必要ない
    • AWS公式なので安心
    • テーブルのmigrateが簡単
      • serverless.ymlのテーブル定義から起動時にテーブル作成できる
      • seed設定をしておけば初期値も設定できる(json)
  • デメリット
    • 最新版だと起動できないケースが有る
    • DynamoDBインスタンス生成時に追加設定が必要（エンドポイントなど）
      • Test logic in productionアンチパターンに注意する
      • 設定はできる限りテストソース側から注入する
• Serverless-S3-Local
  • ローカルにS3のバケットとキーを構築できる
  • ローカルホストのURLから操作可能
  • serverless-offlineの環境上で使用可能
  • メリット
    • ローカルでS3のテストができる
    • 各種S3イベントのトリガを発火できる
      • createObjectなどS3の各種イベントでのイベント発火も可能
      • イベントでLambda起動などの確認も可能
  • デメリット
    • 自分でキーを作成するのが若干手間

テストを効率的に行えることが大切。手段が目的にならないように注意

サーバーレスとコンテナを活用したアプリケーション開発の今

濱田 孝治

• サーバレスはメリットも多いが悩みも多い
• 開発におけるデプロイ戦略
• 最近よかったサービス
  • ECR Public
    • パブリックでアクセス可能に
  • Managed Service for Grafana / Prometheus
    • マネージドサービス！
  • Lambda 1ms Billing
  • Glue
    • DynamoDBのS3エクスポート
  • AWS AppSync GraphQL Exproler対応
  • ALB HTTP2/gRPC対応
    • エンドツーエンドでHTTP2が使えるようになった。今までは上流のみ

StepFunctions Expressで作るフルマネージドなサーバーレスバッチ

遠藤大輔

• 比較的かんたんな処理のためにをサーバー・ミドルウェア・フレームワークを用意するのは面倒

  • Lambdaを使う場合、処理が複雑になると
    • スパゲッティ化
    • 責務が大きくなりすぎる
    • 並列処理が辛い
  • → AWS Step Functionsを使う！
    • サーバレスな関数オーケストレーター
    • イベント駆動型のワークフローを構築
    • 例外処理や例外分岐ができる
    • ただし…
      • 料金
      • DBコネクション問題
      • Lambdaコールドスタート問題
    • しかし！
      • Step Functions Express Workflows発表
      • RDS Proxy発表
      • Lambdaのコールドスタートが1分から1秒に改善

• 並列処理

  • Mapステートを使用
  • Step Functionsの状態の一つ
  • タスク単位で並列処理が可能
  • ただし
    • 並列数の上限は無限だが、同時実行数は約40
      • ネストさせると良い
    • Lambdaのクォータ
      • リクエスト数/秒の10倍
        • 1万ぐらいはすぐに上げてくれる。それ以上は実績やデータが必要
      • GetFunction APIのリクエスト制限
        • 100リクエスト/秒
        • コールドスタートの際に実行される
        • デプロイパッケージの取得などに利用
          • Mapの並列数を200ぐらいにする
      • Step Functionsのデータサイズ制限
        • タスク・ステート・入出力のデータサイズ制限
        • Mapステートの前後で制限オーバーする可能性が高い（Mapステート合算のため）
          • S3に一時保存する
          • S3が強い読み込み整合性をサポート
          • 不要なパラメータはMapの最後に削除
      • S3のコストを抑えるためハンドラー外で取得
        • 古いデータを参照してしまう場合がある
        • S3のオブジェクトのMetadataにバージョン情報を追加してチェックする

• データベース接続

  • RDS Proxyを使う
    • DBコネクションのプーリング＆共有が可能
    • Lambdaがコネクションを使い潰す問題を解決
    • コネクション数の節約
      • Lambdaハンドラー外でDBコネクションを生成
        • コネクションが切断した場合に、Lambda実行基盤を終了するエラーハンドリングが必要
    • 書き込み処理をまとめる
      • 1ユーザーごとに書き込み処理を行うのはNG
      • Kinesisで100人ごとバルクアップデート
      • ただしStep FunctionsやX-Rayで追跡できなくなる

• CI/CD

  • Stackを分割するメリット
    • 複数のグループごとにリソースを展開できる
      • パラメータを書き換えるだけ
    • エンタープライズコネクションなどで効果を発揮
      • 物理的・理論的にセキュア
    • ログやメトリクスの管理がしやすい
      • どのリソースで障害が発生したかがすぐわかる
  • Stackを分割するデメリット
    • リソースが大量に生成される

一年間運用して分かったCDKアンチパターン

佐藤雅樹

• AWS CDK
  • CDKデプロイでcfnテンプレートが生成され、リソースが作成される
  • 導入するモチベーション
    • CloudFormationからの脱却
      • 肥大化して可読性が低い状態
    • DevOpsの推進
      • 開発チームからインフラのPRを上げやすくする
  • プログラミング言語だから繰り返しや関数が使える
  • 自動補完が効くのでリファレンスを行ったり来たりしなくてもかける
  • ただ運用が辛くなってきた
    • CDKの使い方が悪かった
      • 可読性が低い
      • 修正が怖い
    • 1アプリケーション1ファイルで作ってしまい、ファイルあたりのコード量が増えてしまった
      • スタックの作成・削除がやりづらい（反映に時間がかかってしまう）
      • → ライフサイクル毎にスタックを分割する
        • ECS・ロググループ・ECRは別スタックで作るのがおすすめ
    • コード量を減らすこと（共通化）をがんばりすぎた
      • 変更時の影響範囲が大きい
      • 特定のスタックのリソースだけ設定を変えることができない状態に
      • →ある程度似たような記述は許容する
        • High Level Construct, Patternsを使えばそこまで記述量は増えない
      • →ライブラリ化する
        • 使っている側でバージョンを上げない限り変更されない
    • CloudFormationのベストプラクティスを意識することが大切
    • コード量を減らすことにより安心してデプロイできる

Cognito+API Gateway+Lambda+S3ではじめるサーバーレスアプリ構築 ~SIer企業がはじめて挑戦してみた話~

横山弘典

• MongoDB Atlas
  • MongoDB公式が提供するDaaS
  • AWS連携が簡単
  • VPCピアリングして使う
• ウェブサイトエンドポイントとREST APIエンドポイントの違い
  • RESTだとXML形式のエラーレスポンスを返す
• Lambdaがデプロイできない
  • SQSの可視性タイムアウト(30秒）がLambdaのタイムアウトより短かった
• SQSに対してLambdaが複数呼ばれる
  • SQSトリガーのバッチサイズが1より大きな値になっている
• Serverless-artillery
  • サーバレスで負荷試験ができる
  • AWS上に負荷を生成するLambdaが簡単に生成できる

CI/CDプロセスにCloudFormationを本気導入するために考えるべきこと

濱田孝治

• CloudFormationの実行場所
  • マネジメントコンソール
  • PC
  • EC2（SSH)
  • EC2（SSM)
  • リポジトリから自動適用

• CloudFormationにおけるCI/CDの違い

  • CI
    • 静的解析・アーティファクト格納
    • アーティファクトを作成する前に、組織ポリシーや異常テンプレートを排除し、後続処理の手間を排除する
      • CloudFormation Linter
        • DockerfileがあるのでCI/CDに組み込むのが容易
        • pipでも入る
      • AWS CloudFormation Guard
        • AWS謹製のテンプレート解析＆セキュリティポリシー評価ツール
        • デフォルト定義のルールはない
          • 自分で作るかExampleから利用
          • 「タグにPRODが含まれている場合.DeletationPolicyをRetainに強制する」など
          • Organizationsが必須なControl TowerやSCPなどとともに、CloudFormation Guardを利用したガードレール実装も検討の余地あり
        • バイナリが用意されているのですぐ使える
      • 今は微妙になったツール
        • cfn-nag
          • CloudFormation Guardが上位互換になった
          • 使いづらい
        • CFripper
          • CloudFormation Guardの方が良さそう
    • CDで利用する形態に合わせてアーティファクトを作成する
      • 通常のCloudFormationの場合
        • CloudFormationのテンプレート
        • パラメータ設定ファイル
      • SAMの場合
        • Lambdaのコードとパラメータがアーティファクト用に変換されたテンプレート
        • cloudformation packageコマンドを使うとよしなにやってくれる
  • CD
    • チェンジセット確認・環境デプロイ
    • やるべきこと
      • ChangeSetの作成
      • 承認
      • ChangeSetの実行
    • CodePipelineにCloudFormationを組み込む
      • CodePipelineのアクションプロバイダーにCloudFormationを利用
      • アクションモードでスタックに対する操作(変更セット作成だけか、実行だけなのか)を設定
      • パラメータを埋め込むためには
        • テンプレート設定ファイルを用意する
      • 公式チュートリアルおすすめ
      • クロスアカウントのデプロイはCLIじゃないとできない…
    • CodeBuildからCLIで実行
      • Terraformでは一般的な方法
      • CloduFormationは辛い
        • create, updateの使い分けが必要
        • スタック展開の進捗がわからない
        • deployコマンドが柔軟でない
      • Rainを使うとつらみを諸々解消してくれる
        • インタラクティブなデプロイ
        • CFｎテンプレートの生成
        • 既存スタックの有無によるコマンド使い分けも不要
        • 削除が簡単
        • シングルバイナリ
      • 冪等性が重要な領域に処理を組み込んでしまいがち
        • 前段の処理結果を受けてパラメータを変更するなど過度にやりだすと見通しが悪くなりCI/CDプロセス保守性が下がる

• CloudFormation Linter (VSCode Plugin)

  • CI/CDと関係ないが、リアルタイムにエラー表示
  • リソースに応じたプロパティ補完
  • リソースの関連を示すグラフ

プロダクトの成長をサポートするServerless戦略

小西 宏樹

• Serverless
  • サーバの調達モデルが所有から利用に変わり、調達のリードタイムが短くなる
  • アプリケーションロジック開発に時間を割り当てることができる
  • サービスには向き不向きがある
    • RDSの場合レコード数が少ない場合は高速だが、多くなってくると遅くなってくる。Redshiftならレコードが少ない場合は相対的に遅いが多くなっても劣化が少ない
  • 公式のサーバレスパターンおすすめ

数100台規模のnodeを使うEKSのAI推論環境

外山 寛

• Managed Nodegroupのspotインスタンス対応

  • ただしinstance typeを組み合わせたりオンデマンドの比率は引き続き手動対応が必要

• capacity rebalance

  • 従来の中断通知より前にEC2 Instance rebalance recommendationが通知される
    • 容量が一時的に不足する可能性が大幅に下る
    • EKSのManaged Nodegroupのspot機能はopt-inされている
    • SpotAllocationStrategy=capacity-optimizedにするとより効果的

• corednsの負荷増大

  • corednsなどのsystem的なpodはnodeSelectorで専用nodeに所属させ、負荷の高いnodeと共存させないようにする
  • corednsのpod数を2から5~10程度に増やした
  • kubeflowのpodの大半が通信を行うため、kubeflow上は*部分的にFQDNで通信させることによりDNSのsearchを少なくした
  • namespace=kube-systemをFargateで動かしたらDNSエラーが多発した
  • 1つのNodegroupで全podを稼働させ、spot instanceも併用させたらcorednsが死んだ

• IAM RoleのNoCredentialsErrorが多発した

  • podを1000podくらい起動するとNoCredentialsError形はつ
    • Managed NodegroupはデフォルトではnodeのIAM Roleが使われる
    • インスタンスメタデータの取得の際にスロットルが起こる
      • → IAM Roles for Service Accountsでpod毎にIAM Roleを設定して解決
        • podはk8sから払い出されるservice account tokenをAWS STSにOIDC tokenの形で渡すことでIAM認証情報を使うことができる

• 他にも…

  • podが増えすぎてIPアドレスが枯渇した
    • Secondaryのsubnetを追加
  • EKSのManaged Nodegroupのhealth checkでエラーが止まらない
    • rbacのapiGroupsでcertificates.k8s.ioを許可しないとhealth checkが失敗してしまう

• helmをterraformで扱う

  • 増えてきたhelm packageの管理が辛くなってきたのでterraform-provider-helmを使う
  • terraformでhelm packageの管理ができるので便利
    • 追加削除更新がコードで管理できる
    • インフラの管理をterraformに集約できる
    • 直接installするとどのpackageをインフラで管理しているのかがわかりにくくなっていく

• モニタリング

  • kubernetes dashboard
    • 直近15分しか見れない
    • 採用NG
  • prometheus
    • 学習コストが高すぎた
    • メモリ消費が激しい
    • 採用NG
  • cloudwatch container insights
    • deployは簡単だがhelm化はされていない
    • UIもみやすくManaged Serviceで運用コストも低い
    • 採用！

• kubeflow

  • k8s上で動作する機械学習プラットフォーム
  • kubeflow pipelines
    • k8s上で動作させる機械学習に特化したworkflow engine
    • experimentsの概念があり、実行するpipeline(workflow)にはexperimentsが必須となる
    • あとから実験結果を見る際にexperimentsから成功失敗が一覧で見れる
    • パラメータを画面から細かく設定できる
      • jenkinsっぽい
      • 可変にするパラメータもcodeで管理できる