AWS SUMMIT TOKYO 2019 Day2 レポート

はじめに

2019/6/12（木） ~ 6/14（金）で開催された AWS SUMMIT TOKYO 2019 の Day2 に参加しました。
AWS SUMMIT には初参加です。
会場の雰囲気や、受講したいくつかのセッションのサマリをレポートします。
発表資料は後日アップされるそうです。

agenda

• 会場の雰囲気
• セッションのメモ
  • AWS で実現する攻めのシステムモニタリング
  • 【初級】AWS でのデータ収集、分析、そして機械学習
  • AWS を活用したユーザー認証実装パターン解説
  • クラウド人材育成の現状と今後の展望（DMM.com 様事例のご紹介）
• 所感

会場の雰囲気

• 会場は幕張メッセです。JR 海浜幕張駅から徒歩 5 分ほどで到着しました。
• 会場内は中央に各企業の展示スペースがあり、それを取り囲むように各セッションの会場が配置されていました。
• とにかく人が多く、歩く際にすれ違う人とぶつかりそうになるくらいでした。
• セッション A~D は座席数が何百人単位と大規模で、かつ横並びのセッション会場のため、サイレントセッション（イヤホンをして講演を聞くスタイル）となっていました。
• AWS 認定資格所有者専用のラウンジがあり、電源付きの作業スペースが配置されていました。また、インタビューに答えるとオリジナルの T シャツがもらえるようです。
• web フォームからセッションに関する簡単なアンケートに答えると、ノベルティとかき氷 or アイスクリームがもらえます。

セッションのメモ

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

監視の目的

1. アプリケーションの正常性をチェックする
2. アプリケーションを元の状態に回復する
3. トラブルの原因を調査する
4. ユーザー行動を分析する
5. キャパシティを分析する

アンチパターンの例

1. 不適合な監視
   • web アプリの正常性チェックのために apache プロセス監視
     • ユーザーリクエストを発生させて e2e で確認すべき
2. 情報不足
   • オートスケールの結果インスタンスが消失してログも消失
   • リアルタイムシステムの調査用に 5 分間隔のメトリクス収集
3. 通知過多
   • error を含むログが出力されたら全部メール通知

適応型モニタリングとは

以下の 4 つのステップからなるサイクルを繰り返し、監視設計をシステムに適応させ続けるプロセス

• Collect（収集）
• Monitor（監視）
• Act（実行）
• Analyze（分析）

これら 4 ステップの継続的な振り返りと監視設計の見直しが必要

各ステップで使用できるサービス

• Collect
  • Cloudwatch Metrics
  • Cloudwatch Logs
  • Kinesis data firehose
    • ログを s3 や Elasticsearch service に転送
  • vpc フローログ
    • vpc ネットワークトラフィックのログ
• Monitor
  • Cloudwatch Dashboard
  • Elasticsearch service + Kibana
    • よりリッチなダッシュボード
  • trusted advisor
    • コスト削減、パフォーマンスの向上、セキュリティの向上
• Act
  • autoscaling
    - リソースの調整
  • cloudwatch event + lambda
  • system manager
    • ssm run command
      • 管理対象のサーバでコマンド実行
• Analyze
  • 分析ツール
    • Cloudwatch Logs Insight
      • シンプルな言語でクエリ 可視化もできる
    • Elasticsearch service
      • rest api でクエリし全文検索
      • Kibana でリッチな可視化も
    • athena
      • 複数の s3 ファイル内を検索
  • BI ツール
    • quicksight
  • 予測ツール
    • amazon forecast
      • メトリクスなどを予測

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

1. アプリレベル監視パターン

• ELB + EC2(auto scaling) + RDS の構成
• 外形監視（Cloudwatch Event + Lambda）
• ELB （ユーザーに近いところから）のログやメトリクスを集計
• ELB のアクセスログを使用しユーザーの行動を時系列で分析、予測

2. モニタリングインテグレーションパターン

• オンプレとクラウド両方に監視を入れる場合、サードパーティの監視ソフト/サービスを使うのが有効
• AWS で取得したメトリクスをサードパーティの監視サービスに連携

3. ログ集約・分析プラットフォームパターン

• ログデータを s3 に集約
  • kinesis firehose を使う
• データを変換/変形
  • glue を使う
• ログデータをクエリし確認
  • Athena
  • Quick Sight

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

データ活用の流れとデータレイク

• データ活用の流れ
  • 過去を蓄積
  • 現在を理解
  • 未来・未知を予測
  • 意思決定
• データに基づいた意思決定に必要なこと
  • シーズからではなく、ビジネス課題からスタートすること
  • 以下のループを回し続ける
    1. ビジネス課題
    2. データ収集
    3. データ分析 or 機械学習
    4. 評価
• 過去（データ）の蓄積に最も時間がかかる
• やりたいことは後から必ず変わるので汎用的なデータの持ち方をする
  • データレイクをデータ活用の基盤とする
  • 全てのデータを一箇所に集めて、そのままの形式で保存
  • データレイクには s3 の使用がおすすめ

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

• 何からやるべきか？
  • データ活用は、常にビジネス課題からスタート
    • データを早く集め始めることが重要だが、それを目的化してはいけない
  • まずは一本のデータ活用フローを作ってみる
  • ビジネス課題 -> データベース、ログファイル -> s3 -> 可視化（BI ツール）-> 意思決定と評価 -> ビジネス課題
  • 上記のループを回す
• データ活用フロー設計のポイント
  • 万能なツールは存在しない -> 適切なツールを適切な対象に適用
  • やりたいことは変わる -> マネージドサービスで作る
  • 扱いたいデータ量も変わる -> スケールアウトするようにサーバーレスで作る
• 分析基盤（下に行くほど高度なスキルが必要）
  • sql で分析 -> AWS Athena（クエリサービス）
  • 高度な sql 分析 -> AWS RedShift（データウェアハウスサービス）
  • hadoop/spark で分析 -> Amazon EMR（hadoop クラスターサービス）
• 分析ツール（下に行くほど高度なスキルが必要）
  • 非エンジニアが参照 -> Amazon QuickSight
    • サーバーレスの BI サービス
    • 利用者はブラウザで BI を利用
    • spice : インメモリの計算エンジン
    • csv をアップロード or s3 から取り込みで分析
    • Athena と組み合わせる事で大規模データでも対応可能
  • データアナリストが活用 -> 3rd party toools or Amazon ElasticSearch Service
  • データサイエンティストが活用 -> Amazon Sagemaker
• データ活用フロー設計の順序
  • データ収集
    • データの中身、細かさ、頻度
    • 後から増やせないので可能な限り細かくデータを取るほうがいい
  • データ蓄積
    • s3がよい
  • データ変換（ETL）
    • サーバーレスが基本方針
    • 下に行くほど実装コスト大
      • 小規模な処理 -> lambda
      • 中規模 -> glue python shell
      • 大規模 -> glue spark job

機械学習の活用

• 機械学習も、常にビジネス課題からスタート
• 機械学習で解けそうな問題を理解する
• 注力する領域を決める -> 全てを自前で作る必要はない
• QuickSight ML Insights
  • 専門家不要で使えるインサイト機能を提供
• aws が提供する機械学習サービスの例
  • AI サービス （知識必要なし、使うだけのサービス）
    • amazon rekognition
      • 学習されたモデルを利用
    • amazon personalize
      • サービスでモデルを学習して利用
  • ML サービス （モデルを自分で作りたい時）
    • amazon sage maker
      • 機械学習のワークフロー全体をカバーするマネージドサービス
      • ラベリング -> モデル開発 -> 学習 -> モデル変換・推論

まとめ

• 常にビジネス課題からスタート
  • 早いことは大事だがそれを目的化してはいけない
  • まずは一本のデータ活用フローを組んでみる
  • ループを回して評価をし、データ活用が役立つことを確かめる
• データレイクはデータ活用の基盤
  • s3 がよい
• 目的と使う人にあったツールを選択する

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

ユーザー認証の概要

• パターン A : 従来型（HTML ベース）の web アプリ
  • 毎回 html を取得し、画面更新する
• パターン B : モダンな API ベースの web アプリ
  • 最初に html ゃ javascript を取得
  • 画面は部分更新
  • AWS の API にアクセスする際に credential が必要
• パターン C : クラウドベンダー提供のアプリ
  • 実装はベンダー依存
• ユーザー認証に関連する関連事
  • 強固な認証（MFA など）
  • ユーザビリティ（SSO など）
  • ガバナンス/コンプライアンス
  • 構築/運用性
  • これらはマネージドサービスを活用して解決

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

• ID 管理/認証/認可に関連するサービス
  • ID 管理&認証
    • AWS Single Sign-On
      • 複数の aws アカウントやビジネスアプリへのシングルサインオンを実現
    • AWS Directory Service
      • マネージド型 microsoft active directory
    • Amazon Cognito
      • カスタムアプリや awsAPI の認証・認可を提供
      • ユーザープール : 認証機能を提供
      • ID プール : 認可機能を提供
  • 認可
    • IAM
    • AWS secrets manager

ユーザー認証の実装パターン

• パターン A
  • A-1 : 認証サービスの活用
    • Amazon cognito の活用
    • OIDC 準拠 ID プロバイダの活用
  • A-2 : カスタム実装
• パターン B
  • B-1 : API を API Gateway で提供している場合
    • amazon cognito user pool
  • B-2 : カスタム実装
  • B-3 : Amazon Cognito ID プールの利用する方法
    • ユーザープールで認証
    • 外部 ID プロバイダで認証
• パターン C
  • C-1 : シングルサインオンを提供したい場合
    • AWS Single Sign-On
  • C-2 : AD を活用したい場合
    • AWS Single Sign-On
      • オンプレミスの AD も統合可能
• 参考
  • AWS Amplify
    • モバイルアプリおよびウェブアプリでの認証の作成、設定、実装を容易化するサービス

クラウド人材育成の現状と今後の展望（DMM.com 様事例のご紹介）

人材育成観点での IT 市場状況

• そもそも IT 人材の人口が不足
• さらに IT エンジニアのスキルシフトが必要
• 効率的学習の必要性
  • 受動的から能動的へ
  • input から output へ
  • 教わるから教えるへ
  • 技術の移り変わりが早く input がコロコロ変わるので、サイクルを小さく早く回すことが大事
• AWS 人材育成の先進企業が気にしているポイント
  • 小さくてもいいので早く始める（脱完璧主義）
  • ハンズオン、現場経験の量（ハンズオン環境の重要性）
  • 情報発信の機会を作る（社内勉強会/コミュニティ）

AWS トレーニングの特徴

• クラウド知識の定着
  • 講義 + デモ + ハンズオン
• アウトプットとフィードバックのループによる実践力の向上
  • ディスカッション + プレゼン + レビュー
• 講義終了後の具体的な学習パスを紹介
  • aws 無料学習コンテンツ、web サイト
• 講師は案件経験が豊富なエンジニア出身者

dmm.com の人材育成事例

• 取り組み 1 : aws 実弾演習場
  • 開発職従業員に対して、自由に aws が利用できる環境を提供
  • aws の学習や自由研究的な開発などでの利用が可能
  • 一人 100$/月を目安に自由に利用できる
• 取り組み 2 : 社内 AWS 勉強会
  • aws に協力をもらい社内 SRE チーム・有志が勉強会を開催
  • テーマ例
    • aws を基礎から学ぶ
    • dmm.com 内で標準になっていくだろう技術ハンズオン
  • 月 1 or 2 ヶ月に 1 回くらいのペースでやっている
• 新卒研修
  • 期間は 3.5 ヶ月
  • 内製でつくっている
  • 前半
    • 基礎技術研修
      • インフラ（オンプレ、クラウド両方やっている）
        • AWS 研修
          • Essential 1,2（1 は内製）
          • Architecting on AWS
          • Architecting on AWS の後にハンズオン 1 日
            • 内容は 2018 の AWS SUMMIT で好評だった Dev AWSome Day の内容を活用したもの
          • 講義の後にハンズオンを入れてインプットとアウトプットのサイクルを短く
          • ディスカッション、アウトプットを重視
          • 3 人 1 組でモブプロ、振り返りを取り入れている
      • web 開発
      • アプリ開発
        • android
        • ios
    • 書籍学習（輪読する）
      • リーダブルコード
      • エンジニアリング組織論への招待
      • 大規模サービス技術入門
    • 開発手法
  • 後半
    • チーム開発演習

まとめ

• aws skill guild
  • クラウド活用を推進するにあたり、必要なスキルを持った技術者集団を作るための、カスタマイズされた教育プログラム
• AWS が以下を支援
  • 社内でクラウド技術者育成を推進する組織（CCoE : Cloud Center of Excellence）メンバーの教育
  • CCoE メンバーによる継続学習の仕組みづくり
  • CCoE メンバーによる教育（研修内製化）
• 自学なしでのエンジニアの品質維持が難しくなってきた
• CCoE 候補の自学者を置き去りにしない会社としての配慮が非常に重要

所感

• 初の AWS SUMMIT 参加でしたが、今まで触れたことがないサービスを知ったり、他社の事例を知り、外の世界に触れられたことは非常に良い刺激になりました
• セッションの中で自学に有効な WEB サイトを紹介してくれるなど、AWS が自学（self learning）を推奨していることがひしひしと感じられました
• 機会があればぜひ来年も参加したいと思います