JAWS-UGアーキテクチャ専門支部 ServerlessConfレポート

SERVERLESSCONF
’16 NYC レポート
2016.7.14
株式会社セクションナイン
@yoshidashingo

吉田真吾
n バックグラウンド
証券システム基盤開発
p 基盤開発、Oracleチューニングなど
エバンジェリスト
p 講演年間113回(2013年実績)
p AWS設計・構築・移行(2014-2015)
n 現在のしごと
(株)セクションナイン社長
p AWSコンサルティング
Mobingi, K.K. VP of Eng
p サービスデベロップメント
n 実績等
p AWSウルトラクイズ
初代チャンピオン (2012年)
p AWS Samurai 2014
p AWSエキスパート養成読本執筆
p AWS認定全資格(5種類)保持
p Oracle Database 11g認定 (OCP,
Performance Tuning)保持

インフラのパラダイムシフト
• その昔
• 土地：所有
• ハードウェア：所有
• キッティング：自分
• ミドルウェア設定：自分
• データセンターアウトソーシング
• 土地：借りる
• キッティング：自分
• ミドルウェア設定：自分
• ハイパーバイザー仮想化
• 土地：借りる
• キッティング：イメージの展開
• ミドルウェア設定：イメージ
/Configuration Management
• クラウドコンピューティング
• セルフサービス
• ペットから家畜へ
• Infrastructure as Code: ソフト
ウェアのベストプラクティスをイ
ンフラにも適用
• サーバーレスコンピューティング
• コンテナ技術活用によるFaaSの現
実感
• マイクロサービス

その他のパラダイムシフト
アプリケーション
• クラサバからWebへ
• Enterprise Architecture
による全体最適化
• SOAによるWebサービス
連携
• OSSの活用
• アジャイル開発
• ITのコンシューマライ
ゼーション
オペレーション
• ITサービスマネジメント
• ITSMSの導入
• ITSSv3
• Site Reliability Engineering
• ソフトウェア・エンジニアリン
グでITサービスマネジメントを
実現する
• 自動化、連鎖障害の極小化(クラ
スタレベルでの管理)、改善速度
の向上、エラーバジェットによ
る管理
• DevOpsワークフロー

Process→Experience
厳格なプロセスによるマネジメント
↓
組織文化内での役割による必然性
（Workstyle Experience）による
マネジメント

サーバーレスとは
レポートの前に…

参考資料
http://martinfowler.com/articles/serverless.html http://www.slideshare.net/acloudguru/ant-
stanley-being-serverless

サーバーレスとは
1. リッチクライアント
アプリケーション
• BaaSの活用
2. イベントドリブンな
コード実行環境
• FaaSの活用
http://martinfowler.com/articles/serverless.html
2つのトレンドが混ざっていて「サーバーレス」の
定義は明確に定まっていない

1. リッチクライアントアプリケーション
• サーバーサイドのロジックや状態を管理するサー
ドパーティのクラウド上のアプリやサービスを利
用する
• シングルページアプリケーションや
モバイルアプリ
• サービス
• BaaS, mBaaS, 2-Tier Architecture …
• クラウドなデータベース：ParseやFirebase,DynamoDB
• 認証サービス：Auth0やCognito
• APIとして提供、ひとつを上手くやる
マイクロサービスの組合せ

2. イベントドリブンアプリケーション
• サーバーサイドのロジックを、ステートレスな
クラウドのコンテナでできた実行環境に載せて
イベントドリブンに稼働させるアプリケーショ
ン
• Function as a Service：AWS Lambda, Azure
Functions, Google Cloud Functions, IBM
Bluemix OpenWhisk
• Auth0は認証アプリだけでなく、Webtaskとい
うサーバーレスコンピューティング環境も提供

組合せ例
1. UIドリブンアプリケーション
2. メッセージドリブンアプリケーション

UIドリブンアプリケーション
• モノリスからマイクロサービスへ
の移行でサーバーレス活用
1. 認証ロジックをBaaSで置換え
2. DynamoDBにクライアントから直
接アクセスするように
3. 大半のロジックをクライアントの
シングルページアプリケーション
に(UXに気をつける)してサーバー
側はAPI Gatewayで束ねる
4. 検索機能をFaaS上に
5. セキュリティの考慮で課金は別DB
に別FaaSでアクセスするように

メッセージドリブンアプリケーション
• オンライン広告システム
• 素早い配信(と同時に)
アクティビティ記録
• 非同期にサーバーに送信してい
た部分をスケーラビリティを気
にしなくていいFaaSに送信

http://www.slideshare.net/acloudguru/ant-stanley-being-serverless

ServerlessConf レポート
• 5/25(水)26(木)27(金)
AWS Pop-up Loft, Villain @ New York
• Serverless Computing/Architecture/Apps のベンダーニュートラルな技術カンファレンス
• API Gateway
• S3
• Elastic Transcoder
• Auth0
• Firebase
• DynamoDB
をもちいたサーバーレスな
Youtubeクローン作成
Day 1 Day 2ワークショップ
• ベンダー各社
• ツール開発者
• ベンダー各社
• ユーザ事例
ü King of PaaS?
ü Flourish
ü NoOps?

Category
1. Serverless Computing (Platform)
2. Ecosystem (Framework)
3. Usecase of developers

Serverless Computing
• サーバーレスがなぜ上手くいくか
• 規模の経済性
• 使う人が多くなれば多くなるほどコスト集約され、リソース
のムラがなくなる
• Isolation Level
• コード＆ライブラリをコンテナライズして配布
• プロビジョニングのリードタイム
• リカバリのリードタイム
• サービス形態
• コンテナを含むインフラレイヤを隠蔽し、Function as a
Service化されている

AWS Lambda
• サーバーレス・マニフェスト
1. ファンクションはデプロイ単位/拡張可能単位で管理する
2. 機器や仮想サーバーやコンテナがプログラミングモデルから
見えてはいけない
3. データを永続化するストレージは他の場所に確保する
4. リクエスト単位にスケールが管理される。ユーザーはキャパ
シティの調達不足も超過もしない
5. アイドル時間に課金されてはいけない（待機サーバー/コンテ
ナや課金）
6. ファンクションはどこでも実行できるので、暗黙的に耐障害
性を持つ
7. Bring your own code. コードだけ持ち込めばいい
8. メトリクス収集やログ取得は絶対的正義である

AWS Lambda
YES
• 独立したファンクション
• RESTful APIか
イベントドリブン
• BYOC(コードを持ち込むだけ)
• 複雑なアルゴリズムで管理
• 水平スケール
• 同期/非同期/スケジューリング
NO
• サーバー上で稼働
• モノリシックなtarボールになっ
ている
• モノリシックなデプロイ方法
• 重量級フレームワーク
• 分散配布されたシステムコード
• 単調作業（ログ取得など）が必要
• サーバーレスアプリケーションかどうか

Ecosystem (フレームワーク)
• コードの再利用性
• リポジトリで共有
• CI/CDも：ビルド→レグレッショ
ンテスト→デプロイ
• APIやDBも含めた統合開発・管
理

Flourish
• 実行アプリケーションモデリング
• Microserviceのフォーマット定義
• IDEプロジェクトとのマッピング
• ビルドをおこなったり、ZIPによるデプロイ
• 共有コンテナ上での実行
• 1箇所のダッシュボード上での監視
• 利用料金の集約
• モノリス(一枚岩)を避けるために使う
• Lambdaファンクションは独立したアップデート機能を備えて
いる
• Flourishのバージョンコレクション
• コードと設定の組合せによる一貫性のあるロールバック機能
• モノリシックなデプロイ方法は不要

Flourish
AWSがLambdaを産み
エコシステムとサービスマネジメントが支える
Serverless

Python Serverless
Microframework for
AWS(Preview)
FlourishはないけどChalice(聖杯)は出た

Serverless Framework
• Node.js
• 豊富なサブコマンド
• ステージの概念
• プロファイルやリー
ジョンの切替
• リソースやエンドポ
イントの削除など
Python Serverless
Microframework for AWS
• Python
• シンプル！
• chalice new-project
してapp.py書いて
deploy!
• 今後に期待

より開発が簡単にできるサービス
vs
ファイングレインな設定ができる
ビルディングブロックなサービス

10X Product Development
• 製品がマーケットにフィットす
るかどうかが最も重要である
• ビジネスに関連するコードの開
発時間に極力時間を使うべきで
ある
• 顧客とまわすイテレーションを
最大化すべきである
• 依存性を最小化すべきである：
仕様確定待ちで開発者を待たせ
たり、運用やDBAやその他の開
発者の影響で待たせることを極
力避けるべきである
http://www.slideshare.net/ServerlessConf/joe-emison-10x-product-development

10X Product Development
• Commercial Search
• 2人の開発者で4ヶ月で作った
• 13,307行のTypeScript
• 開発者の稼働は95%以上だった(なにかに依存した待
ち時間はほとんどなかった)
• コンセプトはMicroservicesだが、自分たちはコアし
か書いていない
• 構成
• Auth: Firebase
• Static Site Hosting: Netlify
• 画像管理: Cloudinary
• 検索: Algolia
• ペインポイント
• Firebaseのダッシュボードでは大きなデータセット
が扱えない（APIであればOK）
• RDBMSからFirebaseに移行する開発者のラーニング
カーブは人それぞれ、非常識ってほどではないけど
http://www.slideshare.net/ServerlessConf/joe-emison-10x-product-development

From serverless to Service Full
• サーバーレスな構成のために積極的に
SaaSを使うことが増えた
• ITサポートサービス：DataDog, GitHub,
CircleCIなど
• オフィスサービス：Gppgle Apps, Slack,
Dropbox, Google Calendar, Skype,
Trello, Google Hangoutなど
• コミュニティサービス：npm, ubuntu,
coreos, NTP, Docker Registryなど
• フロントエンドサービス：jQuery,
Google font api, AngularJS, Google
Analytics
• モバイルサービス：AWS Device Farm,
Amazon Mobile Analytics, SNS, Cognito,
App Annie, AppStore, Google Play
Store, fabric, New Relic, ComScore
https://www.slideshare.net/jedi4ever/from-serverless-to-service-full-how-the-role-of-devops-is-evolving

• サービスの可用性に依存しているので、GitHubが落
ちたらシゴトができない、みたいなことがよく起きる
• 文書化されてない変更が入ったりする（CircleCIの
例）
• ELBは事前暖機が必要で、忘れて急にトラフィック受
けると何もできずにエラーが大量に返ってしまう
• サーバーレス、というかサービスフルな状態で
【SaaSがダウンしてサービスが継続できないリスク
が上昇している】

• Lambdaのサービスの内部仕様
• Lambdaのコンテナの再利用ルールは非決定
• スケールは常に無限というわけではない
• DevOpsを採用して、リモートAPIを駆使する
• RSSでAWSの障害を監視
• Google Scanningを用いたGoogle Appsのデータのバックアップ
• Slackを用いてステータス変更を素早くフィードバックできるようにする
• (ポストモーテムなどを読んで)何に依存しているか明らかにする
• カンファレンスでサービスへの希望を共有する
• 他の人に経験をフィードバックする
• 自分を頼りにしてくれる人たちにも知ったことを教えてあげる
• 同僚のエンジニアたちにおそれずに情報交換すべきであるということを示す
• 要望されていることに対する責任を持つ
• DevとOpsのコラボレーションはいまや外部のサードパーティベンダーにまで広がって
いることを認識する

Serverlessness, NoOps and the Tooth Fairy
• 来たるサーバーレスな未来では、アプリ
ケーション開発者がもっと運用品質に対
する責任を担うことになる
• インフラは外部にホストしてるから運用の
ことは考えたくないと言っても、アプリが
落ちているかもしれない状況においてはど
んな変更があったか、サービス側の問題か、
切り分ける必要性がある
• 運用とはなにか？
• 運用は自分の組織の技術スキルや練習、デ
ザイン周りの文化づくり、システムの構築
やメンテナンス、ソフトウェアのデリバ
リー、技術的な問題の解決
"In the glorious Future, we will be Serverless,
and there will be NoOps. - thought leaders"
http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy

• 運用とはなにか？
• 運用は自分の組織の技術スキルや練習、デ
ザイン周りの文化づくり、システムの構築
やメンテナンス、ソフトウェアのデリバ
リー、技術的な問題の解決
• 運用エンジニアのコアコンピテンシー
• スケーラビリティ
• レジリエンシー
• 可用性
• メンテナンス性
• 複雑なシステムを簡素化するモニタリング
の実装と可視性
• グレイスフルデグラデーション：ソフト
ウェアのアップグレードなど

• サーバーレス運用工学のベス
トプラクティス
• あなたのプロダクトの問題はあ
なた以上にちゃんと直せる人は
いない
• クリティカルパスを理解する
• できるかぎり小さく維持する
• SaaSプロバイダの技術情報と、
何にどう依存しているか理解す
る
• アウトソース先に問題が起きても、
自身のサービスにおけるそれによ
る結果については依然としてあな
たが責任を持たなければいけない

• トレードオフ
• 可視性が下がる
• 自分自身で問題をfixできない
し、新機能を実装することも
できない
• サービスはあなたの支払うお
金で維持されている
• 制限や制約は公開されること
もあるし、公開されないこと
もある

より開発が簡単にできるサービス
vs
ファイングレインな設定ができる
ビルディングブロックなサービス
↓
開発のアジリティとResponsibilityのバランス

リクルートジョブズ
• タウンワークにおけるサー
バーレスアーキテクチャデ
ザイン
• CTL(データサイエンティス
ト集団)が機械学習ロジッ
クに集中できる環境
• ログ基盤を整備し、カスタ
マーの回遊や検索における
リアルタイムな特徴量の更
新や、バッチ処理による予
測モデルの作成に利用
https://techblog.recruitjobs.net/events/aws-summit-tokyo-2016-townwork-serverless-architecture-design

リクルートジョブズ
• Lambdaがなかったらこ
の規模のシステムをごく
短期間でリリースする事
は不可能だったと言える
https://techblog.recruitjobs.net/events/aws-summit-tokyo-2016-townwork-serverless-architecture-design

やっていく気持ち
サーバーレスでビジネスを牽引する先駆者になる

Serverlessconf Tokyo
the future will be
Serverless Community (JP)
https://www.facebook.com/groups/813718382095265/

JAWS-UGアーキテクチャ専門支部 ServerlessConfレポート

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie JAWS-UGアーキテクチャ専門支部 ServerlessConfレポート

Ähnlich wie JAWS-UGアーキテクチャ専門支部 ServerlessConfレポート (19)

Mehr von 真吾吉田

Mehr von 真吾吉田 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (10)