トップ > コミュニティ活動 > AWS Summit 2018 Tokyo 行ってきました！Day 2 レポート

AWS Summit 2018 Tokyo 行ってきました！Day 2 レポート

コミュニティ活動

Day 1のレポートはこちら↓
xblood.hatenablog.com

Tech系セッションは後ほど動画が公開されたらリンクを貼りたいと思います。
Day 2のレポートを書いていくよ！↓↓↓

Day2 5月31日(木)

09:00-09:40 AWS パートナープログラムのご紹介

  • AWSはアーリーアダプターからマジョリティへ
    • ４年前は、AWSのイベントには"とても詳しい質問をしてくる人"と、"クラウドって何ですか？って人"がきていた。
  • 日本型の中抜きビジネスは今後通用しない。絶対的な利益額が減り、上流が通じなくなる。
  • 本業集中と内製化。
    • システムインテグレーターに請負させるのではなく、優秀な人間を会社で囲い込む、雇用する戦略に移っている。
  • クラウドインテグレーターが１週目は勝利した。
    • ２週目はこれから
  • IT従業員の7割がアプリケーションエンジニアで、インフラエンジニアは3割ほど。
    • クラウドはAPIでコントロールするデータセンターサーバー。だからアプリケーションエンジニアにFitする。
      • だが、当初はインフラエンジニアがAWSに振られていた。
  • 会社規模・知名度ではない。プロジェクトマネジメント能力は重要。
  • 自社の強みを世の中にアピール。コンピテンシーを所有していることを証明とか。
  • 成功したパートナーの３つの共通点
    • チャンピオンのアサイン
    • セルフラーニング
    • ダイレクト タッチ
  • チャンピオンのアサイン
    • 会社の中で中心的な人物を
      • 後輩に慕われている、AWSのテクノロジーを詳しく知る必要はない。テクノロジーに詳しい人は別ポジションにアサインすればよい。
      • どちらかというと技術寄り、フットワークが良い、リスクをとって進めることができる。"確認します。"では遅い。
      • プレゼンテーションが嫌いではない。
      • AWSと言えばこの人と言える人
  • セルフラーニング
    • Business Professional Online/Technical Professional Onlineは全員受講
    • 技術者は、Black Belt Onlineセミナー、JAWS UG XXX支部に参加
    • 初心者はAWSSome DayやSTP-Fなどの無料トレーニグを積極的に活用
    • 会社として、受講費用を提供、認定資格を会社が負担
    • まずは触ってみる。アウトプットと共有。その文化。
  • ダイレクト タッチ
    • 自社の強みを磨いて、顧客と直接対話すること。
    • 2020年4月1日 法改正
    • 短納期・Pay per user型
所感

"テッキーな方々"という呼び方面白い。
各社の雇用状況については、やっぱり敏感に反応しておかないといけないよねぇ。自己実現のためにも。

10:00-10:40 AWS の DataLake を使ったデータ分析入門

  • データ活用の考え方、データレイクの考え方、データ活用のための試行錯誤などが主なセッション
    • データを貯める->可視化->分析/ML
      • 試行錯誤のサイクルをいかに高速に回せるか
  • RDB
    • スキーマが定義されている、データの型も強制できる。アクセスするツールが簡単。トランザクションも。
      • スケーラビリティに限界がある。非構造化データに対応しずらい。リアルタイム分析など当たらな要求に対応できない。
      • データのサイロ化による対策。しかしサイロ化の課題も。
  • 全てのデータを生のフォーマットで安全に保持することがデータレイク構想。
    • ストレージと計算処理の分離、SSOT、様々I/O手法に対応
  • サイズ制限からの解放も必要ですData Lakeは。
  • システム全体のハブとして機能する。
  • データレイクのためのAWSサービス
    • 保存：S3
    • 収集：OSS on EC2(fluentd, logstush)、Kinesis、Snowball、AWS IoT
    • 分析：Redshift, EMR, Athena, Glue
    • 可視化：QuickSight, パートナーソリューション（要望によって違うので）
  • 事例
    • Finra, prieNumber(DMP)
所感

システムは改善を止めたら死 = 分かる
これを人生にも当てはめると面白い。
自分自身のキャリア開発を止めたら・・・死ではない。
だけど成長が止まる。成長が止まったらよくない。
つまり、システムであろうと、自己実現であろうと同じベクトルに向ける、それが一番大事!?。
そして、PCに貼るステッカーも改善を止めたら死（ぉ）
・・・サービスのロゴも変わるのでダサい・・必要なシール以外貼るのやめよう。→ めっちゃ剥がしたｗ

12:00-12:40 AWS のオペレーション最適化の勘所

  • AWS Config Ruleで必須タグの強制ができる。
    • まぁ、しかしながら、タグで全て管理しようとしても無理があることは納得。
      • IAMアクセスポリシーでタグを指定すると大量のタグを指定しないといけなくてポリシーが書けない（文字数制限に引っかかる）とか。
  • AWS Organization
  • AWS Support
    • AWS Suportを利用する場合は、問い合わせするフォーマットを徹底することで対応スピードが上がる。発生日時、リソースなど。
    • リソース毎にチケットは切っていったほうが良い。緊急度も適切に。
  • 請求APIとか、Trusted AdvortiserAPIとか。
  • Personal Health Dashboardも活用してみたい。https://phd.aws.amazon.com/

13:00-13:40 DevSecOps on AWS - AWS のモニタリング-

Dev && Sec && Ops

  • クラウドネイティブセキュリティ
  • AWS上でのDevSecOps実装方法
    • Metrics-Based, Event-Based, Rule-Based
    • Trusted Advisor, CloudTrail, GuardDuty, CloudWatch, Config, Macie
  • セキュリティベースライン作成の考え方
    • MasterにはIAMロール作るけど、子アカウントには作らない。
      • 理由としては、キーのロールとか面倒になるから。
    • Lambdaの集約
      • 管理が簡単。
  • Admin側に情報を集約する方法に、CloudWatch Event Busという手法がある。
    • Admin側にパスされるので、ターゲットアカウントのイベント発生をトリガーにAdminのLambdaを起動できる。
  • Cloudtrailの有効範囲を設定できる。
    • Cloudtrail Realtime report?
  • Aws Configはインベントリチェックもできる。
  • System Managerのインサイト機能、便利やな。
  • まとめ
    • マルチアカウント、マルチリージョンへの展開as a code
    • イベント集約管理も

14:00-14:40 【京王電鉄様ご登壇事例】AWS、Alexa を活用した情報システム部門のクラウドシフトの進め方

  • ユーザー企業のシステム部は新技術というよりは、主業務に関わるシステムの最適化が求められていた。
    • 最近だと売上出せという傾向もある・・と。
    • 20年、30年とか使い続けるシステムもあったと。
  • Kintone, DataSpiderとか利用。
  • AWS導入状況
    • メールマガジン、スマートフォンアプリ、高速バス予約、ポイントシステム、観光業、データレイクなどなど
      • ハイウェイバスドットコム

いいからAlexaの話はよ。(30分経過)
京王の情報システムのエンドポイントAPIと連携するLambdaファンクションってところかな。

  • Alexa 開発の落とし穴
    • 耳で聞いて声で操作。
    • 表現の幅が狭い
    • 作り手側による制御が困難
    • 完成後のギャップ大
  • 京王スキルでプッシュ通知開始！
    • 京王スキル、ハイウェイバススキル、京王ライナースキル
  • ハイウェイバススキル
    • 呼び方とか大変だった。けっぱち　とか呼ぶ場合もある。
  • 京王バススキルは決済まだー。
  • まとめ
    • まずさわってみること、できることは自分たちでやってみる　など・・
  • ユーザー企業向けまとめ
    • 今までみたことがない項目の明確な回答にベンダーは気を配って欲しい。
所感

Direct Connect上手に活用してるんだなー！
企業ってのは、人の人生を預かっているんだっていうことを、もう少し理解して欲しいよね。
SIerみたいな人売り商売だとそれは皆無だろうけど。

いろいろ聞いてみて思うのが、インプットを頭の片隅にでも必ず残しておいて、
それをアウトプットという形にできなくても業務で使う時にアウトプットとして残せれば、
その時に初めてセッションに参加してよかったって思えるんだろうなぁ。

15:00-15:40 ストリームデータ分析の AWS 設計パターン

  • 取込->変換->分析->アクション->保存
  • 拡張性、耐障害性、速度
  • [New]Kinesis Video Streams
  • マネージドサービス同士で接続を検討
    • 無理ならLambda関数で接続を検討
    • EC2上のアプリで接続を検討
  • まとめ
    • よりリアルタイムな世界へ
    • 動画や音声もストリームで
    • ストリームデータ ✖️ 機械学習
    • AWSのマネージドサービスを利用してシンプルに修正

16:00-16:40 AWS のリアルタイム処理入門

  • リアルタイム
    • エッジコンピューティング：greenglass
  • ニアリアルタイム
    • ストリーム処理：Kinesis
  • リアクティブ
    • リアクティブ宣言 reactive manifest, responsive(即応性), resilient(障害耐性), elastic(弾力性), message-driven(メッセージ駆動)
  • イベントソーシング
    • Lambdaのイベントソーシング
      • スケジュール処理から脱却しよう。
  • ステートマシン
    • AWS Step Functions

17:00-17:40 AWS のエッジネットワーク入門

すまねぇ、聞いたことのある話ばかりだった。

  • AWS Edgeサービス
    • CloudFront, Route53, WAF, Shield, Lambda@Edge
      • レスポンスの遅延、不安定なレスポンス、大量アクセスへの対応など
  • Lambda@Edge
    • エッジにおけるサーバーレスコンピューティング
    • CloudFront + Lambda = Lambda@Edge
    • Lambda@EdgeはNode.js
    • 世界中のロケーションにLambdaがレプリケーションされる。
  • Lambda@Edgeのユースケース
    • キャッシュヒット率の向上
      • キャッシュコントロールヘッダの変更
    • コンテンツ生成
      • 画像リサイズ、HTMLページ生成
    • セキュリティ
      • トークンハッシュを使用した認証

18:00-18:45 Meet the builders ~ 社員が語る AWS とは ~

面白かった！開発はシアトル勤務・・。

  • AWSサービスは顧客ニーズの95%で出来ている。
  • DynamoDBを開発しているAWSエンジニアが語る Part1
    • 一つと言われたらOwnership model -> devopsのiterateが重要。作っているサービスを育てていく。大事にしていく。チームとして全て自分たちで出来る。逆に言うとなんでも出来る。デザインの時点で作り込んでいけることは、とても良いこと。やっていけばどんどんうまくなっていく。テストしたり運用に時間がかかると、リリースが遅れていく。どこに投資を出来るか、ということもチームで決めていく。テストしにくくなったらリファクタリングして育てていく、ということが重要。Single thread owner。Two pizza Team チームのサイズはピザ２枚分くらいがいい。チームとしてひとつのことを考えられ続けることができる力。一つのことを考え続け、どのように顧客側に貢献するかという夢を考える。MicroserviceのSingle threted Ownerとしてどのようにしていくのかを考える。
  • スピード感の維持について
    • 社内の組織の工夫。
    • 普段は組織なんだけど、緊急事態の時は、お客様の方に向くことが大事で、組織がフラットになることがすごい。
      • Amazonは地球上で最もお客様中心の考えになっている。
  • 今までの延長線上で考えるとダメだよってよく言われる話。
    • 常にチャレンジ。
  • DynamoDBを開発しているAWSエンジニアが語る Part2
    • 人がものをつくっていくという自覚。360度のフィードバックを活かしていくことができるというのが良い。イノベーションはやったことないことをやらないといけない。失敗した時に失敗するとおこられるじゃなくて、フィードバックとしてどうして失敗したのか、失敗してよかったのかなどを通して成長していけるカルチャーが素晴らしい。

19:00-19:40 【AWS Tech 再演】Amazon Redshift の 設計・運用大原則

  • 1.サイジングをちゃんとする
    • 設計段階である程度シェアなサイジングを行う
    • 初期容量のみでサイジングしない
    • 可能な場合は大きめのノードサイズを選択する
      • a.)容量ベースのサイジング、b.)性能ベースのサイジング
  • 2.Spectrumのアーキ原則をおさえる
    • パーティション、列志向ファイルフォーマットを活用する
    • データ量に応じたノードスライス数を用意する
    • データの持ち方を工夫する
  • 3.COPYの基本ルールを守る
    • 1コピーで複数ファイルを並列ロードする
    • 可能な場合は常にS3からロードする
    • 一意性制約の特性を理解する
    • エラーハンドリングを実装する
    • ロード時ありがちな問題
      • 一意性制約の行がロードされる
      • テーブルとファイル間の不一致
      • デリミター問題
  • 5.同時実行要件に正しく対処する
    • 実測する
    • 「現行システム要件」の実態を見極める
    • 本当に多数の同時実行クエリー数が必要な場合は、スロット細分化以外の方法を考える。
  • 6.クエリー特性を考慮する
    • スループット重視のバッチとレスポンス重視の対話クエリーはキューを分ける
    • 探索的クエリーなどのロングクエリー／ローグクエリーが想定される場合はクエリーモニタリングツールで予防線を張る
    • BIツールからの定型クエリーに対する備えをする
  • 7.VACUUMを工夫する
    • VACUUMを実行しないで済むように設計する
  • 8.更新処理を工夫する
  • ベスト・プラクティスやアンチパターンに留意することが望ましい
    • 従来型DWHとの互換性とクラウドの恩恵を両立することができる。
  • クラスタ構成 -> ロード -> クエリ -> ハウスキーピング

全体所感

Day 3は諸事情により参加できなかっため、私はDay 2でおしまいです。
1日中、質の高いセッションを聞いていると、本当にいろんな人が私よりがんばってるんだと感じる。
だからこそ、同じくらいがんばらないとダメだと思える。仕事でもプライベートでも。
どれだけいろいろな人が高度で大変な仕事をしているのかという気持ちを、いつでも持っていたい。

2日目のお昼ごはん！量少ないのに満足できるなぜだろう。

参加した皆さん、お疲れ様でした！
以上で、AWS Summit 2018 Tokyoのレポートは終了です！