AWS Summit MEMO

AWS Summit【初級】今から始めるサーバレスアプリケーション.md

今から始めるサーバレスアプリケーション

モジュールの流れ

モノリシック -> サービス思考アーキテクチャ（SOA）-> マイクロサービスアーキテクチャ どれがいいというわけではない、規模や組織による

サーバレスとは

• サーバの管理
• パッチ、最適化、スケーリングの運用する必要がない

つまり

• 疎結合したモジュールが必要
• どこでどのようにサーバが動いているのかは重要ではない
• 自動的にサーバ増築が行われる（イメージ）
• アプリの本質に注力できる

Lambda

• AWS Serverlessの核心
• Lambda以外にもAWSには存在
• サーバレスはマーケットにどうデリバリーするかが肝

利用ケース

• ウェブアプリ
• バックエンド
• ビックデータ
• Media Log
• チャットボット(Amazon alexa)

メリット

• 小規模アプリから大規模アプリへそのまま移行ができる
• サーバを管理する必要がない、開発に注力

考えること

• 開発ワークフローは変わらない

モノリシックからマイクロサービスへ

AWS SAM serverless application model

• Api step function , lifecycle deployment すべてのステップをコントロールできる
• AWS SAMテンプレートファイルを記述して管理（yam json xml）
• Code Commit でPush Code Pipeline -> Code Deploy -> AWS X-ray

初心者向けのサービス

• Code Star: 開発を数分で開始、デリバリーを1つの場所で管理、チーム全体で安全に作業、簡単
• 5分位でサービスが開始できる

サーバレスアプリケーションのためのセキュリティアーキテクチャ.md

サーバレスアプリケーションのためのセキュリティアーキテクチャ

SA: Serverless Application

KIRIYAMA HAYATO

本番環境で使用するにはセキュリティの課題が出てくる

メリット

• サーバレス
• スケーリング
• アイドル時リソース確保
• 高可用性

Dev and AWSの範囲

Dev

• オンプレミスの構成要素が多くある

AWS

• OS導入まで

Serverless

• アプリケーション開発だけ

SA Model

• S3 <-> Kinesis <-> Https <-> App...
• AWS: Client <-> Api gateway <-> lambda <-> dynamo

1. 構成要素

• ユーザ管理とアイデンティティ
• エッジ
• メッセージングストリーミング
• 今ビュート
• データ

2. セキュアに設計する

• Well Architect Framework
• 固有の考え方やベストプロくティスにフォーカスを当てたレンズ（Lans）

セキュリティの柱

• ID アクセス管理

  • 1. APIアクセスの認証認可をどうしているか
  • 2. LambdaファンクションがアクセスできるAWSサービスをどのように保護しているか
    • Amazon Cognito User Pools: ウェブモバイル認証認可ユーザ管理をサポート

      API Gatewayまでの認証

      • Cognito User Pools Authorizer
        • Cognito <-> User <-> API Gateway <-> DB(resource)
      • AWS IAM Authorization
        • 上の図にAWS IAMのクレデンシャルトークンを途中で挟むイメージ
      • Lambda Authorizer 　- Lambdaで認証し、IAM Userを発行し、アクセス権限を与える

• 発見適当性

• インフラ保護

  • Lambdaファンクションがアクセスできるリソースにネットワーク上でどのように保護しているか
    • API Gateway: WAFで防御されている

• データ保護

  • SAアプリの機微な情報をどう保護しているのか
    • 保護すべきデータは外部化する-> SystemManager/ Secrets Manager
    • Secrets Maneger -> AWS Cloud Extension 連携

• インシデントレスポンス

  • 侵入テストがAWSではできる

• セキュリティルールのオートメーション

  • WAFのフルログからS3に保存、保存をトリガーにLambdaでAthenaに渡し、WAFルールを自動更新

ちなみに。。。Lambdaの料金

• 100万アクセスまで無料
• 1秒あたり４００GBまで無料
• 詳細

サービスメッシュは本当に必要なのか 何を解決するのか.md

サービスメッシュは本当に必要なのか

何を解決するのか

Speaker: HARA YASUHIRO

LB ---> (App) ---> DB

Appがどんどん大きくなっていったとする

LB ---> (　　　App　　　) ---> DB

本番環境で障害や、Downtimeが発生してきた

提案: Appをサービス化しよう

Monolithという呼称に込められるニュアンス

• 関係者調整のオーバーヘッドがある
• 変更による影響範囲の広さ
• モジュール構造維持の難しさ
• 非効率スケーリング
• テストビルドに要する時間の長さ
  • 小さい変更でも時間がかかり、大変 　

マイクロサービス化に期待される効果

• 変更による影響範囲を局所化できる
• モジュール境界の維持しやすさ
• 独立したデプロイとスケーリング
• 自律的なチームによる開発運用
• polyglot(-able): 数か国語に通じている人,複数言語
• モノリシックサービスでは1つの言語に制約される

AWS x-ray

• Compornent間の全体的に見れるようなシステム
• X-rayではリクエストごとに処理時間がWebで見れる

マイクロサービスの課題

• サービスの適切な分割

  • 正解がないから難しい、DDD、TDD、、、etc

• テストが難しい

• 影響範囲を自サービスのみに収めるのが難しい

  • 他のサービス、チームを無視していいわけではない、合意なしに仕様変更するわけにはいかない、DownTimeを生み出す訳にはいかない

• サービス間通信の信頼性

  • ネットワーク、防御的実装が必要
    1. 各チームがデプロイしている中で仮想マシン上で動いているが、別の場所で動いているかもしれない
    2. 呼び出し失敗の際にリトライが必要
    3. 継続した呼び出しの失敗 -> サーキットブレイカー
    4. 呼び出し先サービスのパフォーマンス強化 -> taimuauto
    5. 呼び出し元システムの不具合 -> スロットリング(リクエスト受け入れないで即座に返す)

• サービス間通信の可観測性

  • マイクロサービス軍　１つのシステム
  • 外形的にはシステムの失敗
  • ログ, メトリクス、トレース情報を出力する
  • 各サービスの出力フォーマットが不揃だとコンテキストが見えない
  • システム全体の観測には不向き
    • つまり統合されたログ、メトリクスが必要
      • '一貫性のある実現方法が必要'

解決策1

• 共通ライブラリを入れる
  • アプリに改修が必要
  • パフォーマンスが悪化
  • ライブラリには言語対応がされていない

マイクロサービスは

• 疎結合な実装、自律的チーム関係の維持が必要

解決策2

• プロキシアプリを入れる
  • 各アプリの横にプロキシを入れることにより、すべての通信のログを統一化できる
  • それがサービスメッシュ
• envoy
  • OSS, アメリカ企業
  • Graduated プロジェクト
  • ymlで定義してEnvoyに設定ファイルを読み込ませて、envoyを実行

AWS App Mesh

• envoy をラップしたようなアプリ、envoyをコントロールしてくれる？
• メッシュ全体の定義、メッシュを構成するプロキシに対して動的配信ができる
• トラフィックコントロールが可能
• 統一されたフォーマット
• App Meshは無料。Betaプロジェクト？

システムにサービスメッシュは必要化

• 信頼性と可観測性を確保するサービス
• 共通ライブラリでも可能
• 動的なサービスメッシュが必要か
  • Envoyの動的設定が必要化