ikeh1024のブログ

ZennやQiitaに書くにはちょっと小粒なネタをこちらに書いています

AWS SUMMIT OSAKA 2019に参加してきました。

AWS

AWS SUMMIT OSAKA 2019のメモ書きと感想

  • AWS SUMMIT OSAKA 2019参加の忘備録。
  • 2017年のAWSomeday以来の、AWSセミナー参加。
  • ※会場で取ったメモそのままのものもあるので、意味が分からない文章もあるかもしれません。

申し込んだセミナー一覧

  • 自分が申し込んだセミナーは以下の通り

-w566

全体の所感

  • AWSのサービス自体の充実に加え、オンラインを含むセミナーやプログラムなど、AWSを普及させるための教育にもかなり注力していると感じた。
  • 2年で知らないサービスがいくつも立ち上がっていた。
  • 会社内にいるとどうしても視野が狭くなるので、こうしたセミナーに来て、様々な可能性を見聞きし、技術で解決できる範囲が広がっていることを更新し続けることが大事だと思う
  • 強制的にでも定期的にセミナーや勉強会（最低でも3ヶ月に1回、もくもく会は含まない）へ参加すべきだと思った。
  • 10:00-17:40のスケジュールで、MacBookProの電源がギリギリだったので次回から充電器は必須だった。
  • セミナーブースの雰囲気は怖い。なんだろうあのイケイケ感は…。
  • 結局最後の任天堂の導入事例が一番面白いと感じた。
    • 概要よりも実際の導入事例と運用方法を聞くと実感が湧くので、次からは企業の講演主体にしようと思う。

基調講演（10:00-11:30  会場：A-B）

前説

  • 9:55辺りから満席であぶれた人はサテライト会場に移ったとか。
  • 3.3兆円規模で41%の収益増大
  • リージョン：アベイラビリティゾーン（=例：東京に4つあってこれらをまとめて使用することで、一部に不具合があっても稼働率が高い = 可用性が高いという）
  • AWSはクラウドのシェア51%を誇る。
  • AWS_ DEVDAY
  • AWS_LAB
    • AWSは運用を相談できる場所を提供している
  • AWS_INNOVATE
    • 好きな場所・時に聴講できるオンラインセミナー
  • AWS_Educate
  • オンプレでは遅い。柔軟性・スピード感を出すための回答としてクラウド・ML等の最新技術がある

琉球銀行の話（クラウド導入した話）

  • 時間も短く薄めの話
  • 新入社員の初仕事はフラッシュモブ。研修にも組み込まれている。
    • 自分だったらいやだなあと思うけど銀行員って体育会系だから乗り気なんだろうか。
  • クラウドおじさんが一人で社内にAWSを普及していく概要
  • 60過ぎの再雇用の人がリーダで進めているとのこと
    • 沖縄には若い人がいないのかな…と心配にも感じる
  • クラウドを使ってタクシー事業・ローカル番組配信をしている
  • 最後にAWSの人からの感想で「我々はAWSの導入に積極的な彼らを応援します！」とあったが、AWS導入が正義という物言いは、暗殺教室の竹林くんのスピーチを彷彿とさせた。
  • （価値観がAWSの物差しで測られるのが歪だと感じるんだろうな）

-w260

クラウドジャーニー（オンプレ→クラウド遷移に関して）

  • オンプレからクラウドへの移行はそのときだけではなく、その後の運用が必要
  • クラウドにより最適化するように、新しい技術や改善を行う必要がある
  • 問題はDB（Oracle高い）とWindows
  • AWS上でWindowsが簡単な設定で立ち上げられる
  • めっちゃいろんなサービスが有るという話

京セラ（クラウドジャーニーに関して）

  • 基幹システムの刷新
  • オンプレミスからの移行も可能で、クラウドやっぱりは良いぞと言っていたことしか覚えていない。

NULAB（CACOOに関して）

  • アプリケーションの肥大化
    • ソフトウェアと分割してリリースする→開発速度の改善
    • アプリの分割をして技術的負債になっている弊社だが、目的もはっきりと別れていてあれだけ規模が大きい場合は分けたほうがいいんだろうな。
  • AWSを使いつつ如何に開発を効率化するかという実務の話でもう少し詳しく聞きたい。

Amazon Sumerian によるVR/AR/MRアプリケーションの開発（12:00-12:40  会場：C）

お昼ご飯

お昼にサンドイッチがでました。チープな見た目ですがしっかりと美味しいです。

概要

  • XR(Extended Reality) = VR, AR, MRをまとめた呼称
  • MR：マシンに仮想ボタンをつけるとか、古い機械にセンサを付けて表示をMRでするとかの用途がある
  • 従来はiOS、Viveなどデバイスごとに開発するのが大変
  • Webブラウザで開発する
  • 他のAWSサービスと連携できる
  • Sumerian Host
    • セリフをSSML形式で書くとその通りに動くキャラクタ
  • WebでARKit並に開発できるのか疑問だけど実際にやってみないと分からないね…。

XRの活用シーン

  • センサをの情報をAR,VR上で表示する
  • XRの使用例
    • ブランドエンゲージメント
    • デジタルサイネージ
    • AR Navigation System（地図を読み込んで矢印を表示）
    • 仮想トレーニングやシュミレーション
    • 気象情報の可視化

アプリケーション作成の流れ

  • シーン
    • （書き逃した…プロジェクト？）
  • エンティティ
    • 3D,2Dオブジェクト
  • アセット
    • シーンで利用できる3D, 2Dオブジェクト
    • CADのデータを読み込んで利用可能
  • 仮想ドローンをキーボードで操作する
    • キーボードと3Dオブジェクトの動きを連結させる
    • 複雑な操作はJavaScriptで記述できる

デモ

Sumerian単体（危険体験VR）

  • 意外としょぼい…
  • Fusion360のような画面

Sumerian+AWSサービス（SenseHatでVR上のドローンを操作する）

  • 他のAWSとの連携（デジタルツイン）
    • Iot機器：ラズパイ、SenseHat
  • AWS Iotを介して、MRからSenseHatへ情報を伝える
  • ラズパイで取得したデータをVR側に、HTMLでデータを表示
  • ジャイロセンサ.json→ 「Kinesis Data Stream」 → VR側に反映
  • AWS Iot：リアル機器からPCへ情報を送る役目？
  • 参考になる資料
    • チュートリアルが70用意されている
      • これらを参照すればだいたいやりたいことは実現可能
    • 公式ドキュメント
    • Learning Amazon Sumerian 60以上のチュートリアル
    • Youtube：デモをオンデマンド
    • Twitch：ライブのデモ
    • Slack Sumerian 開発者とのコミュニケーションを取れる

DeepRacerワークショップ（13:00-15:00  会場：I）

概要

  • 強化学習の学習用のサービス
  • 具体的には、マイクロマウスやロボコンのようなものだという印象を受けた。
  • ハードやソフトを提供し大会を開催することで、AWSのサービスを使ってもらい、DeepRacerというコミュニティを作成するのがゴールだろうか。
  • DeepRacerというトピックに絞って多くの人が強化学習を行うことで、高い知見を共有していく、というのは魅力的に思える。
  • ワークショップということで機械学習を知らない素人だけど大丈夫かな…と不安だったが、2時間は説明とテストだけで終わってしまうボリュームで杞憂だった。
  • 雰囲気はAWSの講演のようにギラギラと野望に満ちたものとは異なり、ゆるい雰囲気のワークショップ。手を抜いているとは思わないが特別力を入れているわけではなさそう。
  • AWS_漫画の紹介
  • 参加者はバッジとステッカーをもらえます。（ロケットリーグを彷彿とさせるアイコン）

強化学習

  • カメラ画像から行動を決定するモデル、を学習で作成する
  • 特定の環境下で一連の行動から学習
  • 良い行動に報酬を与える
  • 悪い行動には報酬なし
  • 許可学習において、特定の行動にインセンティブを与える報酬関数が大切
  • 報酬関数・価値観数
  • ステップの割引率（将来の行動にどれだけ影響するか）
  • 強化学習アルゴリズム：Vanilla policy gradiend(PPOを簡単にしたもの)
    • 学習はシュミレーター上で行う。実機では推論を行うだけ（学習済み層にデータを入れるだけ）
  • AWS RoboMaker：DeepRacer自体のメカニックな情報をデータ化する？
  • ハイパーパラメータ
    • 学習率：
    • バッチサイズ：まとめる画像数
    • エポック数：バッチのまとまり？
    • Discount factor_割引率：将来の考慮するためげ悪臭が遅くなる
    • エピソード数：シュミレートする回数
  • シュミレータと実環境のドメイン転移（差異）
    • 実際のコースの画像は荒かったりする
    • 戦略：
      • 環境制御を実世界に近いものにする（どの場所でも合わせたモデル or 特定の環境に合わせたモデル）
      • 環境にランダムな要素を追加
  • 細かい指定をSageMakerで行いモデルの清楚を高めていく方法
  • リーダーボード上位を目指すには知識が必要：AWS DeepRacer: Driven by Reinforcement Learning

他ブログ

DeepRacerワークショップ

  • 上記が緑色になるまで数分待つ

  • 再度行う際はDeepRacerのIAMを削除する必要がある

  • 質問はフォーラムへ

-w918

-w852

  • ModelNameはアンダースコアは不可

-w787

  • コースの選択

-w810

  • アクションスペースの設定
    • クローンする際は同じパラメータしか選べないので注意
  • 車が取りうる角度・速度など。3*5とで何通りシュミレートする細かく

-w828

-w745

-w764

  • ValidateでPythonの文法が確認できる

-w402

  • 報酬関数を先に決めて次にハイパーパラメータを決める、というのが一つの方法

-w807

  • どの程度学習させるか

-w814

  • お値段結構掛かる

-w1010

-w816

  • トレーニングを止める方法は上記をクリックするだけ
  • 学習済みモデルのS3バケットは削除されないので、消したい場合は手動で削除
    • S3でDeepRacerとかで検索すると良い

技術情報キャッチアップの実践アプローチ ～AWSプロフェッショナルエンジニアへの道～（15:00-15:40  会場：B）

所感

概要

  • 学習サイクルを身につける
    • Input：記事を見る
    • Output：書く・話す

Input

  • 通勤中にRSS ReaderでWhats newを読んで最新情報を確認
    • プッシュ通知を使って気づくことが確認
    • まずタイトルだけを確認して感心する記事のみ読むようにする
    • AWS News Blog
    • AWS Japan Blog
    • AWS Partner Network(APN)Blog
  • NewServiceTraining（週一の社内勉強会）に参加
    • 詳しい内容を共有
  • 週間AWS（1週間の内容をまとめたものを把握できる）

Output

  • Inputだけでは自分の理解にはつながらない
  • 書く・話す・実際にAWSを触る
  • 実際に技術に触れながら技術トレーニング資料を作成
    • AWSドキュメントを読み、実際に触る
    • 分からなければ社内の人に質問する
    • 資料として整理し、ハンズオン資料を作成
    • 自分の理解となるまで繰り返しリハーサルを行う
  • ユーザに技術トレーニングを実施する
  • ユーザからの技術的な問い合わせにメールで返信

AWS エンジニア ラーニングパス

AWSを触って学ぶには

  • 10分間チュートリアル
  • セルフペースラボ
  • AWS Labs：よりハードな内容
  • 利用用途に合わせて活用する
    • 最新の動向
    • 週替りで深掘り
    • 1年ごとのまとまった解説資料や事例
    • オフィシャルドキュメント（詳細を確認する際）
  • 社外・社内勉強会は効果的
  • JAWS-UG、1回の登壇>100回の勉強会参加
  • 技術ブログで情報整理・発信する

まとめ

  • 学習サイクルをつくる（5minのinputからでも良い）
  • 通勤時間を活用する
  • AWSに実際に触れて、テキストとして書き出す
  • 技術者同士で情報共有する
  • できればJAWS-UGに参加する

クラウド流 移行プロジェクトの進め方（16:00-16:40  会場：B）

所感

  • アタリマエのことを横文字と図でおされに見せているだけなのでは…。
    • まあクラウドといえどクリエイティブな仕事だけじゃないか…
    • 保守だからしかたないが率直につまらない
  • サービスのPRをしないのはなんか新鮮 → やっぱ宣伝ありましたね。

ファーストステップ

  • まずはサーバを建てることから始める。
  • 簡単なもののPoC→難しいもののPoCを行い、課題を確認する

「PoC」とは Proof of Concept の略で、新しいアイディアや概念、理論、原理の実証を目的とした、実導入の前段階における検証やデモンストレーションを指します。

ゴールを決める

  • コストダウン
    • 具体的なKPIにする
  • 対障害
  • イノベーション（スピード感）
    • リリースの回数をx回にする
  • クラウドネイティブなやりかた
  • リフト&シフト
    • オンプレのものをまずクラウドへ移動してみて、コストを下げていく（今回話すこと）
  • リフトシフト概要
    • 移行対象の分け方
    • 移行順序
    • 以降の方法
  • 移行対象の分け方
    • 特徴ごとに表にまとめる（一時のものか、社外でも使うかetc）
  • 移行順序の決め方
    • ビジネス効果が大きいものから
    • プロジェクト理づくが低いものから

6R

  • 移行コストとビジネスコストの天秤を書ける
  • Re-Host
    • OSやアプリケーションの中身を変えずに、そのまま移行
    • EC2に持っていくだけとか
  • Re-Platform
    • データベースをAWSのものにする
  • Refactor
    • WEBサーバ・DBをAWSのサービスで置き換える

移行時の問題

  • AWS クラウド導入フレームワーク
  • Well Architected Framework
    • 必要なキャパシティを勘ではなく、データを計測して決定する
  • クラウド移行のためのツールがいろいろ用意されていて、それらの説明を長々と。
  • AWS Snowball
    • 申し込むと物理的なハードディスクが送られてきて、それに大規模データ100TBなどを、ユーザはそれを送り返す。
    • 通信速度に依存しない
    • これは面白いサービス

Nintendo Switch Onlineを支えるサーバーシステム開発（17:00-17:40  会場：D）

所感

  • 今回のセミナーで一番面白かった！！
  • 専門的すぎて「なるほどわからん」となるのも結構あったが、大規模ネットワークでのクラウドの実際の使い方を目の当たりにすることができた。これは貴重な体験ではなかろうか。
  • こういう実構築の話を聞くとクラウドに足を踏み入れたくなってしまう。
  • 立ち上げ時にベストプラクティスを選び、技術的負債を抱えないためには、皆がとは言わないが専門知識の持った人が舵を取らないと、数年後に痛い目を見るんだろう。
    • （任天堂ですら技術的負債を非常に気にしているのに、弊社ときたら…）
  • マリオ等の任天堂イラストをスライドに使えるのが非常に羨ましい。

前置き

権利管理サーバ

  • Switch Online加入者の権利情報を管理
  • 独立したシステムとして開発
    • 他のシステムとはAPIで通信
  • 可用性
    • AWSのリージョンが落ちない限り大丈夫
  • スケーラビリティ
    • サービス規模の拡大似合わせて
    • 年末商戦でスパイクが発生したりするのでそれへの対応
  • レプリケーション遅延対策
    • 権利の即時反映はUXとして必須
  • Amazon Auroraの採用
    • 要件にマッチしていた
    • 負荷テスト、スケールアップもテストでOKだった
  • アプリ
  • インフラ
    • ALB, Route53, Lambda...
  • 売上に合わせてEC2やレプリカを増やしておき対応ができた
  • Aurora
    • 運用コスト（運用管理）が低いことがメリット
  • レプリケーションとバックアップとアーカイブの違い

セーブデータお預かりサービス

  • セーブデータのクラウドへのバックアップ
  • セーブデータとは…
    • データ構造はゲームによる
    • サイズはMB-GB単位
    • ユーザが数千時間遊んだ記録なので、大事に扱う必要がある
  • バックアップ場所
    • S3、耐久性と可用性が高い
    • SwitchからHTTPSで直接アップロードできる
  • いつバックアップするか
    • 自動で定期的にバックアップ

課題

  • セーブデータの一括転送

    • 世界中の回線環境で数GBのデータをアップロードできるように
    • 1Mbpsだと1GBに2h以上かかる
    • 対策：分割して管理する
      • 1Mbpsでも13min接続が維持できれば大丈夫
    • セーブデータを分割すると、効率的なアップロードが実現できる。差分だけサーバと動悸すればいい

  • S3読み書きの権限管理

    • 読み書きの権限は厳重に管理したい
    • S3だとRateLimitにひっかかるかも…
    • EC2だけで権限払したい
    • S3署名付きURLを作成し、権限払い戻しを行う

DBへの書き込み性能

  • 払い出したS3 KeyをすべてInsertするので負荷がかかる
  • 大量の書き込みをどのように対応するか
  • 今後ユーザが増えても、スケールアップだけで対応できるのが理想
  • Switch共有のため排他的制御が必要
  • 性能強化に期待
    • 人任せ。またシャーディング（データベースの）をする必要がどうせ出るかもしれない
  • 最初からシャーディングしたほうが良い
    • あとからアプリケーションのロジックを変更しないといけない
  • どうやってシャーディングをするか。
  • 技術的負債を抱える可能性がある
  • 別海として、Railsでユーザ振り分けを行わず、nginxに任せる方法
  • データベースを分けたことで弱点もある
    • RDSのメンテナンス、スキーマ変更が必要→自動化で対応
    • worldを増減させるのが難しい
    • wofld数を変えずにAutrolaのスケールアップダウンで対応

セミナー後の懇親会（未参加）

  • 全日程後にre:Mix という懇親会があったけど参加せず。
  • 友人は知り合い3人で時間を過ごしたようで、気楽にいれるなら参加してもよかったな。