AWS DevDay Tokyo 2018 Software Design/Serverless & Mobile トラック+α まとめ
(2018/11/12 更新) Amazon Web Services ブログで資料が公開されましたので、末尾にリンクを追記しました。
AWS DevDay Tokyo 2018 が10/29-11/2 の5日間に渡って行われました。 私は10/31(水)のみ現地で参加し、11/1(木),2(金) はライブストリーミングでちょこちょこ参加しました。 aws.amazon.com
非常に内容が濃く、素晴らしいイベントでしたので、10/31(水)のSoftware DesignトラックとServerless & Mobile トラックについて自分の聴講メモと公開された資料をまとめて残したいと思います。
10/31(水) Software Design トラック
セキュア開発プロセスをアジャイル開発に適用するには
講師: 徳丸 浩 さん（EGセキュアソリューションズ株式会社代表、独立行政法人情報処理推進機構（IPA）非常勤研究員)
アジャイルのような段階的に機能を作り込んだり追加していったりするプロセスにおいて、セキュリティ施策をどう組み込んでいくか現実的な落とし所を考えるセッションでした。
聴講メモ
- アジャイル開発とセキュアプログラミングは相性が悪い？
- セキュリティ施策を分類する
- セキュリティ方針決定系や教育系、予算確保は1回のみ
- それ以外は繰り返す → 自動化したい
- セキュリティ施策の優先度
- エアバッグのない自動車は販売できる(法令上は)が、ブレーキのない自動車は販売できない
- ログイン機能のないWebサイトはリリースできないが、二要素認証がないWebサイトはリリースできる
- アジャイル型開発での脆弱性対処
- 脆弱性診断をインクリメンタルに実施する
- プラットフォームのセキュリティ
- OpenVASやNessusで自動化
- デモ: OWASP ZAP で脆弱性診断したときのURLをPHPUnitで叩いて単体テストに脆弱性診断を組み込む
- が、ツールによる診断では十分とは言えない
ドメインモデリングの始め方
講師: 加藤 潤一 さん（ChatWork株式会社） speakerdeck.com
あなたの推しテクをもっと伝えるプレゼンテーション術
講師: 長沢 智治 さん（エバンジェリズム研究所 代表） speakerdeck.com
The Twelve-Factor App で考える AWS のサービス開発
講師: 千葉 悠貴 さん、畑 史彦 さん（アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト）
外部に依存したコードもテストで駆動する
講師: 和田 卓人 さん（タワーズ・クエスト株式会社 取締役社長、プログラマ、テスト駆動開発者）
Alexa Skillのコードを元にTDDでコードを改善していくセッションでした。
聴講メモ
- Alexa Skillのフレームワークに依存している
- 網羅性はいらない。脳天気な正常系(Happy Path)でいいので動くテストがほしい
- ランダムな応答を返すもののテストはどうやるか？
- レガシーコードのジレンマ
- 接合部(Seam)を作る
- 固定値を外からねじ込めるように書き換える
- テストで品質は良くならない
- テストは品質がよくなるためのきっかけ
- モデルを分離する
- Lambdaレベルのテストをグリーンに保ちながら、ロジックをモデルクラスに引き剥がしていく
- モデルクラスはテスト駆動開発で新規開発する
- 環境依存を減らす
- アーキテクチャを定める
- 安定依存の原則 … 変化しやすいものに依存しない
- 情報 を扱うレイヤと 事実 を扱うレイヤを分ける
日経電子版におけるPWA活用事例
講師:安田 竜 さん (株式会社日本経済新聞社）
実践！リーンなプロダクト開発 ~リーンでアジャイルなUI/UXデザイン検証~
講師: 奥原 拓也 さん (dely 株式会社) speakerdeck.com
10/31(水) Serverless & Mobile トラック
浸透するサーバーレス、実例に見るユースケースと実装パターン
講師: 杉 達也 さん (アマゾン ウェブ サービス ジャパン株式会社 事業開発マネージャ (サーバーレス担当))
Serverless Application Security on AWS
講師: 桐山 隼人 さん（アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト）
AWS Well-Architected Framework の Serverless Applications Lens を読み解くセッションでした。
聴講メモ
- セキュリティの柱
- IDとアクセス管理
- 発見的統制
- インフラストラクチャー保護
- データ保護
- インシデントレスポンス
- IDとアクセス管理
- 発見適当性の考慮事項
- インフラストラクチャー保護の考慮事項
- データ保護
- インシデントレスポンスの考慮事項
- セキュリティインシデントが起きたとき
- 侵入テスト AWSに事前申請が必要
開発者におくるサーバーレスモニタリング
講師: 小梁川 貴史 さん（アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト）
AWS Lambdaを中心にmetricsの意味や監視ポイントを解説するセッションでした。
聴講メモ
- 自分が作ったものがどう使われているのか・動いているのかを把握できることが重要
- AWS Lambdaの起動パターン
- duration の意味
- ENIの作成～ランタイム起動・初期化 までの時間はdurationに含まれない
- SQS起動における注意
- メッセージ数 > 処理量 の傾向が続いて処理が追いつかない状況になるとコンカレンシーリミットまでスケールする
- コンカレンシーリミットを設定していないと、アカウントの上限までスケールして他のLambdaに影響を与えてしまう
- AWS X-Ray
- CloudWatch Logs filter pattern
ZOZOTOWN の膨大な画像ファイルを移行したときの過程の話（オンプレミスからクラウドへ）
講師: 柴田 翔 さん（株式会社ZOZOテクノロジーズ《旧：株式会社スタートトゥデイテクノロジーズ》ZOZOバックエンド部ネットワークブロック）
数億点の画像ファイルをS3に移行した事例についてのセッションでした。
聴講メモ
- 移行背景
- 容量不足
- ZOZOUSED(中古=同じ商品が無い)のサービスが好調
- 画像数億点 約60TB (オリジナル画像+リサイズ画像)
- 監視したくない
- 逼迫の恐怖
- 画像アップロードの量が多い
- オンプレミス画像サーバが耐えられない
- オンプレミスの保守
- 夜間アラート
- 夜間アラートの60%が画像サーバ関連
- スケーラビリティが必要
- サービス拡大による画像アップロード数の増加
- 容量不足
- なぜS3なのか
- 高い耐久性、容量制限がない
- 公開ナレッジが多い
- AWS SAの手厚い技術的サポート
- 移行する上で重要視したポイント
- 運用コスト削減のため、なるべくマネージド
- 画像データの容量を気にしなくていい
- 短期間での移行のため、開発対象を少なくし、テスト工数も削減したい
- 画像移行パターン
- パターン1：Snowballでの移行 → ボツ
- 転送速度の計算
- 約60TB
- 平均オブジェクトサイズ 128KB
- 転送速度 10MB/s
- → 72日
- 暗号化に時間がかかる
- 出す・入れる で2倍
- 移行用クライアントが必要
- オフライン同期のため、差分同期が面倒
- 転送速度の計算
- パターン2：S3に直接PUT → ボツ
- 転送速度を計算
- 転送速度 42MB/s(バッチ3並列の実測値)
- → 17.3日
- 転送速度4倍
- Snowballの手配が不要に
- 転送速度を計算
- パターン3：オリジン画像のみS3直接PUT、リサイズはLambda → 採用
- 転送速度を計算
- 約30TB(オリジナル画像のみ)
- 転送速度 42MB/s(バッチ3並列の実測値)
- → 8.6日
- Snowballの8倍、全画像PUTの2倍 リサイズ用オンプレサーバ不要に
- 転送速度を計算
- パターン1：Snowballでの移行 → ボツ
- 移行後の構成
- ポイント
- Lambdaの修正の楽さ
- 属人化が排除できた
- 公開ナレッジの多さ
- 画像変換用サーバが不要に
- Lambdaの修正の楽さ
- 移行過程で発生した問題
クックパッドの動画事業での AppSync 活用事例 - Firebaseからの移行 -
講師: 渡辺 慎也 さん (メディアプロダクト開発部部長 CookpadTV株式会社取締役 CTO)
AppSyncをMicrservicesの一部として組み込んで使う事例のセッションでした。 speakerdeck.com
聴講メモ
- コメントやハートの実装
- Firebase Realtime Databaseを使っていた
- 当時はまだAppSyncが東京リージョンに来ていなかった
- 移行のモチベーション
- データをAWSとFirebaseに分散させたくなかった
- AppSyncはDynamoDBやLambdaなどコントローラブルな点が多い
- WRITEはサーバー経由、READは直接
- コメントはNGワードのフィルタリングなどをかけたいので
- スタンプはポイントが必要なのでチェックが要る
- AppSyncのボトルネック
- Cognitoの制限
- Cognitoの GetCredentialsForIdentityの同時実行数
- API Keyを利用すれば回避できる
- Mutation per second制限
- アプリへのファンアウト数
- 細かいメッセージをたくさん飛ばすより、ある程度バッファリングした方が良い
- Cognitoの制限
- Service Mesh
- SDK実装ではなくSidecar Proxy(Envoy)経由で通信する
- cookpadTV message and MBR
- AppSync Shcema
- 複数 Subscriptions
- コメント、ハート、スタンプ、ユーザ数 はそれぞれ別 Subscription
- 受信データは配列
- サーバ側でバッファリングできるように
- 複数 Subscriptions
- AppSync Resolver
- 当初DynamoDB Data sourceを使っていたがwriteがボトルネックに
- 結局 Data source type None にした
- サーバサイドからAppSyncに書き込むことが想定されてないのでSDKなどがなく、自前で書いた(Go)
Serverlessを極めるためにDynamoDBデータモデリングを極めよう
講師: 照井 将士 さん (株式会社サーバーワークス Solution Specialist)
AWS上のServerlessアプリケーションのデータストア層として採用されることが多いDynamoDBにおけるモデル設計についてのセッションでした。 speakerdeck.com
- DynamoDB Best Practicesを読もう
- Partition Keyのハッシュでパーティションが分散される
- なので、Partition Keyに連番を振ってもあまり意味がない
- 論理的に一意であればOK
- DynamoDB内のデータは Partition Keyで分散した中で Sort Keyで整列 しているというイメージを持つ
- 結果整合性 って大丈夫なの？
- RDBでもリードレプリカから読み込む場合は結果整合性なので、変わらない
- DynamoDBの設計アプローチとRDBの設計アプローチ
- ACIDトランザクションが無い問題
- ACIDとは 原子性・一貫性・独立性・永続性
- DynamoDBの場合、非正規化して1つの実体について1つのアイテムに収める
- 1アイテムの更新はアトミックであり原子性は保たれる
- 非正規化してあるので読み込みツラい問題
- CQRS (Command Query Responsibility Segregation)
- 書き込むデータと読み込むデータは同じである必要は無い
- 結果整合性を受け入れて非同期で読み込みデータを作る
- Command の完了をもってQuery用のデータを作る
- マテビュー的な
- とはいえ、複数の実体にまたがるトランザクションはできない
その他
ライブストリーミングで以下のセッションを聴講しました。
どれも素晴らしかったですが、DynamDB 関連のセッションが特に最高でした。
Amazon DynamoDB Advanced Design Pattern
講師: 江川 大地 さん（アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト）
DynamoDBの設計についてのセッションでした。
www.slideshare.net
おそらく昨年の re:Inventの以下↓ のセッションが基になっているのだと思うのですが、元のセッションも素晴らしかったですし、説明の順序が改善されて日本語になった本セッションは今まで聞いたDynamoDBの説明の中で一番わかりやすいと感じました。
DynamoDB Backed なテレコムコアシステムを構築・運用してる話
講師: 安川 健太 さん（株式会社ソラコム CTO）
あのSORACOMのバックエンドでDynamoDBをどのように使っているかのセッションでした。
複数の値を一度に更新したい場合の対処法 で紹介されていた方法は初見で、直接情報をアイテムに残すことが難しければデータ(事実)を記録してあとで必要な情報が生成できるようにすればよい、と理解しました。
www.slideshare.net
マイクロサービス時代の認証と認可
講師: 都元 ダイスケ さん（クラスメソッド株式会社 事業開発部 シニアシステムアーキテクト）
認証と認可とは何か、から始まってよくあるWebシステムで必要とされる認証・認可について考えるセッションでした。
後半Twitchの中継が止まってしまって聞けなかったのが残念でした…
さいごに
時間がかぶった関係で観られなかったセッションも多かったので、動画の公開が楽しみです！
