20190620 aws summit_tokyo_2019

AWS Summit Tokyo 2019 報告
株式会社ピクセラ
製品事業本部
ソフトウェア開発部門
先端技術開発部
© 2017 PIXELA CORPORATION｜PIXELA CORPORATION PROPRIETARY AND CONFIDENTIAL.
2019年6月20日

アジェンダ
○ AWS Summit Tokyo2019 概要
○ 各種イベント状況
○ セッション聴講まとめ
○ 参加所感と今後の指針
Copyright © PIXELA CORPORATION. All Rights Reserved.｜PIXELA CORPORATION PROPRIETARY AND CONFIDENTIAL.
2

AWS Summit Tokyo2019 概要
3

概要
2019/06/12-14 @ 幕張メッセ
公式ページより
“AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、アマゾ
ンウェブサービス (AWS) に関する情報交換やコラボレーション、学習を行うことがで
きる日本最大級のカンファレンスです”
今回、主に学習を目的に参加してきました。
4

入場待機列
5

スポンサー
6

ホール & 会場MAP
7

各種イベント状況
8

会場A-D
9

10

11

出展ブース
12

AWS Expo
13

スタートアップのアーキテクト賞レース
14

Deep Racer リーグ
15

セッション聴講まとめ
16

まとめについて
○ 全セッション撮影禁止であったため、写真はありません。
○ 後日資料が公開される予定です。
○ 参加セッション&訪れたAWS Expo展示が多いので、各話題毎にまとめます。
17

サーバーレス
○ サーバーレスとは
○ サーバ管理が不要
○ ソフトウェアのインストール不要
○ パッチの適用不要
○ 柔軟なスケーリング
○ 必要なときに自動で拡張
○ ストレージ、ネットワーク帯域のキャパシティ考慮が不要
○ アイドル時のリソース確保が不要
○ アイドル時には課金がされない
○ AWS SAM (Serverless Application Model)
○ AWSサーバレスアプリケーションを表現するスタンダードモデル
○ サーバレスアプリケーションのデプロイと管理を簡素化
○ https://github.com/awslabs でサンプルが公開されている
18

サーバーレス
Resources:
hogeFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs8,10
CodeUri: s3://hogeBucket/code.zip
Events:
GetResource: Type: Api # API Gatewayが暗黙的に追加される
Properties:
Path: /resource/{resourceId} # カッコはパスパラメータ
Method: get # HTTPメソッドを指定
○ AWS SAM CLI (旧 SAM Local)
○ サーバレスアプリのためのローカルテストツール
○ ローカルマシンでレスポンスやログの確認ができる
○ Lambdaの実行環境をシミュレートしたDockerイメージ
19

サーバーレス AppSync
○ GraphQL
○ RESTの持つ問題を解決するために開発された規格。クエリ言語とスキーマ言語からなる
○ クエリ言語は、以下の処理系を記述します。
○ Query
○ Mutations
○ Subscriptions
○ スキーマ言語
○ リクエストされたクエリは、スキーマ言語で記述したスキーマに従ってGraphQL処理系により実行されて、レス
ポンスを生成します。
○ AWS AppSync: AmazonのマネージドGraphQLサービス
○ GraphQL デモがありました。
○ 10分程で簡単な GraphQL サーバレスサービスを立てられていました。
→ REST API の検討の前に、GraphQLの検討をお勧めします。
20

マイクロサービス/サービスメッシュ
○ マイクロサービス (<-> モノシリック)
○ ソフトウェア・コンポーネントの疎結合と独立性を徹底する
○ 小さなサービスを組み合わせて、1つのアプリケーションを開発する
○ 各サービスは、独立したプロセス(コンテナ)で動作する
○ 各サービスは、RESTやメッセージングのような軽量な仕組みで通信する
○ 各サービスは、完全に自動化された仕組みで、それぞれ個別にデプロイされる
○ 各サービスは、それぞれ異なるプログラミング言語で実装できるし、異なるデータ・ストレージを利用できる
○ サービスメッシュ
○ 各サービスが他のサービスと連携するために構成されるネットワーク
21

マイクロサービス/サービスメッシュ
○ マイクロサービスの課題
○ サービス分割点の正解がない → (DDDとか利用してなんとか決定)
○ デバッグ/テストが難しくなる
○ サービス間の通信の信頼性
○ サービス間の可観測性
○ …
→ 一部課題の解決策 Envoyプロキシ
各サービスにProxyレイヤーを置いく。プロキシレイヤーがIFを担う。設定Yamlを書いて突っ込む。
○ トラフィックコントロール
○ ルーティング
○ メトリクス
○ 分散トレーシング
○ デバッグ
AWS App Mesh
○ EC2, ECS, EKS 等で稼働するサービスに対してEnvoy プロキシを使用してくれる。
22
Ser
vice
A
Ser
vice
B
Proxy Proxy

運用
○ ビジネス価値の定義
○ SLA合意を定義し、達成度を計測する。
○ 価値を提供するためのモニタリングと継続的な改善
○ モニタリング対象は、個別のリソースではなくアプリレベルの状態を収集する必要がある
○ アプリを元の状態に回復する
○ アプリの正常/異常を定義する
○ 異常状態への状態変化を検知する
○ 異常状態から正常状態に復旧する方法を用意する
○ トラブルの原因を調査する
○ 事象の因果関係を調査するために高いレベルのログやメトリクスが必要
23

運用
○ 運用のクラウドネイティブ化＆サイクル
○ 準備: 優先事項定義
○ インスタンスのリソース状況ではなく、サービス全体の状況を決定する値の決定 (例レイテンシ)
→ Cloudwatchで複数リソースに渡るカスタムメトリクスを定義可能
○ 運用: 健全性のチェック、イベント対応、回復
○ アプリの正常/異常を定義する
○ 異常状態への状態変化を検知する
○ トラブルの原因を調査する
→ Cloudwatch events -> Lambda で定期的HTTPアクセス
→ ログをElasticSearch に流しこみ、可視化
○ 発展: 知見の共有、分析、予測
→ ログをS3へと流し、 Athenaによるログ分析
→メトリクスなどの時系列データを元に, AWS Forecast 等を用いて予測する
24

運用 (EC2等の利用)
AWS official AMIは、System Manager Agentをインストール済み。ロール付与で機能有効化可能。
○ SSM RunCommand (インスタンス上でのコマンド実行)
○ sshを使ったりポートを開けたりするわけではない
○ グループに対しての一斉実行指示が可能。
○ エージェントに指示を出すだけで、上りの通信を使っている
○ 結果をCloudWatch LogsやS3に出力してくれる。
○ SSM MaintenanceWindow （スケジューリング)
○ 決まった時間にRunCommandやAutomationを起動
○ 同時実行数制御や実行履歴の確認が可能
○ インスタンス郡を決まった時間帯だけ起動するのに利用できる
○ AWS Solutions - Instance Schedulerを利用できる
○ SSM PatchManager (パッチ自動化)
○ OSやライブラリのパッチが発行されてから、どのくらいの経過時間で適用するかの指定が可能。
○ SSM License Manager
○ DBライセンス等の自動管理
25

開発
○ Cloud9: AWS上でのIDE。またはプラグイン提供
○ Eclipse
○ VS
○ VS Code (Preview) and more
○ CI/CDパイプライン
○ 開発者がコードをCodeCommitにプッシュ
○ CodePipelineがリソースの変更を検知
○ CodeBuildが起動し、ビルド、テストを行い、デプロイ用の成果物を作成
○ビルド命令発行と同時にインスタンス立ち上がる = 待機キュー無し
○ CodeDeployでデプロイする
→ これらをまとめた CodeStart サービスがある。
26

開発
○ 段階的なデプロイメント
○ Deployment Preference Typeを指定することで可能
○ Canary10Percent30Minutes
○ 10%のトラフィックを30分間新しいLambdaに流し、その後100%新しいLambdaに流す
○ Linear10PercentEvery10Minutes
○ 10分ごとに10%ずつ新しいLambdaに流す
○ AllAtOnce
○ 即時にすべてのトラフィックを新しいLambdaに流す
○ アラーム
○ デプロイメントで何かしらのエラー（アラーム）が発生すると自動でロールバック
○ フック
○ 新しいトラフィックの開始前後でLambdaをフックできる
○ LambdaはCodeDeployに成功、失敗をコールバックする
○ PreTraffic トラフィックが流れる前にLambdaが起動
○ PostTraffic トラフィック流れ出した後に起動
27

開発
○ APIGateway：Canaryリリース
○ 新しいステージのデプロイに進むトラフィックの割合を設定し、ステージの設
定や変数をテストできる
○ Canaryリクエストは, 自身のCloudWatch Logsグループに送信される
○ 問題がなければCanaryリリースを本稼働に昇格させCanaryをデプロイから無効
にする
28

開発
○ 監視・モニタリング
○ CloudWatch
○ ログ収集基盤
○ 他サービスに柔軟に接続可能
○ Kinesis :データストリーム収集, 加工
○ S3 <- Athena によるクエリ
○ DynamoDB (NoSQL)
○ Elastic Search: 可視化
○ AWS X-Ray
○ AWS サービス間の詳細状況を監視
○ Lambda等では、内部にX-Ray用のコードを仕込めば、監視される。
29

開発
○ CI/CDを自動化しているチームはコードをより早く、自信を持ってコードを書いて
いる。
○ 頻繁なデプロイが 33倍増加
○ リードタイムが 440倍減少
○ ミスが 60倍減少
○ 予期しない作業を 21% 削減
○ 新しい作業にあてる時間を 44% 増加
○ ~AWS Expo の Cloud9 担当者様のコメント~
1社で数TBのレポジトリ運用されているケースもある。
30

セキュリティ
○ AWS CloudHSM
○ 平文はHardware内のみで保持。そこには誰にもアクセスできない。
○ AWS KMS
○ 複数層の暗号鍵ヒエラルキー
○ 個別のデータキーによるユーザーデータの暗号化
○ AWS KMS マスターによるデータキーの復号化
○ キーの自動ローリング
31

セキュリティ
○ コンテナのセキュリティ
○ 脆弱性を持つコンテナに侵入され、そこを踏み台にして別のコンテナにも侵入
されてしまう。
セキュリティ重要ポイント
○ セキュリティに如何に早く気づくか。
○ 気づいた時の被害状況の確認と再発防止策
○ (コンテナは) コンテナ固有OSを利用する
32

ML/AI
○ Amazon Forecast
○ 過去の時系列データを利用し、将来のデータを予測する。
○ データセットスキーマをアップロードする
○ 5回のクリックで、アップロードしたデータでカスタムモデルを作成できる
○ AutoMLかビルトインアルゴリズムを選択
○ 実際に推論の検証を行い、精度が良ければデプロイする
○ 複数の予測モデルの結果を可視化
○ Amazon Personalize
○ Amazon ECサイトのレコメンデーションシステムと同様のものを利用可能。
下記の情報から、モデルを作成する
○ アクティビティストリーム:ユーザーの行動
○ インベントリ: 商品や記事動画などデータ
○ デモグラ情報:ユーザーの情報
AI/MLをデータを用意するだけで利用可能にまでなっている。
→ データの用意も Amazon SageMaker Ground Truth サービスがあるが… 1 アノテーション約8円。バイトを雇うコストとの
差がないかもしれない。
33

ML/AI エアークローゼット様
○ プロのスタイリストがユーザに合わせたコーディネートでファッションを家にお届け。気に入ったものだけ購入
○ ユーザから自身の写真提供いただく & コーディネイト系統アンケートに答える
○ ML/AI活用のポイント
○ ユーザ分類
○ 人と人や服と服のマッチング
○ 倉庫、場所、ショップの人員配置
○ 課題
○ データ不足
○ テストデータと教師データ
○ データ数が足りない
○ アノテーション作業
○ 人員不足
○ 作業自体の時間がかかる。
○ 提供写真原因の問題
○ ML/AI に食わせた時の推論結果に大きく影響
○ 特に明るさや照明によって肌の色が大きく変わる
34

ML/AI zozo research 様
○ SageMaker上での問題点と解決策
○ SageMakerが用意する開発環境上では開発ライブラリ等の設置柔軟性がなくなる。
→ 開発機にSageMaker SDKを導入。 SDKからSageMakerジョブを呼ぶ。
○ Jupyter notebook の ipynbファイルがgitと相性が悪い…
→ 実験条件はyamlに切り出してgit管理
○ SageMakerは途中モデル保存を行わない
→ スクリプト内にcloudwatchへの転送コードを追加した
公開ツール
https://github.com/tn1031/chainer-sagemaker-tools
35

ML/AI メルカリ様
ML/AI
○ なるべく全体をイミュータブルにして、環境の完全再現性を可能にしている
インフラ
○ クラウドインフラをk8sで抽象化してAWSとGCPの両方をコントロール
36

参加所感
○ クラウド潮流の速さ・大きさを体感
○ 1年前に宣伝されていたサービスは、すでにビジネスで積極利用されていた。
○ 2年前の先端技術は、すでに基礎的土台となっている。 (サーバーレス)
○ 2年前はクラウド紹介セッションは満員、技術セッションは割と空いていたが、今年はどの
セッションもほぼ満員。
○ 確実にクラウド技術者の数が増えている
○ SI系スポンサーの提供サービスの変化
○ 以前はクラウド移行サービスがメイン
○ 今年はクラウド運用、セキュリティサービスがメインに。
= クラウド移行が終わっていっている。
37

今後の指針
○ 業務をサービスに合わせていく。
○ 加速度的な発展が期待できるので、今できるところから積極的に形態・手続きを用意された
サービスに切り替えていく。
○ 開発スピードで同じ土俵に立てなくなる。
○ 今は労力・コストがかかっても、これは回収できる。
○ サーバ利用料見直し(低価格化)が常に行われている。
38

来年も開催
39

外部リンク
クラスメソッド様の詳細セッションレポートが上がっています。
https://dev.classmethod.jp/report/aws-summit-Tokyo-2019-day1-matome/
https://dev.classmethod.jp/report/aws-summit-tokyo-2019-day2-matome/
https://dev.classmethod.jp/report/aws-summit-tokyo-2019-day3-matome/
40

20190620 aws summit_tokyo_2019

20190620 aws summit_tokyo_2019

Recommended

Recommended

More Related Content

Similar to 20190620 aws summit_tokyo_2019

Similar to 20190620 aws summit_tokyo_2019 (20)

More from PIXELAcorporation

More from PIXELAcorporation (13)

20190620 aws summit_tokyo_2019