AWS Summit Tokyo参加メモ

２日目と４日目に参加した。

AWSとしては、まずはIaaSでそのままクラウド移行、その後でPaaSに移行していくというパスを、わりと推している印象を受けた（基調講演のゲストの事例を含め）。

2017/05/31

基調講演

• 日本準拠法を選択可、通貨選択、コンソールの日本語化（６月までに）
• Amazon Lightsail(VPS)を5/31から東京Regionで利用可能に
  • 設定が複雑、費用が見積もれないというお客様向け
  • 月額5$～、データ転送量込
• クラウドジャーニー
  • プロジェクト
  • ハイブリッド
  • クラウドファースト
  • 全面移行
• 移行
  • AWS Database Migration Service
  • Aurora MySqlは、AWS史上もっとも早く成長しているサービス
  • ペタバイト級のデータ移行：AWS Snowball（Eisai、レコチョク、dwangoなど、50-数百TB）
• 6/2～Workspacesの無料利用枠を開始
• 2018年にOsaka Local Regionを開設予定（特定のユーザのみ利用可能）

MUFG

• MUFGオープンイノベーション
  • API
  • Blockchain（次世代決済ネットワーク、リアルタイム送金、コイン）
  • AI（７年後に本部の業務は4割 AIで置き換えられる）
  • デジタルアクセラレータ、ハッカソン
• MUFGクラウド活用全体像（6 Initiatives）
  • ガバナンス：ポリシー＆ガイドで緩やかに
  • サービス企画
  • 設計・アーキテクチャ
  • 運用保守：課金のコントロールなど
  • 人材開発
  • 移行：移行基準の策定

セイコーエプソン

• ITトランスフォーメーション（クラウド移行：EC2/RDS）⇒デジタルイノベーション（サーバレスアーキテクチャ採用）
  • 移行のしやすさ、クラウド利用抵抗感の排除を訴求して成果を出すことを優先
  • 費用が20%削減
  • サーバ環境構築期間を2-3ヵ月から1週間以内に短縮

レコチョク AWS全面移行

• Oracle RACからAuroraへ
  • Operations：DBAを開発チームに入れて、チューニングはチーム内で対応
  • Availability：許容ダウンタイムを定義して業務／システム調整
• VRが配信できる環境
  • 配信方式（ストリーミングだと厳しい）
  • 端末負荷（熱暴走）
  • 画質・音質
  • スマホ向けVR映像配信 ＋ VRライブ映像

Sansan(Eight)

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

エンタープライズ・クラウドジャーニーの最新動向

• 2016年：SofA
  • プロジェクト
  • ハイブリッド
  • 大規模
  • クラウドファースト
• 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 を最大限活用して可用性を高める秘策〜

Richo Ucs

• AWS移行
  • 2011/8- 自社インフラで運用
  • 2016/6- AWSへ移行（最初はDR用、12月からメインをAWSに）
  • 2017/6- 完全移行完了
• インフラを含めた品質保証
  • インフラは壊れる前提で考える
• 可用性の向上
  • アプリケーション障害
  • サーバ障害
  • データセンター障害
  • リージョン障害：バージニアのS3障害
  • 全リージョン障害（IaaS事業者障害）：2016年GCPがネットワーク接続を失った
  • まずはデータセンター障害までは、起きても大丈夫なことを目指してきた
• 可用性向上のために
  • IaaSの障害を想定した設計（Design for failure）
  • 障害検知を早くする、自動的に復旧させる
  • デプロイのダウンタイムゼロ

移行ポリシー

• 基本的に同じ構成で移行（ただしコンテナ技術を採用、マネジドサービスを積極採用、移行後に最適化）
• インフラ構築を徹底的に自動化
• サービスの特徴：接続する相手によって使うデータセンター（映像配信サーバ）が変わる、物理的なレイテンシーを縮めるため
  • データセンター間で、DB間／API間のやり取りをする

移行

• 各種WebAPI化、Appのコンテナ化
  • 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
  • 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障害 = 大規模障害から、小規模障害に目が向くように
  • アプリケーション側の工夫が余儀なくされるケースが出てきた ⇒ もはやインフラとアプリケーションの境目はない

ドコモが考える地道なデジタル化とその先にある AI

• IT
  • 強い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 の新メッセージングシステムを支える技術

Falcon

• Falconのプロジェクト推移
  • 総コード量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

• 負荷試験を取ったアプリコードを維持、チームだけで好きなタイミングでリリース、アラート対応：開発チームで対応
• 実行環境をKubernetes
  • デファクト＆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 がメッセージング (Amazon SQS) でスケーラビリティを手に入れた話: using C# on Windows

全体像

• 専用Scannerで名刺をScan -> Web API Call(jpeg) -> Digitization Serviceにjpegを投げると、Callback APIでtextが返ってくる
• マルチテナント型：DBテーブルにtenant_idを持っている

メッセージング

• メッセージは単なるテキスト
• 処理失敗したメッセージはリトライされる、一定回数失敗し続けたメッセージは別キューに退避（Dead Letter Queue）
• AWS SQS(Standard/FIFO), Azure Storage, Azure Service Bus, MSMQ
• 巨大なトランザクション：権限設定レコードの洗い替え処理（ユーザ単位で、所有名刺の参照・更新可否を設定）
  • 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 上での自然言語処理・機械学習の活用事例

• ニュースパス（2016/6にKDDIと共同でリリース）のユーザ行動解析、記事配信アルゴリズム構築（10名）
• web上の様々な情報（ニュース記事、ECサイトの商品サイト、動画）を独自のアルゴリズムで、収集＆評価づけ＆配信
• 推定したユーザの属性、コンテンツ評価でマッチング精度を向上
• 一日数千本の記事が入稿される ⇒ カテゴリ分類／同一イベント判定／ユーザ属性／リアルタイム記事評価 ⇒ リスト作成
  • 記事分類（カテゴリ推定） ⇒ 同一イベント判定 ⇒ 代表記事選択 ⇒ スコアリング（ユーザ属性ごとのCTR予測して並び替え）
  • ユーザー行動ログ ⇒ ユーザー属性推定（行動ログから属性推定）
  • 評価：配信アルゴリズムの効果を測定（同一イベント判定の粒度：メジャーリーグ全体で一記事？）

記事分類

• 教師あり多クラス分類問題（教師データは、クラウドソーシングで集めている）
• 辞書を使って形態素解析して名刺を抽出、ベクトル化して、カテゴリ分類器にかけて分類
• Trained ModelはS3に保存、deploy時に取得
• 分類した記事をRDBに格納して、後続処理で利用（スコアリングなど）

属性推定 + スコアリング

• 少ないステップで自分が読みたい記事にあたるのがいい状態と定義
  • 男性はスポーツ記事をクリックしやすい、特に野球、フィギュアスケートは両方
  • 有名人の結婚・出産などのライフイベントは女性の方がクリックしやすい
  • アーティストのニュースは年齢差、スポーツチーム・事件・イベントは地域
• 属性の知り方
  • ユーザに聞く⇒入力ストレスで離脱、全ユーザが入力してくれるわけではない
  • ユーザが読んだ記事情報をもとに属性を推定
• ユーザのクリックログから年齢推定（ユーザごとのクリック有無を、次元縮減した上で濃淡をつけて画像化）
  • IN（ユーザの行動ログ）/OUT（推定結果）はS3に置いている
  • S3アクションログとRDSを突き合せて、可視化
  • 行動ログをAmazon Stream Analyticsで属性情報をjoin、firehorseを介してElasticsearch Serviceに格納

評価

• A/Bテスト
  • ユーザの満足度を最適化したい（「視聴率」のような一つの指標では見られない）
  • 測定が難しい、記事の質や季節要因などの影響を受ける
• A/Bテストのメリット
  • 時間変化などのノイズが入りにくい
  • 最適化すべきメトリクス（例：クリック率＆滞在時間）が決まっていれば、単純なクロス集計になる
• 記事リストをDynamoDBに格納、アルゴリズムごとにkeyを分けている、ユーザIDごとにA/Bテストに割り当てる
  • 割り当たったkeyを行動ログにすべて付与
  • slack/redash/Jupyter notebookなどで集計（いろいろな人でテストの結果を見て、分析方法に誤りがないかをチェック）

2017/06/02

基調講演

茂木健一郎

• シンギュラリティはもう起こっている
  • 人の脳の情報処理量は1秒あたり128kb、一度に複数のことに集中できない
  • 囲碁・将棋：人工知能なら１ヵ月でできることを、人間は一生かけてやっている
  • 人は脳の中に構築したモデルを他の人と共有できない
• 認知システムについてのアプローチ
  • 計算モデルに当てはめるアプローチ
  • 生態学的アプローチ（ギブソン：情報は環境の中にある）、アフォーダンス ⇒ これからはこちらが重要
• 今のamazon echoのskills
  • まだ人の指示待ち（人間に合わせすぎ）
  • ずっと人の音声をモニターしていてログが取られているという可能性がある（人は何年も前の会話を記憶していられない）
  • 発想を変えないとポテンシャルを生かせない、革新がない
• もはや人間の脳とか、チューリングテストとか考えていてもしょうがない（人間に合わせる必要はない）
  • 映画herの複数人と同時に会話して、恋をする人工知能
  • 感情やパーソナリティはまだ数理モデルがないので、人工知能にインプリできない
  • パントマイムは人間には難しいが、ロボットには簡単（人間が進化してきたドライブフォースと、人工知能の方向性は違う）
• 今のシステムは人間のattentionを要求しすぎる
  • 例：SNS、メール
  • Six Sensesのリゾートホテルでは、no news no shoes、自然の中でリラックスする
  • フリン効果：処理する情報量が増えたことで、人間の平均IQは上昇し続けている
  • それで人間は幸せになっているのか、今の人間とITとの関わり方は持続可能なのか
  • 自動運転：人間の注意を常に要求するものではなくなりつつある
• 子どもはルーティーンがない
  • 大人が生きるために必要なルーティーンをやってくれている（安全基地）
  • 子どもたちがずっと遊んでいるように、人間の創造性／遊びを開放するようなシステムであってほしい
  • アメリカの自由さ、シカゴに教授がおらず学生のコミュニティだけの大学がある

Dash

• イノベーション：社員のアイデアからサービスを実現するための仕組みが、会社に組み込まれている
  • プレスリリース：先にプレスリリースを書いてから（顧客体験）開発を始める
  • 2 pizza team：10人くらいの規模であれば、全員のアイデアの種を引き出すことができる
• IoTでユーザインタフェースが変わっていく
  • クリック、タップ、スワイプ ⇒ トーク、プッシュ、タッチ
  • アプリ ⇒ スキル／ボット
  • API呼び出し ⇒ イベント
• 「優れた」モノのインターネット
  • 顧客から声を聴き、学ぶ企業
  • 使うごとによくなるスマートな製品
  • お客さまの信頼を守るセキュアなデバイス
  • 毎日の活動がより簡単になる
  • IoT到来前にはできなかったことを可能にする
• amazon DRS -> ゼロクリック
  • Dash Replenishment Service
  • 足らないということも、買いすぎるということもなくなる
• 単なるガジェットではなく、「役立つ」モノのインターネットの力を活用する製品を創る

Alexa

• alexa音声サービス（AVS）
• alexa skills kit（ASK）

Amazon Robotics

• Amazon倉庫からの発送
• 在庫（棚）が人の方にやってくる（Pod）

Amazon Redshift Ecosystem

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

Redshift概要

• DWHの時代遷移
  • OLTP向けRDBMS：遅い
  • DWHアプリアイアンス：高い
  • 列志向型データベース（ソフトウェア）
  • Redshift：フルマネジド、列志向＆MPP
• 一般的な構成
  • 保存：S3に構造化データを保存
  • Redshiftで分析
  • BIツールで可視化
• IO削減
  • 列志向型（カラムナ）；フルスキャンせずに集計
  • 圧縮、ゾーンマップ（1MBのブロックごとの最大値／最小値をメモリに持つ）

Redshift ecosystem

• ETL/ELT（先にロードして、redshift上で変換する）
• BI
• DataLake
  • 多様なデータを一元的に保存⇒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アカウント：リソースの管理単位、セキュリティ上の境界、課金の分離単位
• 1つのAWSアカウントによる環境：１つのDX接続でオンプレミスとのハイブリッド環境が導入可能
• ワークロードや環境、組織でアカウントを分割

AWSアカウント分割の理由

• ガバナンス（本番環境と開発環境の分離：PCI-DSS準拠のワークロードなど）
  • 管理コンソールを分離、権限の分離、セキュリティ対策の分離 ⇔ 複数アカウントのまたがる監査情報種等の効率化が必要
• 課金
  • 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を利用

[日本経済新聞社] "ＡＩ 記者"の生みの親～「テクノロジーメディア」への挑戦

• 決算の要点を最速で配信、決算短信開示の２分後とかに配信
• 日経電子版はEC2を300台くらい使っている、モバイルはサーバレス
• デジタル事業のNIKEI AI：決算サマリー、日経DeepOcean（例：日経平均と連動している銘柄、原子力関連の銘柄）

決算サマリー

• 東京証券取引所 -> 決算短信：PDF（定性情報）/XBPL（定量情報） -> AWS -> 決算サマリー
• 「要因」の部分で、記者とAIにはまだ差はあるが、見比べないと分からないレベル
• 2015/3に雑談レベル、2015/12から東京大学の松尾研究室と共同研究、ILU（徳島大学発のベンチャー企業）と協業、2017/1リリース
• 性能
  • 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 で変わるバッチの世界 ~ CPU 時間トータル 100 時間の処理を 10 分で終わらせるには~

対象の処理

• 画面の高速描画のための前処理
  • HTML, js, cssの最適化、HTMLテンプレートの事前コンパイル
  • 9,000画面弱
• Sparkで２時間、インスタンス数最適化作業が終わらない

lambda導入

• 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する

処理フロー

• 起動用ファイル：各lambda function用に作成、suffixで処理を区別、ファイルをS3にPutしてlambda実行（ファイルはエビデンスとして残る）
• ステータス管理用ファイル：Pending -> Running -> Success / Warn / Error
  • 前のfunctionがPendingフォルダに入れる、functionの開始時と終了時のフォルダを動かす
  • S3のObjectをListで取得して進捗状況を監視

Troubleshooting事例

• CPU性能はメモリに比例
  • メモリ上限UP! 1.5GBだと2コア利用可能
• 上限変更後、並列数が伸びない（3,000まで上限を上げたが、1,000くらいまでしか伸びない）
  • VPCの設定を確認（subnet）
• 起動直後にエラー
  • S3への大量Put &　結果整合性なので注意が必要
• DBの負荷が上がってエラーになるケースが発生（Cassandraのコネクション）

[Sansan] AWS が支える Eight のリコメンデーションエンジンの裏側

Eightにおけるリコメンデーション

• 日本の名刺交換の10%、Eightに約3億枚の名刺が貯えられている
• レコメンドで名刺交換リクエストをし、つながりを効率的に生み出す
• 旧
  • 誰が誰に何をしたかかを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で分身させる）

リコメンドデータ洗い替え

• Redshift上の全過去ログを集計してレーティングデータを作り直す
• Data Pipeline
  • 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 パイプライン構築

• Continuout Delivery（リリースチェックが入る） / Deployment（テスト通過後、自動でプロダクション環境へリリース）
• SAMの徳直
  • サーバレスアプリに最適化されたAWS CloudFormationの拡張
  • 既存のファンクションをSAMテンプレートとしてエクスポート可能
• SAMで指定できるサーバレスリソース
  • Lambda / API Gateway / DynamoDB
  • XRay連携も本日発表された
  • cloudformationにpackage / deployが追加された
  • SAM templateのyaml -> packageするとCloudformation用のyamlに変換される

SAMとAWS Code関係サービスとの連携

• AWS CodePipeline
  • 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の本が出ます