AWS Summit Tokyo 2019 に参加しました。

---

AWS で実現する攻めのシステムモニタリング #

6 月 13 日 10:00-10:40  会場：A

"攻め"の監視設計のポイント ~AWSクラウド上のシステム監視を始めるには~ #

"攻め"の監視 ... 本来の要求を高水準で満たし、新たな価値を生み出す監視

なんのために監視するのか

• アプリケーションの清浄性をチェックする。
  • 個別リソースではなく、応答時間や処理時間といったアプリケーションレベルの状態を収集する必要がある。
• アプリケーションを元の状態に回復する
  • 正常/異常状態を定義する
  • 異常状態への状態変化を検知する
  • 異常状態から正常状態に復旧する方法を用意する
  • 自動復旧 or 手動復旧
• トラブルの原因を調査する
  • アプリ/リソースの動作状況を記録する
    • 動作状況を示すログやメトリクスの記録
    • 高い粒度のログとメトリクス
  • トラブルに関係する記録を保全する
• ユーザー行動を分析する
  • ユーザー行動を記録する
  • 記録したユーザー行動を分析する
• キャパシティを分析する
  • リソースに関する状況を記録する
  • 記録したリソース状況から将来のキャパシティを分析する

目的と監視方法がマッチしないアンチパターン

• 不適合な監視
  • ex. web アプリの清浄性チェックのために、Apache プロセス監視
• 情報不足
  • ex. オートスケールの結果、インスタンスが消失してログも消失
  • ex. リアルタイムの調査用に 5 分間隔のメトリクス収集
• 通知過多
  • ex. "ERROR" を含むログが出力されたら全部メール通知
    • アプリケーションにて検知したい状態と実行したいアクションは常に対応するように通知を厳選すべき

クラウドはオンプレミスとどう違うか？

• リソースをオンデマンドに追加/削除できる
• リソースが一時的にしか存在しない
• マネージドサービスが提供されている
• クラウド特有の監視が必要になる

クラウドの特性をふまえた監視設計が必要

適応型モニタリングのコンセプト #

"適応型"モニタリング 収集、監視、行動、分析のサイクルを繰り返し

Collect 監視

• システム監視には、まず現状の把握が必要
  • 監視目的から収集対象/粒度/保存期間を決める
  • 収集/粒度/保存期間は、コストとのトレードオフ
    • 優先度の高いものから収集。できるだけ詳細かつ多量を収集する
• CloudWatch Metrics
• ログ収集
  • CloudWatch Logs
  • Kinesis Data FIrehose
  • CloudTail
  • etc

Monitor 監視

• 収集した状態を適切な方法で把握、確認する
• 目的に応じた監視
• 通知頻度は、運用不可とのトレードオフ
• 通知方法と宛先の検討
• ダッシュボード
  • CloudWatch コンソール
  • CloudWatchDashboard
  • Elastic Servuce Kibana
  • Trusted Advisor
• 通知
  • CloudWatch Alarms

Act 行動

• 収集/監視した状態を元に適切なアクションをとる
• 目的に応じたアクション
• 状態とアクションの対応づけ
• リソースの調整
  • AWS Auto Scaling
• システムの回復：リソース
  • 高可用性サービス、高可用性オプションを持つサービス
  • Amazon Auto Scaling
• システムの回復
  • Design for Failure の原則
    • リトライと冪等性 ... 何度同じ動作を繰り返しても同じ状態になる
    • ステートフルよりステートレス
• オートメーション
  • CLoudWatch Events
  • Lambda
  • Systems Manager

Analyze 分析

• 収集した状態を中長期的に分析する
• 目的に応じた分析
• 分析のための前準備
• 検索
  • CloudWatch Logs Insights
  • Esasticsearch Service
  • Athena
  • Elastic Servuce Kibana
• ビジネスインテリジェンス
  • QuickSight
• 予測
  • Amazon Forecast

継続的な振り返りと監視設計の見直し

モニタリングデザインパターン #

• アプリ監視
• インテグレーション
• ログ収集分析

---

【初級】AWS におけるデータベースの選択指針 #

6 月 13 日 12:00-12:40  会場：C

データベースの歴史 #

• 1980 頃 ... RDB
• 2000 頃 ... NoSQL
• 現在 ... インターネットを介して大量のデータを扱う

データベースの選択

• 多様な洗濯し
• 適材適所の洗濯

データベース管理のフルマネージド化

• 自動化された管理タスク
• DBA が必要なタスクにフォーカスできる
  • スキーマデザイン
  • クエリの作成
  • クエリの静的か

AWS のデータベースサービス

• RDB
  • Amazon RDS
    • 6 つのエンジンから洗濯できる
    • Amazon Aurora ... MySQL、PostgreSQL 互換
  • 選択指針として、ます候補とする
• NoSQL
  • インターネットスケールのシステムは、スケール規模を事前に予測するのが難しい
  • Amazon DynamoDB
    • どんな規模にも対応する高速で柔軟な key-value store
    • Amazon.com
• DocumentDB
  • 頻繁に変更される属性情報
    • スキーマを事前に決められない
    • ニュース、ブログ記事
  • Amazon DocumentDB
    • MongoDB 互換
• In-Memory
  • 最大限メモリで処理する KVS
  • リアルタイム性の高い、ミリ秒未満のレイテンシーが求められる
  • Amazon ElasticCache
    • Redis、Memcached 互換
• Graph
  • データ間を相互に結びつけて、データ同士の関係をグラフで表す
    • グラフ構造を扱うアプリケーション
    • SNS フィード、リコメンデーション
  • 多対多の関連を表す要件がある
  • 短いクエリの頻発する要件がある
  • Amazon Nepture
• Time-Series
  • 時系列データサービス
    • 時間が唯一の主軸
    • 特定の間隔で記録され続ける
    • IoT デバイスデータ、アプリケーションイベント、DevOps データ
  • 大量ログの絶え間ない格納
  • RDB では格納と分析の両立が難しい
  • Amazon Timestream
    • 現在は Public Preview
    • 挿入と分析のレイヤーが分かれている
• 台帳データベース
  • データの変更履歴はイミュータブルであることを保証する
  • 意図しない変更が発生していないことを暗号技術で検証
  • 医療カルテ、登記、会計履歴
  • 台帳を管理しなければならないか
    • RDB では管理者が存在する
  • Amazon Quantum Ledger Database
    • 現在は Public Preview
    • 変更の履歴の追跡

---

モダンなモニタリングへの変革！Datadog徹底解説 #

6 月 13 日 13:00-13:40  会場：J

オブザーバビリティのための三本柱 #

• Traces

• Metrics

• Logs

  • ビジネス分析

• 分散したマイクロサービスの関係性をすべて可視化

• どこがボトルネックになっているか

• 250 を超える豊富なインテグレーション

AWS x Datadog #

• Amazon CloudWatch or Datadog
• Datadog
  • 根本原因分析
  • 顧客体験の可視化するための堅牢なツール
  • 導入おしやすさと Fast time-to-value
  • AWS Integration
    • AWS 各種サービスのメトリクス・イベントを簡単に可視化
    • 複数の AWS アカウントを同時にモニタリング
    • インスタンスタイプ、AZ、リージョンを自動でタグ付け
    • 各種サービスのダッシュボードテンプレート

モダンなモニタリングのポイント #

• Cattle、not pets
  • ペットではなく家畜として捉える
  • 個ではなく、群として捉える
• Tag ごとのモニタリング・分析
  • メトリクスに付帯
  • フィルタリング/グルーピング
  • カスタマイズ可能

モニタリングする要素

• ワークメトリクス
• リソースメトリクス
• イベント
• APM
• ログ
• 外形監視

モニタリングの目的

• 健全なサービスを継続させるためビジネス的観点

Datadog でモニタリングと可視化

• ダッシュボード
  • ScreenBoard
    • "今何がおこっているか" "どこで問題が起きているか"
    • チーム間で共通の可視性を保つこと
    • 問題が発生している箇所を特定できること
    • インフラ、APM、ログにまたがるタグ付け
  • TimeBoard
    • "なにが問題なのか" "どこが原因だったのか"
    • サービスをドリルダウンしてリソースまで確認
• モニター & アラート
  • アラート設定のポイント
    • 緊急性に応じて 3 段階のレベルでアラートを使い分ける
      • 記録する(Record)
      • 通知する(Notification)
      • 呼び出す(Page)
  • アラートワークフローに役立つインテグレーション
    • Slack、PagerDuty、Webhook .etc

Datadog でトラブルシューティング

• ログ管理
  • Datadog エージェントからログ収集して一箇所に集約管理
  • CloudWatch Logs や S3 のログは Lambda 関数経由でログをインデックス
  • ログパターンを自動でクラスタリング
• APM
  • 7 言語にサポート
  • マイクロサービスのトレース
  • Trace Search
    • 各トレースをログ同様に収集
    • グラフ化
    • トレース詳細の確認
    • Watchdog ... 気概各州による異常検知の自動化
• 外形監視
  • API
  • Browser Tests
    • E2E テスト

"良くわからんが動いているからヨシ！" ではなく、"Datadog で可視化しみんなハッピー" に。

---

【初級】AWSでのデータ収集、分析、そして機械学習 #

6 月 13 日 14:00-14:40  会場：C

必要となる技術要素

• データソース
• BI ツール
• データ分析
• 機械学習 (学習/推論)

データに基づいた意思決定で必要なこと

• 十分な質と量のデータ
• データ分析や機械学習の仕組み
• 評価指標とそれを計測する仕組み
• seeds からではなく、ビジネス課題からスタートする
• ループを回して評価をし、データ活用が役立つことを確かめる

やりたいことは後から必ず変わる、増える データレイクをデータ活用の基盤とする

• データレイクに最適な S3
  • データを任意のファイル形式で保存
  • 容量の上限なし
  • 高い耐久性
  • 低コスト
  • 多様な権限管理や暗号化によるセキュリティ
  • API により様々なプログラム言語やサービスと連携

最初のデータ活用フローの構築

• データ活用フロー設計のポイント
  • 万能なツールは存在しない
    • 適材適所のサービスを選定する
  • やりたいことは変わる
    • やりたいことに集中して素早く試行錯誤ができるようにマネージドサービスを活用する
  • 扱いたいデータ量も変わる
• データ活用フローの設計の順序
  • 誰がどのようにデータを利用するのか？
    • SQL で分析 ... Amazon Athena
    • (高度な)SQL で分析 ... Amazon Redshift
    • Hadoop/Spark で分析 ... Amazon EMR
    • BI 画面で分析 ... Amazon QuickSight
    • データアナリスト ... Amazon Elastic Service
    • Jupyter ... Amazon SageMaker
• 目指すデータ活用から必要なデータ収集を考える
  • 可能な限り細かくデータをとる
  • ログデータ、IoT データ -> Amazon Kinesis Data Firehose -> S3
  • データベース dmp -> S3
• 必要であればデータ変換 (ETL) する
  • Amazon Lambda ... 小規模、　逐次処理
  • AWS Grue(Python Shell) ... 中規模、データをまとめて処理
  • AWS Grue(Spark Job) ... 大規模、データをまとめて処理

機械学習を活用する意味を考える

• ビジネス課題からスタート
• 注力する領域を決める
  • 気概学習すべてを自社で行う必要があるとは限らない
  • QuickSight ML Insights
    • 専門家不要で使えるインサイト機能を提供
    • 機械学習ベースの異常検知
    • 機械学習ベースの予測
    • 自動ナラティブ

AWS が提供する機械学習サービスのスタック

• AI サービス
  • 学習されたモデルを利用
  • Amazon Rekognition ... 画像認識
• ML サービス
  • Amazon Personalize ... レコメンデーション
• ML フレームワーク & インフラストラクチャ
  • Amazon SageMaker ... アルゴリズムを実装/利用して、自分でモデルを学習

---

AWSを活用したユーザー認証実装パターン解説 #

6 月 13 日 15:00-15:40  会場：B

ユーザー認証の概要 #

• ログイン等は"認証"
• 実行権限等は"認可"
• 本セッションはエンドユーザにまつわる認証
  • 消費者、従業員、パートナー

Web アプリケーションの実装例

• 従来型(HTML ベース)の Web アプリ
• モダンな API ベースの Web アプリ
  • 最初に HTML、Javascript を取得
  • API にアクセス
  • 場面は部分更新
• クラウドベンダー提供のアプリ
  • 実装はベンダー依存

ユーザー認証に関連する関心事

• 強固な認証、ユーザビリティ i、ガバナンス/コンプライアンス、構築/運用性

AWSの認証関連のマネージドサービスの紹介 #

AWS SSO

• 多要素認証
• パスワードポリシー
• シングルサインオン
• ActiveDirectory 対応
• CLoudTrail 対応(監査)
• プログラミング不要
• マネージドで負荷軽減

Amazon Cognito

• 多要素認証
• パスワードポリシー
• AWS Credentials
• ソーシャル連携
• 外部 ID プロバイダ連携
• CLoudTrail 対応(監査)
• プログラミング不要
• マネージドで負荷軽減

ユーザープールと ID プール

• ユーザープール
  • ユーザー認証
• ID プール
  • AWS Credentials 発行

ユーザー認証の実装パターン解説 #

• 従来型(HTML ベース)の Web アプリ
  • ALB + ユーザープール
  • ALB + OICD 準拠 ID プロバイダ
  • NLB + EC2 + RDS
• モダンな API ベースの Web アプリ
  • Amazon API Gateway で提供している場合
    • Amazon Cognito
  • ユーザープール + ID プール
• クラウドベンダー提供のアプリ
  • AWS SSO

---

ML Security on AWS #

6 月 13 日 16:00-16:40  会場：A

機械学習プロセスの全体像 #

ビジネス課題 -> データ収集 -> データの加工整形 -> データの分析可視化 -> 機械学習

• 開発 -> 学習 -> 推論 (-> 開発 ...) -> 多システム

データをどう扱うか

考慮するべき 5 個のセキュリティ項目

1. 保存のデータ暗号化

• 基本的には、SSE-KMS がおすすめ

2. 通信のデータ暗号化

3. 権限管理

• データに関する最小権限の原則
• クロスアカウントでの環境分離
  • データ加工・管理、開発、本番でアカウントを分離し、必要なデータはコピーする
  • 用途や組織に応じてアカウントごと/バケットごと分離
• データの分離と前処理
  • 分析に影響ない範囲で加工して、リスク提言
  • 必要なければ、そもそも扱わない
  • ex. 住所は文字列ではなく、hash 化すればリスクを下げながらグルーピングできる

4. 閉域に閉じた環境

• VPC エンドポイント
  • ex. S3 のバケット、オブジェクトに対して、簡潔で制御されたアクセスを実現
• データの保護
  • あらゆるものを閉域網の中に閉じると、それだけシステム構成に制約がつきやすく、運用コストも上がる
  • リスクによるデータ分類に応じて、保護のレベルを帰る

5. ガバナンス

• CLoudWatch Logs によるログの出力、集約
• CloudTrail による API 実行履歴の蓄積

Amazon SageMakerで実現するセキュアな機械学習基盤 #

Amazon SageMaker

• 機械学習システムでよくある問題を解消し、データサイエンティストやエンジニアが素早くプロセスを回せるようにするためのサービス
• 数クリックで、機械学習の定番ライブラリ群が含まれたインスタンスを起動
• ブラウザ経由の Jupyter Notebook で作業する

---

アカツキ、スマートニュースがご紹介！AWS運用を支えるエンタープライズサポート活用事例 #

6 月 13 日 17:00-17:40  会場：J

AWS Enterprise Supportとは #

AWS 技術サポートサービス構成

• TAM
  • お客様にアサインされるエンジニア
  • 各種相談窓口
• Concierge
  • 料金、契約関連の問い合わせに対応するシニアエージェント
• 優先対応
  • 技術サポートケースを優先的にハンドリング

SmartNews #

• "より深い" 情報の提供
• 無限サポートケース
• プレビュー版サービスの試供
• (実は AWS 使用量が減る可能性も)

Akatsuki #

• Consolidated Billing 親アカウントに対して Enterprise Support 締結
• Chat でリアルタイムに直接相談
• Reserved Instance の利用状況確認、最適化

---

【初級】AWS コンテナサービス入門 #

6 月 14 日 12:00-12:40  会場：C

コンテナとは #

アプリケーションを構成するコンポーネント

• ランタイム/エンジン
• アプリケーションコード
• 依存ライブラリ/パッケージ
• 設定

"コンテナ"という解決策

• ランタイム/エンジン、依存ライブラリ/パッケージ、アプリケーションコードをコンテナにまとめる
• 設定は、環境に依存するもには後からコンテナに渡す
• 全ての環境で同じコンテナを動かす
• Docker がデファクトスタンダード

"仮想マシン"と"コンテナ"

• コンテナは立ち上がりが早い
• 仮想マシン ... "マシン" 、コンテナ ... "プロセス"
• コンテナは実行環境を隔離しているだけなので早い(isolation)
• コンテナは、"1 コンテナ 1 プロセス"の原則がある

Docker を利用した基本的ワークフロー

• コンテナイメージ作成
  • Dockerfile or docker run したコンテナ内で作業して、docker commit
  • イメージレジストリに push
• コンテナ実行
  • Docker pull
  • Docker run

Docker の責務は同一サーバー上のコンテナライフサイクル管理
複数サーバーでの管理は責務外

コンテナオーケストレーション #

Amazon ECS

• クラウドをコンテナを本番環境利用するためのオーケストレーター
• 各種 AWS サービスとの高度な連携
• 数億コンテナ/週、
• 多様なワークロードをサポートする"タスク""サービス"というシンプルなリソース表現
• Linux、Windows サポート

Amazon EKS

• 運用難易度の高い Kubenetes マスターをマネージドで提供
• コントロールプレーンをフルマネージドで提供する
• エコシステムの OSS やツールを利用できる、CNCF certified
• 各種 AWS サービスとの連携
• EKS サービスチーム、OSS チームによる Kubernetes コミュニティへの貢献
• オープンソース
• "Pod"、"Deployment"、"Service"、"Job"などのリソースに代表される高い表現力

イメージレジストリ、コンテナ実行環境 #

Amazon ECR

• フルマネージドなプライベートコンテナイメージレジストリ
• セキュア
  • 保管イメージの自動的な暗号化、IAM 連携
• スケーラブルかつ高い可用性
• Docker CLI からの利用
• ECS/EKS/Kubernetes だけでなく、その他のコンテナオーケストレーションから利用可能

コンテナ実行環境

• 実行環境 EC2 インスタンスの運用秒無
  • OS やエージェント類へのパッチ当て、更新
  • 実行中のコンテナ数に基づく、リソース最適化
• AWS Fargate
  • AWS マネージド
  • コンテナネイティブ
  • 各種 AWS サービス連携

その他のコンテナ関連サービス #

AWS Cloud Map

• クラウドリソースのためのサービスディスカバリ
• 開発生産性の工場
• AWS コンテナサービスとの連携

AWS App Mesh

• アプリケーションレベルのネットワーク
• 単一のクラスタ

Amazon CloudWatch Container Insights

• コンテナワークロードのためのモニタリングサービス

現実世界のコンテナワークロード #

コンテナだけでサービスは作れない

コンピューティングの多様な選択肢

• Function
• Container
• Virtual Machines

まとめ #

AWS のコンテナ関連サービス

• オーケストレーション
  • Amazon ECS
  • Amazon EKS
• イメージレジストリ
• ホスティング
• アプリケーションレベル

---

Kubernetes on AWS (Amazon EKS実践入門) #

6 月 14 日 13:00-13:40  会場：A

コンテナrecap #

• ソフトウェアを OS 内の独立した環境で実行する技術
• Docker
  • Build、Share、Run の 3 つのフェーズ
  • Build ... コンテナイメージ作成
  • Share ... イメージレジストリに push
  • Run ... ホスト上で実行
• コンテナのユースケース例
  • マイクロサービスのアプリケーション
  • ジョブ実行
  • CI/CD の実行
  • 機械学習

コンテナ実行(Run)時の課題

• 耐障害性
  • コンテナのホストが停止したらコンテナ全滅、機能停止
• 運用性
  • コンテナをどのホストで動かすか
• スケール

Kubernetes #

• オープンソースのコンテナオーケストレーションツール
• Cloud Native Computing Foundation が開発プロジェクトをホスト
• 通称 k8s
• コントロールプレーン ... マスターサーバー群
• データプレーン ... ノード群

Kubernetes オブジェクト

• Pod
  • デプロイの最小単位
  • "1 つ以上のコンテナ"から構成
• Service
  • Pod を名前解決により発見
  • ロードバランス(L3/L4)
• Deployment
  • Pod を維持、コントロールする Replicaset の管理

Kubernetes マニフェストと宣言的設定

• マニフェスト
  • あるべき状態を宣言
• 照合ループ
  • それぞれが個別に動いた結果の"状態"と"結果"

Kubernetes 運用の悩み

• Kubernetes コントロールプレーンの運用は"重労働"
  • コントロールプレーンの冗長は必須
• もっとアプリケーションを実行する部分に集中したい！

Amazon AKS #

• Kubernetes コントロールプレーンをマネージドで提供
• Kubernetes リリースを改変なく利用
• AWS サービスとのスムーズな連携

Amazon AKS を使う理由

• 堅牢なコントロールプレーンをマネージドで提供
• Kubernetes の運用を支援する機能
• AWS マネージドサービスとスムーズな連携が可能
• 選択可能なデータプレーン(ノード)

"Undifferentiated Heaby Lifting"

Amazon EKS をデプロイする方法

• AWS マネジメントコンソール
• AWS CLI
• eksctl
• teraform eksctl の場合

1. EKS に必要な権限を割り当て(IAM)
2. 必要なコマンドをインストール
3. elsctl コマンで作成実行

ユースケースとAWS連携 #

HTTPS/HTTP 対応のロードバランサを使いたい

• SSL オフロード、パスルーティング、複数ドメイン対応したい
  • Ingress オブジェクトによるロードバランサ機能
• ALB Ingress Controller

Kubernetes マニフェストを書いて、AWS メンージドサービスをデプロイ/コントロール可能

ログを集約したい

• Fluentd の Depployment を利用して、ログを集約
• CloudWatch Container Insights(preview)
  • コンテナログと、メトリクスを CloudWatch に集約
  • 数個のマニフェストを適用するだけの、簡単なセットアップ

オートスケースしたい

• 2 種類の水平オートスケール
  • Pod レベル : 水平オートスケール
  • ノードレベル : クラスタオートスケーリング

デプロイを効率化したい

• Code シリーズを利用して、パイプラインを構築

堅牢なデータストアを使いたい

• Amaozon RDS、DynamoDB、ElasticCash など

ラーニングパス #

Amazon EKS Workshop AWS Black Belt Github にてコンテナ関連ワークロードのロードマップ

---

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

6 月 14 日 14:00-14:40  会場：A

"Monolith" という故障に込められるニュアンス #

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

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

• 変更による影響範囲の局所化
• モジュールッキョ鵜飼の維持しやすさ
• 独立したデプロイとスケーリング
• 自律的なチームによる開発、運用
• Polyglot(-able)

モノリスの考察 #

AWS X-Ray

• 分散アプリケーションの分析と調査のための分散トレーシング
• SDK が提供されている

マイクロサービス #

マイクロサービスの課題

• サービスの適切な役割

• テストの難しさ

• 影響範囲を自サービス内に収める難しさ

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

  • マイクロサービスは一種の分散システム
  • ネットワーク経由通信 = 失敗が前程
  • 一時的なネットワーク状況による失敗
  • 防御的実装
    • 呼び出し先サービスの位置は一定ではない
      • サービスディスカバリ
    • 一時的な呼び出しの失敗
      • リトライ
    • 継続した呼び出しの失敗
      • サーキットプレーカー
    • 呼び出し先サービスのパフォーマンス悪化
      • タイムアウト
    • 呼び出し<元>システムの不具合
      • スロットリング

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

  • マイクロサービス群 = 1 つのシステム
  • ログ/メトリクス/トレース情報出力
  • 各サービスの既存実装の出力フォーマットが不揃いだとコンテキストが見えない
  • "システム"全体の観測には不向き

• 各サービスへの個別実装

• 複数の言語やフレームワーク

• 実装担当者と品質担保方法

• 統一フォーマットの変更

• 一貫性ある実現方法が必要

一貫性あるサービス間通信の信頼性/可観測性実装

• "共通ライブラリ"という解決策？
  • アプリケーション改修
  • パフォーマンス悪化
  • 各言語、ライブラリバージョンへの対応
• マイクロサービスは ... 疎結合な実装、自律的チーム関係の維持が成功の秘訣
  • ”共通ライブラリ”は密結合を生んでしまう
• プロキシへのオフロードというアイディア
  • Envoy
    • OSS
    • 多くの本番環境利用実績
    • CNCF"Graduated"プロジェクト

AWS App Mesh

• サービスメッシュのコントロールプレーン
  • メッシュ全体構造の定義
• アプリケーションレベルのネットワーク
• クラスタやサービスにまたがるメッシュの構築
• マネージドコントロールプレーン
• トラフィック管理
• 料金は発生しない

Github パブリックロードマップ

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

• "あなたのサービスにとって"必要か
  • 課題に対する必要性を検討する
  • そもそもサービスメッシュは必要か
    • X-Ray での分散トレーシング、ALB でのトラフィックコントロール
    • OSS ライブラリの利用で十分低コストなケース
  • 動的なサービスメッシュは必要か

---

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

6 月 14 日 15:00-15:40  会場：A

サーバレスアプリケーションの構成要素を知る #

特長

• サーバー管理が不要
• 柔軟なスケーリング
• アイドル時リソース確保不要
• 高可用性

サーバレスなアプリケーションモデル

• イベントソース
  • S3 にオブジェクトが作られる
  • Kinesis にストリームデータが保存される
  • Https によるリクエスト
• ファンクション
  • Lambda
• サービス呼び出し
  • データベース読み書き
  • ファイル操作
  • 通知

もっとも基本的な AWS サーバレスアーキテクチャ

• Client
• Amazon API Gateway
  • どんな規模であっても、簡単に API の作成、配布、保守、監視、保護
  1. API の定義とホスティング
  2. ネットワークトラフィック管理
  3. AWS の認証の仕組みを活用
• AWS Lambda
  • サーバーを気にすることのないアプリケーション開発/実行
  1. インフラ管理不要
  2. 高いコスト効率
  3. 自分のコードを実行
• Amazon DynamoDB

DataProcessing IoT 機器 -> Amazon Kinesis -> Lambda -> DynamoDB

システム監視とデプロイ

• CloudWatch
• X-Ray エッジ
• CloudFront メッセージング、ストリーミング
• SNS
• Kinesis コンピュート
• Gateway
• Lambda
• Step Functions データ
• DynamoDB
• Elasticchash
• S3 ユーザ管理とアイデンティティ
• Cognito

サーバレスアプリケーションをセキュアに設計する #

Well-Architected Framework

• クラウドにおけるシステム設計、　運用のベストプラクティス集
• ワークロード固有の考え方やベストプラクティスにフォーカスを当てた Lens

セキュリティの柱

• ID とアクセス管理
  • API アクセスの認証認可をどのようにしていますか？
  • lambda ファンクションがアクセスできる AWS サービスをどのように保護していますか？
  • Amazon Cognito User Pools
    • Web/モバイルアプリケーションの認証、認可、ユーザー管理をサポート
    1. ユーザー管理を簡単に
    2. マネージド型ユーザーディレクトリ
    3. 拡張されたセキュリティ機能
• 発見的統制
  • API Gateway アクセスログの設定
  • AWS X-Ray を使ったとらぶるしゅーてぃんぐ
    • サービス間イベント背にを可視化
• インフラストラクチャー保護
  • Firewall によるネットワーク境界保護
  • AWS WAF ルールに基づいた保護
  • Security Groups に基づいた保護
• データ保護
  • サーバレスアプリケーション内の機微な情報をどのように保護していますか？
  • どのように入力値チェックしますか？
  • AWS Systems Manager Prameter Store
  • AWS Secret Maneter
• インシデントレスポンス
  • 侵入テスト
  • AWS WAF セキュリティオートメーション

AWS API Gateway の認証方式

1. Cognito User Pools Authorizer
2. AWS IAM Authorization
3. Lambda Authorizer

---

めざせ! サーバレスプロフェッショナル #

6 月 14 日 16:00-16:40  会場：A

サーバーレスとは #

• サーバー管理が不要
• 柔軟なスケーリング
• アイドル時リソース確保不要
• 高可用性バレスとは

開発テスト/フレームワーク #

AWS SAM(Serverless Application Model)

• AWS でサーバーレスアプリケーションを表現するスタンダードモデル
• 関数、API、イベントリソース、データ
• Package & Deploy
• 面倒であれば awslabs
• AWS SAM CLI
  • サーバレスアプリのためのローカルテストツール
  • ローカルマシンでレスポンスやログの確認ができる
  • Lambda の実行環境をシミュレートした Docker 環境の実行
• 開発、テスト、実行には複数環境が必要
  • アカウント戦略
    • 同じアカウントでスタックを分ける
      • 小規模チームや個人に向いている
    • アカウントを分ける
      • 大規模チームや企業に向いている
  • 環境変数
    • オプションで KMS 経由して利用できる
    • ステージごとに環境を作成するために利用すると便利
  • SAM
  • Ci/CD Lambda ; バージョニング・エイリアス API Gatewai : ステージ
• 環境変数のように利用できる

Codeサービスと組み合わせてCI/CD #

段階的なデプロイメント #

Amazon API Gateway : Canary リリース

• 新しいステージのデプロイに進むトラフィックの割合を設定し、ステージの設定や変数をテストできる

再利用 #

• SAM、CLoudFormation として再利用する
• Serverless Application Repository 経由で利用する
  • AWS CodePipeline SAR Auto-Publish で自動化

監視/モニタリング #

メトリクスとログ

• CLoudWatch メトリクス
• CLoudWatch ログ
• AWS X-Ray
  • リクエスト実行状況の確認
  • 問題の検出
  • パフォーマンスの改善
  • さまざまなアプリに最適
  • サービスマップ
    • 各ノードの呼び出しの結果を色で分類し、割合を円グラフに

---

クラウドネイティブなモダンアプリケーション開発始めよう! クラウドネイティブ設計とデプロイメントパターン #

6 月 14 日 17:00-17:40  会場：A

モダンアプリケーション開発とは #

• Re-host(lift-and-shift)
  • data center -> EC2
• Re-platform(lift-tinker0shift)
  • VMs -> container
• Re-architecture
  • monolith -> microsercice
• Re-Invent

モダンアプリケーション開発のベストプラクティス #

アプリケーションのライフサイクル全体にわたってコンプライアンスとセキュリティを構築する #

イノベーションの速度を落とすことなく脅威に対応

• Authenticate
• Authorize
• Audit & Govern
• Validate

自動化された、継続的な対応

• AWS セキュリティオートメーションツールボックス

アプリケーションの構造をマイクロサービスの集まりにする #

• 変更の影響は小さくなると、リリースの速度が向上可能に
• API と疎結合なコミュニケーションが自動化を可能にして信頼性を向上
• ワークフローで複数のサービスを連携することで、俊敏性、生産性、および柔軟性が向上

可能な限りサーバーレスで構築する #

• 自動化と抽象化によって課題から解放
• サーバーレスアーキテクチャは最小の努力で最大の成果
• コンピュートの選択はトランスフォーメーションの確信

アプリケーションのモデリングとインフラにコードを利用する #

• すべてをソフトウェアとして扱うことでインフラのデプロイのスピードとアジリティを向上
• AWS Cloud Development Kit (CDK)

CI/CDを利用して高品質な機能を迅速にリリースする #

AWS Developer Tools for CI/CD

モニタリングによってアプリケーションの振る舞いの洞察を得る #

より早く問題を分析できると、より早く問題を解決できる

• AWS CloudWatch
• AWS X-ray

モダンアプリケーションのデザインパターン #

APIゲートウェイパターン #

• Amazon API Gateway
  • バックエンドサービスと簡単に連携できる
  • スロットリング
  • キャッシング
  • プロキシ
  • 認証/認可

サービスディスカバリ/サービスレジストリパターン #

• 連携するサービスがどこにいるか知っている必要がある
• AWS Cloud Map
  • 名前解決

サーキットブレーカーパターン #

• 呼び出し先サービスの障害の影響を軽減する
• Amazon Elastic Container Service

コマンドクエリ責務分離(CQRS)パターン #

イベントソーシングパターン #

• データソースを直接変更するのではなく、イベントリストからプロセスを実行していく
• Amazon Kinesis & Amazon Lambda

コレオグラフィパターン #

• 特定の処理を、特定のコンテナだけ実行したい

集約ログパターン #

Polyglotパーシステンスパターン #

• 異なるデータ処理のニーズに対しては異なるデータストレージを選択できる

---

以上。