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パーシステンスパターン #

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

---

以上。