参加了AWS Summit Tokyo的笔记

1 年 ago

科, 颖

5 minutes

我参加了第二天和第四天。

AWS似乎强烈倡导逐步从IaaS迁移到PaaS的成长路径（包括主题演讲的嘉宾案例）。

2017年5月31日

演讲的主调

設定が複雑、費用が見積もれないというお客様向け
月額5$～、データ転送量込

クラウドジャーニー

プロジェクト
ハイブリッド
クラウドファースト
全面移行

移行

AWS Database Migration Service
Aurora MySqlは、AWS史上もっとも早く成長しているサービス
ペタバイト級のデータ移行：AWS Snowball（Eisai、レコチョク、dwangoなど、50-数百TB）

6/2～Workspacesの無料利用枠を開始
2018年にOsaka Local Regionを開設予定（特定のユーザのみ利用可能）

日本三菱UFJ銀行

API
Blockchain（次世代決済ネットワーク、リアルタイム送金、コイン）
AI（７年後に本部の業務は4割 AIで置き換えられる）
デジタルアクセラレータ、ハッカソン

MUFGクラウド活用全体像（6 Initiatives）

ガバナンス：ポリシー＆ガイドで緩やかに
サービス企画
設計・アーキテクチャ
運用保守：課金のコントロールなど
人材開発
移行：移行基準の策定

精工爱普生 ài pǔ

移行のしやすさ、クラウド利用抵抗感の排除を訴求して成果を出すことを優先
費用が20%削減
サーバ環境構築期間を2-3ヵ月から1週間以内に短縮

将 Recochoku 全面转移到 AWS。

Operations：DBAを開発チームに入れて、チューニングはチーム内で対応
Availability：許容ダウンタイムを定義して業務／システム調整

VRが配信できる環境

配信方式（ストリーミングだと厳しい）
端末負荷（熱暴走）
画質・音質
スマホ向けVR映像配信＋ VRライブ映像

山山（八）。

150万人が、年間1億枚の名刺を登録（日本での名刺交換の10%）

企业云旅程的最新趋势

プロジェクト
ハイブリッド
大規模
クラウドファースト

2017年：クラウドジャーニーの２つの道

初期プロジェクト
ベース作り
移行（技術的負債の返済）
再創造（クラウド・ネイティブ）

クラウド活用のギャップ（施策のポイント）

アジャイル開発+DevOps
分析と可視化（システム監視を含む）
既存システムとの接続
ガバナンス・セキュリティ

分析と可視化

DWH製品は非常に高価だった。クラウドのストレージサービスにより、古いデータを捨てたり、データを間引かなくても良くなった
DataLake（S3）に対して、Redshiftから直接sqlを発行できるようになった
Streaming <-> バッチ

既存システムとの接続

更新系はAPIまたは非同期メッセージング
参照系はクラウド側にデータをコピーしておくことで（DBレプリケーション）、既存アプリに影響を与えない

ガバナンス・セキュリティ

フロントの共通セキュリティVPC経由でのアクセスとする（ファイアウォール、IDS/IPS、WAF、ログ取得、通信暗号化など）

専門組織

シャドーIT、従来のIT部門とは別の専門組織を立ち上げ

IT部門の役割

デジタルトランスフォーメーションの支援と対応：全体IT方針の策定、役割分担の整理、環境整備
技術的負債の返却（自社の差異化につながるところ以外の整理）：DCメンテナンス、H/Wリプレース、VM環境運用、インベントリー管理など

技術的負債の返済

Mode1.5：基幹系でも改修していくもの、季節性などでキャパシティ変動のあるもの ⇒ クラウドに移していく
Mode2からMode1へアクセスするインタフェース（API・データ連携・データ配置）
単純以降でも、H/Wリプレースはなくなる。マネジドサービスに乗せることで、パッチ適用がなくなる。

【理光】绝对不能全面停止服务。努力提升可用性，追求无间断的电视会议系统，充分利用AWS的秘策。

瑞科优克斯 (Ruì kē kè sī)

2011/8- 自社インフラで運用
2016/6- AWSへ移行（最初はDR用、12月からメインをAWSに）
2017/6- 完全移行完了

インフラを含めた品質保証

インフラは壊れる前提で考える

可用性の向上

アプリケーション障害
サーバ障害
データセンター障害
リージョン障害：バージニアのS3障害
全リージョン障害（IaaS事業者障害）：2016年GCPがネットワーク接続を失った
まずはデータセンター障害までは、起きても大丈夫なことを目指してきた

可用性向上のために

IaaSの障害を想定した設計（Design for failure）
障害検知を早くする、自動的に復旧させる
デプロイのダウンタイムゼロ

转型政策

データセンター間で、DB間／API間のやり取りをする

进行过渡

Dockerさえあれば動く、言語バージョンを気にしなくてよい、ECSの安心感
運用実績は作っていくしかない、対応コストは初期投資はかかるがその後の運用が楽

ELB + EC2 + ECS + WCR

ECRがDevとOpsのI/Fになる、開発者はDockerイメージをpushするだけでデプロイ可能
+AutoScaling + cfn-init
ELBをECS側につけることで、壊れたコンテナには振り分けられなくなる

RDS(MySQL)を利用

Multi-AZ構成
クロスリージョンのレプリカのMulti-AZができない制約があった

マネジドサービス⇒サーバレス化

ELB + EC2 + RDS
API Gateway + Lambda + Dynamo

コアな部分は、AWSのマネジドな仕組みに乗らないことが多い

映像配信サーバは、単純なヘルスチェックだけでは不十分で、複雑なシーケンスで会議をしてみないと分からない
AutoScallingとも相性が悪い（つながっている端末がある限りは、映像配信ルーターを減らすことができない）
テレビ会議レベルでの監視を世界中のRegionから1分に1回監視した（利用できない系統は、切り離し）

RDS MySQL -> Auroraに変更（高速フェイルオーバー）
全ては検知を早く、1秒でも復帰を早く

自动化

Dev/Stage: 必要な時にあればよいので、自動化が特に役に立つ
Beta/Production: 常時稼働

Infrastructure as a Code

Cloudformation(Kumogata)を利用（Kumogataの利用で、60Kが16Kに）
環境名とバージョンだけ渡せば起動するようにしている、前のバージョンを作り直すこともできる（壊れても作り直せば元通りになる）
Dev環境は営業時間内のみ自動起動／削除（20:00には強制シャットダウンで帰るしかない、毎日構築されるのでバグトラッキングがしやすい）
職人芸がコードになった

Blue-Greenデプロイメント

In Placeはしない、Red/Blackのように一斉アップデートもしない
Cloudformationの構築／更新のみで実現
Swap ECS services with ELB方式を採用（もしくはSwap Auto Scaling Group）
ただし、一から構築するのでデプロイに時間がかかる

通过使用AWS运营的经验明白了以下事实

Pingdom
CloudWatch
Zabbix
VCMon（独自会議監視）
電話／メール／Slackで通知

インフラで何かがおきてもほとんど自動復旧
アラームにおびえる（新しいアラームが鳴るので、癖／パターンを掴むまではビクビクする）
AWSのネットワーク品質低下問題

外部／内部ネットワークで疎通できない時間帯があった

可用性のボトルネックが変わってきた

IaaS障害 = 大規模障害から、小規模障害に目が向くように
アプリケーション側の工夫が余儀なくされるケースが出てきた ⇒ もはやインフラとアプリケーションの境目はない

NTTドコモ对于持续进行数字化以及AI的未来思考。

強いAI Symbol Grounding（記号設置問題）：ろうそくを壁に取り付けてください
今のコンピュータ（地道なAPI）：多様な発話例を収集 ⇒ 学習 ⇒ タスク識別
ちゃんとデータを整備して、枯れた技術をちゃんと使う

IoT

ICT + OT(Operational Technologh:各業界のドメイン技術)
IoT + AI = これまでコンピュータとは無縁だった産業の自動化・自律最適化
GEは、縦串でICTを切って、横軸にOTを切っている
非ICT産業のICT化、クラウドによってユーザ企業が自分たちでできることが増える、ユーザ企業同士が直接話をする

2005: Data is the Next Intel Inside

人々とデータ：トランザクションデータの解析、サブトランザクショナル（Webアクセス解析など）
オンプレGreen Plum -> RedShift
docomo cloud package: 100社以上にライセンス（ユーザ企業がもっているノウハウを形式知化）

Data analysis Platform

Hot data: RDS / ElasticCache / Dynamo
Warm data: RedShift
Cold data: S3 / Glacier

AIタクシー

500mメッシュごとのタクシー乗車台数を10分ごとに予測（東京無線＋富士通＋docomo）

クラウドは市民革命、機械学習は産業革命

public cloudベンダーは両方を一斉に達成しようとしている

支持ChatWork新的消息系统的技术

猎鹰 (Liè

総コード量30万行以上、中心的なクラスは1万行以上
ライブマイグレーションプランを選択：お互いに起こったイベントを共有、DynamoDBに両方で書き込み
1年半ほど開発を続けたが、Dynamoのセカンダリインデックス使い過ぎ、ID採番などで課題が発生
根本的に新アーキテクチャに以降、１年間の開発期間を経て、大規模なデータ移行をして2016年末に無事リリース

新アーキテクチャの方針

メッセージ数の遷移が、指数関数的に急増（5億⇒10億⇒20億）
DDD + Akkaは維持
現行システムの2倍以上の性能、自己回復力
CQRS + ESを採用
システム規模とコストの相関が線形未満
PoCを必須とする、クネビンフレームワークの複雑な課題への対応

CQRS + Event Sourcing

Wirte側のstackにのみドメインモデルは現れる（Read/Write）
Read stackは、GUIに合わせたリードモデルを返す
発生するドメインイベントのすべてを永続化して、リプレイによって状態を再現（Akkaの機能でスナップショットも保持）
rock lessでスケールしやすい
Write API（Cassandraに書き込む⇒Kafka） / Read Model Updater（Auroraに構築⇒HBASE） / Read API

アプリケーションアーキテクチャ

ヘキサゴナルアーキテクチャ（DIPを適用したレイヤ化アーキテクチャ）

障害に強いアクター

Error kernel pattern：スーパービジョンヒエラルキー：危険な作業を末端に移譲、ルート近くに重要なアプリケーション状態や機能を維持
Let it crash pattern：スーパーバイザに障害への対応は委任し、システムの一部を再起動して復旧 ⇒ 障害モデルを簡素化
階層構造を持つ、特にIOを司るようなアクターはヒエラルキーの下層に配置

DevOps: DevOps

デファクト＆production readyな機能が豊富
Helmというパッケージングシステム
ローカル開発環境minikube
インフラチームはKubernetes運用（＋Fluentdログ収集、Datadogメトリクス収集）に専念、開発チームはAPIを使う

CIサーバをConsource CIに

pipelineが一般市民（Resource -> Task -> Resource）
yamlで定義
Dependable Results(Reproducible)：パイプラインはステートレス、Taskの実行環境がコンテナで分離（CIサーバにpluginが不要）
CIサーバの運用が非常に楽になった：pluginの構成管理が不要、Databaseの保存データはパイプライン定義やビルド履歴のみ
productionへのデプロイ：公式ではBOSHが推奨
ローカル開発したパイプラインがそのまま本番にデプロイできる（concourse(vagrant) + minikube）
Gitlab flow with Environment Branches

負荷テストツールの自動化

コマンドを叩くだけで負荷試験を実行できるように
ECS + Gatlingを使った負荷テスト自動化ツールの導入
負荷シナリオがコンテナ化されて、負荷実行まで自動化
ECSクラスタ＋ログ出力用S3バケット＆ECSタスクのCloudFormation⇒負荷実行⇒S3のログからレポート作成・閲覧

Sansan 使用 C# 在 Windows 上通过消息队列 (Amazon SQS) 实现了可扩展性的故事。

整体的形象

マルチテナント型：DBテーブルにtenant_idを持っている

发消息

5,000 * 5,000 = 25,000,000のレコード -> メッセージングを導入
fromの１ユーザごとにトランザクションを分ける、並列処理によりスループットが向上
WebServer -> SQS -> Consumer(message分割) -> SQS -> 並列処理 -> DB
SQSに詰めた時点で、ユーザにレスポンスを返して「処理中」画面を表示

終わらないバッチ処理

バッチウィンドウを一日中に
Domain Event: 後続処理は知らない、後続処理（複数）はEvent Aggregatorをsubscribe
Publisher -> SNS Topic -> SQS Subscriber Qeue(複数) -> Subscriber並列処理

急激に変化するデータベース負荷

ピークの処理を後回しにできれば、負荷が安定（即時性が求められなければ）
SQSのConsumerの並列度の制御により負荷を均す：インスタンス並列度／スレッド並列度（SemaphoreSlim）

低いメンテナンス自由度

メンテナンス中はConsumerを止めることで、APIは平常運転していてqueueに溜める

リカバリ不可能な処理

リトライは標準装備、処理内容がテキストで表現されているので必ずリカバリ可能

聊天软件的注意事项

FIFO Queueは、遅い（秒間300）、Tokyoに来ていない

順序は保証されない
結果整合性モデルになることが多い

Gunosy 在 AWS 上如何应用自然语言处理和机器学习的案例

記事分類（カテゴリ推定） ⇒ 同一イベント判定 ⇒ 代表記事選択 ⇒ スコアリング（ユーザ属性ごとのCTR予測して並び替え）
ユーザー行動ログ ⇒ ユーザー属性推定（行動ログから属性推定）
評価：配信アルゴリズムの効果を測定（同一イベント判定の粒度：メジャーリーグ全体で一記事？）

将以下内容以中文本地化改述，只需提供一个选项：

分类文章

分類した記事をRDBに格納して、後続処理で利用（スコアリングなど）

属性推定 + 评分

男性はスポーツ記事をクリックしやすい、特に野球、フィギュアスケートは両方
有名人の結婚・出産などのライフイベントは女性の方がクリックしやすい
アーティストのニュースは年齢差、スポーツチーム・事件・イベントは地域

属性の知り方

ユーザに聞く⇒入力ストレスで離脱、全ユーザが入力してくれるわけではない
ユーザが読んだ記事情報をもとに属性を推定

ユーザのクリックログから年齢推定（ユーザごとのクリック有無を、次元縮減した上で濃淡をつけて画像化）

IN（ユーザの行動ログ）/OUT（推定結果）はS3に置いている
S3アクションログとRDSを突き合せて、可視化
行動ログをAmazon Stream Analyticsで属性情報をjoin、firehorseを介してElasticsearch Serviceに格納

評價

ユーザの満足度を最適化したい（「視聴率」のような一つの指標では見られない）
測定が難しい、記事の質や季節要因などの影響を受ける

A/Bテストのメリット

時間変化などのノイズが入りにくい
最適化すべきメトリクス（例：クリック率＆滞在時間）が決まっていれば、単純なクロス集計になる

記事リストをDynamoDBに格納、アルゴリズムごとにkeyを分けている、ユーザIDごとにA/Bテストに割り当てる

割り当たったkeyを行動ログにすべて付与
slack/redash/Jupyter notebookなどで集計（いろいろな人でテストの結果を見て、分析方法に誤りがないかをチェック）

2017年6月2日

主题演讲 (zhǔ tí

茂木健一郎 Mù Yī

人の脳の情報処理量は1秒あたり128kb、一度に複数のことに集中できない
囲碁・将棋：人工知能なら１ヵ月でできることを、人間は一生かけてやっている
人は脳の中に構築したモデルを他の人と共有できない

認知システムについてのアプローチ

計算モデルに当てはめるアプローチ
生態学的アプローチ（ギブソン：情報は環境の中にある）、アフォーダンス ⇒ これからはこちらが重要

今のamazon echoのskills

まだ人の指示待ち（人間に合わせすぎ）
ずっと人の音声をモニターしていてログが取られているという可能性がある（人は何年も前の会話を記憶していられない）
発想を変えないとポテンシャルを生かせない、革新がない

もはや人間の脳とか、チューリングテストとか考えていてもしょうがない（人間に合わせる必要はない）

映画herの複数人と同時に会話して、恋をする人工知能
感情やパーソナリティはまだ数理モデルがないので、人工知能にインプリできない
パントマイムは人間には難しいが、ロボットには簡単（人間が進化してきたドライブフォースと、人工知能の方向性は違う）

今のシステムは人間のattentionを要求しすぎる

例：SNS、メール
Six Sensesのリゾートホテルでは、no news no shoes、自然の中でリラックスする
フリン効果：処理する情報量が増えたことで、人間の平均IQは上昇し続けている
それで人間は幸せになっているのか、今の人間とITとの関わり方は持続可能なのか
自動運転：人間の注意を常に要求するものではなくなりつつある

子どもはルーティーンがない

大人が生きるために必要なルーティーンをやってくれている（安全基地）
子どもたちがずっと遊んでいるように、人間の創造性／遊びを開放するようなシステムであってほしい
アメリカの自由さ、シカゴに教授がおらず学生のコミュニティだけの大学がある

急驶

プレスリリース：先にプレスリリースを書いてから（顧客体験）開発を始める
2 pizza team：10人くらいの規模であれば、全員のアイデアの種を引き出すことができる

IoTでユーザインタフェースが変わっていく

クリック、タップ、スワイプ ⇒ トーク、プッシュ、タッチ
アプリ ⇒ スキル／ボット
API呼び出し ⇒ イベント

「優れた」モノのインターネット

顧客から声を聴き、学ぶ企業
使うごとによくなるスマートな製品
お客さまの信頼を守るセキュアなデバイス
毎日の活動がより簡単になる
IoT到来前にはできなかったことを可能にする

amazon DRS -> ゼロクリック

Dash Replenishment Service
足らないということも、買いすぎるということもなくなる

単なるガジェットではなく、「役立つ」モノのインターネットの力を活用する製品を創る

亚历克莎 -kè-shā)

alexa skills kit（ASK）

亚马逊机器人

在庫（棚）が人の方にやってくる（Pod）

亚马逊红移生态系统

コスト（初期費用なし、従量課金）：1TBあたり$1,000/year
パフォーマンス（nodeを足せばいい）：最大128ノードスケールアウト可能
アジリティー（ハードウェアの調達なしで、ユーザがすぐに変えられる）

红移综述

OLTP向けRDBMS：遅い
DWHアプリアイアンス：高い
列志向型データベース（ソフトウェア）
Redshift：フルマネジド、列志向＆MPP

一般的な構成

保存：S3に構造化データを保存
Redshiftで分析
BIツールで可視化

IO削減

列志向型（カラムナ）；フルスキャンせずに集計
圧縮、ゾーンマップ（1MBのブロックごとの最大値／最小値をメモリに持つ）

红移生态系统

多様なデータを一元的に保存⇒S3
S3上のデータをRedshiftにロードすることなく外部表として使いたい ⇒ Redshift Spectrum（クエリ課金）
例：hot dataはRedshift、週に１回／月に１回しかアクセスしないデータはS3に
Partitionも作成できる

負荷分散

RDS(Postgres)をを前面配置して、分析済データをdblinkで定期的にMV反映（もしくはRDS側にInsertしてしまう）
LambdaでMVを更新する
pgbouncer-rrでテーブルごとに振り分ける

移行

S3をDataLakeとして使い、スモールスタートでPoC

AWS的多账户管理方法和最佳实践

ワークロードや環境、組織でアカウントを分割

AWS账户分割的原因

管理コンソールを分離、権限の分離、セキュリティ対策の分離 ⇔ 複数アカウントのまたがる監査情報種等の効率化が必要

課金

LOBごとに課金を明確に分けたい
課金やチャージバックをシンプルに
各アカウントの課金レポートに対するアクセス管理、レポート集約、ボリュームディスカウントのコンソリデーション

組織

LOBごとの管理
共通サービスのようなアカウントをまたいで利用できる機能を重複して構築することへの検討が必要

運用

構成変更時の影響局所化、リソース上限
オンプレ ⇔ AWS、AWS間のネットワーク接続の複雑性・コストが増す

AWS多账号管理功能

IAMロールによる、クロスアカウントアクセス
Switch RoleによるAWSアカウントの切替
JumpアカウントにIAMユーザを作って、クロスアカウントで各環境にアクセス

課金管理

一括請求機能（Consolidated Billing）
支払アカウントで連結
コスト配分タグ、アカウントをまたがってもコスト配分タグで集計

セキュリティ・ログ管理

セキュリティオペレーション用アカウント
CloudTrail, AWS Configのログを集約する

マルチアカウントの統制

AWS Organization
組織コントロールポリシー
マスターアカウントからのみ新規アカウントを作成（Organizationに自動で入る、既存のアカウントの招待も可能）
OUでツリー後続を作り、ポリシーを割り当てていく（上位のポリシーは継承される）

サービスコントールポリシー（SCP）

どのAWSサービスのAPIにアクセス可能かをコントロール（ホワイトリスト、ブラックリスト）
SCPとIAMの権限が両方あるものにアクセス可能
例：絶対に利用しないサービスを明確にしてブラックリスト化する

最佳实践

多くのアカウントを集中管理する場合は、AWS Organizationを利用

【日本经济新闻社】创造”AI记者”之父~挑战”技术媒体”

デジタル事業のNIKEI AI：決算サマリー、日経DeepOcean（例：日経平均と連動している銘柄、原子力関連の銘柄）

财务摘要

6787サマリー（1/25-5/26）
サービス公開まで1-2分、決算ピーク（300開示/分）も2分

記者一人につき50-70社を担当し、年4回の決算発表と定型原稿（速報を書けているのは注目度の高い企業のみ） ⇒ ロングテール
インプットとアウトプットが決まっているのでやりやすい

利益・売上高など業績に関する文章 -> XBRLの数値を抜いてテンプレートはめ込み（難易度低）
その業績の要因を述べた文章（業績要因文） -> こちらが大変

処理フロー

PDF解析（全体業績、事業セグメント）
格構造解析（形態素解析、格構造解析）
ネガポジ分析（原因と結果の文章ペアを発見する、ネガティブ・ポジティブ分を分析する）
要因文の分類、文の選択（日経の基準：全体業績概要、利益の大きい事業セグメントを優先）、整形・生成
取らない文章を学習させる：他の数値変動が理由（「減収により」）、一般的・定常的な活動（「地道な営業努力」）、客観的事実でない記述（「経営全般にわたり徹底した効率化」）

決算ピークに対応

年に４回、5月のGW明けが最大のピーク
S3バケット経由でオンプレと連携
AWSでautoscaleを利用、アプリが2GB以上メモリを使うのでlambdaではなくEC2上で動かしている
記事生成自体は十秒程度

課題

流暢さ（チューニングの問題、要点を取ってくる）
創造性（記者のように仮説を立てて企業に裏取りをするとかはできない）
一方、「数字を見間違える」ことがない正確性がある

現場の温度感

仕事をとられるという意識はない
Aiの取り組みに好意的、サポートとしての期待が大きい
上場企業3,600社のカバレッジは機械で、情報の深さは人間が担う ⇒ 深い情報 = 価値の高い情報を増やしていく（付加価値の高い業務に集中）

AI記者を通して

実ビジネス応用へのハードル：精度が悪い／運用が難しい、データ品質／データ量／モデルどれの問題？、自社独自のカスタマイズ（AIの知識 x 業務知識）
導入後の業務設計

【ワークスアプリケーションズ】通过 AWS Lambda 改变批处理的世界〜如何在 10 分钟内完成总共 100 小时的 CPU 时间处理〜

处理对象

HTML, js, cssの最適化、HTMLテンプレートの事前コンパイル
9,000画面弱

Sparkで２時間、インスタンス数最適化作業が終わらない

引入lambda

スケーリング管理コスト、インスタンス管理コストがかからない（勝手にやってくれる）
100ms単位の課金

検討課題

処理フローの整理
処理時間上限5min、メモリ上限1.5GB
出荷、運用

preheat

画面のリスト作成、HTML最適化、JS/CSSがある画面の場合はコンパイル

処理の分割：それぞれのStepを役割ごとに気って分割、Dispatcher / Skelton / JS/ Less
Dispatcher

Before:RuntimeでJava classから情報収集
After:Jar作成時に情報収集、

JS Compile

Before: SpringFW上でGoogleClosureCompilerを動かしていた（あえて作りこんでいた）
After: GoogleClosureCompiler単体で動かす

Less Compile

Before: Java & SpringFW上で動作
After: Node.jsランタイム上で、純正Node.jsコンパイラを利用

SpringFW利用の工夫

初期化コスト:10-30sec
コンストラクタで節約：コンストラクタは課金対象外（timeout時間は短い＆timeoutすると課金対象）

AWS Lambda Functionのライフサイクル

コールドスタート。コンテナ（≒JVM）の一定時間待機
singletonでContextを用意し、nullの場合のみnewする

处理流程

前のfunctionがPendingフォルダに入れる、functionの開始時と終了時のフォルダを動かす
S3のObjectをListで取得して進捗状況を監視

故障排除示例

メモリ上限UP! 1.5GBだと2コア利用可能

上限変更後、並列数が伸びない（3,000まで上限を上げたが、1,000くらいまでしか伸びない）

VPCの設定を確認（subnet）

起動直後にエラー

S3への大量Put &　結果整合性なので注意が必要

DBの負荷が上がってエラーになるケースが発生（Cassandraのコネクション）

[Sansan] AWS 支持的Eight推荐引擎的幕后运作

在”Eight”中的推荐

誰が誰に何をしたかかをRedshiftに入れて、バッチ処理で更新、CloudSearchでソートしてユーザに提示
CloudSearchの更新までのレイテンシー

刷新推荐架构

データ分析
アルゴリズム
リアルタイムフィードバック（ユーザがアクティビティを起こしてから、レコメンドに反映されるまでのリードタイム）-
直近の出会いを大事に、データの鮮度がよいほどリクエスト承認しやすくなる

生ログを加工して、「誰が誰に」を中間データとして保持

中間データ更新にKinesis + Lambdaを利用
DynamoDBをストレージに（レイティングデータ）
シャード数／キャパシティを上げることでスケール

２か月で刷新

Dynamoに中間データができると、ElasticCacheにレコメンドデータをキャッシュ
SQSにメッセージ、batchサーバが拾ってDynamoにレコメンド結果を保存、lambdaが表示順を決定して、ElasticCacheに投入

性能問題

1分間のアクティビティが1時間たっても処理できなかった
Kinesis Put Recordsでrクエストをまとめる
Lambdaはリソースを増やす
Batch writeでまとめて書き込む（lambdaのbatch size）

オペレーションコスト

処理の単純化（1Functionをシンプルに） ⇔ Funcions数の増加（管理しきれない）
ReadProvisionedThrouputExceededが発生しやすくなる ⇒ 1 stream / 1 function
ただし管理やstreamコストの問題があるため、バランスを取る
異なるstreamから同じような処理をさせたいケース ⇒ lambdaをまとめて内部でstreamを判別して処理を分岐 ⇒ lambda数を削減
パラメタにより処理を分離（１つのstreamをlambdaで分身させる）

更新推荐数据

Reshift -> S3(総Item数 5,000万超) -> DynamoDB

lambda停止 -> データ再作成 -> cacheウォームアップ -> lambda再開
DataPipeline on Step Functions

DataPipelineの状態管理：DynamoDBにDataPipelineの完了状態を持たせ、終了時にSNS経由で起動するlambdaでDynamoを更新、Step2で完了待ちする
LambdaのTimeout：完了していない場合はエラー扱いとし、定間隔でリトライ（Step Functionsの機能）
Cacheのウォームアップ：DynamoDBにkeyを書き込み、Dynamo Streamnをlambdaが受けて、本体のDynamoからデータを取ってcacheを更新

为无服务器应用程序构建 CI/CD 管道。

サーバレスアプリに最適化されたAWS CloudFormationの拡張
既存のファンクションをSAMテンプレートとしてエクスポート可能

SAMで指定できるサーバレスリソース

Lambda / API Gateway / DynamoDB
XRay連携も本日発表された
cloudformationにpackage / deployが追加された
SAM templateのyaml -> packageするとCloudformation用のyamlに変換される

SAM 和 AWS Code 相关服务的集成

Piplineの中にステージ（Buildなど）、ステージの中にアクション（並列アクション／逐次アクションが定義できる）
ソースはいったんS3にダウンロード、各ステージの成果物もS3で管理する

CodeCommit: 5/27 Tokyo region launch
CodeBuild: Dockerベース
source / build / staging(cloudformationへの反映) / deploy（cloudformationのexecuteChangeSet）

buildspec.yml（Codebuildの設定ファイル）: 拡張子に注意、rootに配置が必要

CodePipelineの実行状況はCloudWatchに一元化される
外部ライブラリを利用するケースは、buildspec.ymlの設定によりCodeBuildの中でpip installを叩く設定ができる（リポジトリ側にライブラリを入れなくともよい）
承認フローを追加

Approveというタスクを追加し、SNSのエンドポイントを指定 ⇒ 承認チェックが足される

AWS CodeStar

ガイドに従うと、一式のワークフローが生成される

Step Functions

lambdaを分割し、前処理の戻り値判定で後続lambdaを切り替える

環境変数から接続情報、logレベルを変更できるようにする
6/9にAWS Lambdaの本が出ます