Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支える サーバーレスアーキテクチャーと開発としてのビジネスの課題

5,628 views

Published on

Serverlessconf Tokyo 2017で喋った資料です!
サーバレス案件のお話待ってます!

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支える サーバーレスアーキテクチャーと開発としてのビジネスの課題

  1. 1. お客様のビジネスを⽀支える サーバーレスアーキテクチャー と開発としてのビジネスの課題 2017.11.03 ⽐比企 宏之 Biz  Serverless Serverlessconf Tokyo  2017 #serverlessconf
  2. 2. ⽐比企 宏之 cloudpack⼤大阪 セクションリーダー/ソリューションアーキテクト 現職でのロール ・拠点⽴立立ち上げ&⼤大阪採⽤用担当(2014〜~2017) ・構築/運⽤用担当(2014〜~2015) ・ MSP運⽤用⾃自動化推進役(2015〜~2016) ・サーバーレスメディア開発チーム(2016 〜~ 2017) ・サーバーレスIoT/AI開発チーム(2017〜~)   バックグラウンド ・携帯電話/スマートフォン端末/エンタープライズシステム開発を 経て2014.4より現職 ・ AWS  SAMURAI  2014受賞 ・ JAWS-‐‑‒UG  MVP  2013受賞 サーバーレス経歴(未公開部分) ・2009年年にGAEでAndroidアプリのバックエンドを作成 ・2015年年◯⽉月に◯ ◯ ◯リリース(事例例未公開・ホワイトペーパー記載) ・2015年年◯⽉月に◯ ◯ ◯リリース(事例例未公開・ホワイトペーパー記載) #serverlessconf
  3. 3. 何故サーバーレスアーキテクチャーを使う? #serverlessconf
  4. 4. 課題の解決として サーバーレスアーキテクチャーが必要? #serverlessconf
  5. 5. 何故サーバーレスアーキテクチャーを使う? • EC2のとなりのLambda? • 会社のWEBサイトの受付部分にAPI  Gateway  &  Lambda? EC2環境は汚れないけど、監視のポイントが増える? #serverlessconf シンプルなシステムを複雑化しているだけかも (全てのシステムをステートレスで作る理理由はない)?
  6. 6. cloudpackサーバーレス開発チームは 何故サーバーレスで提案したのか? #serverlessconf
  7. 7. cloudpackとして課題の解決として提案した案件 • cloudpackの根幹であるMSP業務を⽀支える各種サービス • MBS動画イズム444  (有料料動画配信) • トリニティ(世界三点からの運⽤用システム) • MBS動画イズム (⾒見見逃し配信・ライブ配信) • おしゃべりらいよんチャン&番宣宣伝システム ※他にもあるのですが、公開許可出てないので割愛 #serverlessconf
  8. 8. cloudpackの根幹であるMSP業務を⽀支える各種サービス • 課題としてMSP業務の可視化・便便利利化・⾃自動化をする必要があった #serverlessconf • 必要性は現場でも認知されていたが、その課題を解決するインフラを現場の メンバーがお守りする必要が新たに発⽣生するのはいかがなものか?
  9. 9. MBS動画イズム444  (有料料動画配信)  2016年年12⽉月リリース #serverlessconf 「MBS動画イズム444」とは、 MBSで現在放送中の番組や、過去の名番組を、 インターネットに接続したPC、スマートフォンなどで視聴いだけるサービス。 ⽉月額定額課⾦金金で全ての作品を⾒見見放題
  10. 10. MBS動画イズム444  (有料料動画配信) #serverlessconf 課題 • 新規ビジネスなのでスモールスタートが必須(ランニング費⽤用がかさむと 横槍が⼊入る可能性がある。勝ち続ける事が前提の⽅方法ではなく、負けな いための⽅方法を考えた) • サービスが急に拡⼤大した場合でも耐えうるアーキテクチャーが必要
  11. 11. Trinity(世界三点からの運⽤用システム)  2017年年1⽉月リリース #serverlessconf 「Trinity」とは、 サーバーレス開発セクションで作成したサービスの監視と運⽤用を補助する⾃自作 のシステム。世界三箇所からEC2などを使わずにLambdaを使っているので安 い(ってゆうかLambda分は無料料枠で収まる!)
  12. 12. Trinity(世界三点からの運⽤用システム) 課題 • サーバーレスのシステムの運⽤用にEC2ベースでの監視はいかがなものか? • 当時SaaSの監視システムを使って監視を⾏行行うも、cloudwatchのコストが結 構⾼高くなった(頻繁にcloudwatchがコールされていた) • API  Gateway&Lambdaの弱点である、同時実⾏行行数に対する攻撃の防御を実 現する必要があった • 従来から監視システムの冗⻑⾧長化を⾏行行いたかったが、EC2ベースやSaaSベー スだとコスト⾼高になるので、安価なLambdaベースのリージョン障害にも耐 えうる監視システムを実現させたかった #serverlessconf
  13. 13. おしゃべりらいよんチャン&番組宣伝システム 「おしゃべりらいよんチャン」とは? 関⻄西で愛されているMBSの番組宣伝キャラクター(ほとんど番組内容については 語らずコスプレばかりする)のLINE  BOT #serverlessconf
  14. 14. おしゃべりらいよんチャン&番組宣伝システム 課題 • 既存の番組宣伝システムがそもそも⾼高かった!既存のシステムから保守費な どを含めリプレイスした⽅方が、全体的にコストダウンが可能とお客様が判断 • コストダウンした⾦金金額を元に攻めのIT投資を実施。LINEのBOTシステムが 導⼊入可能となった #serverlessconf
  15. 15. MBS動画イズム (⾒見見逃し配信・ライブ配信) 課題? • 動画イズム444でランニング費⽤用が下がる事が実証されたので、既存のサービス のコストダウンと、運⽤用時の⼊入⼒力力⽅方法の⼀一本化なども考えてお客様が判断。 #serverlessconf 「MBS動画イズム」とは、 番組放送終了了後の番組&ライブ動画を無料料で配信。 動画の視聴には専⽤用のアプリで対応
  16. 16. 課題を実現する為に サーバーレスアーキテクチャを選択 #serverlessconf
  17. 17. リリースした各サービスの技術的な特徴 #serverlessconf
  18. 18. cloudpackの根幹であるMSP業務を⽀支える各種サービス • インシデントの取りこぼしを起こさないようにする仕組みを設計レベルで 実現(トリガーイベントだけで処理理をせずに、リカバリー⽤用にタイムスケ ジュールで動作するモジュールを配置)。 lambdaがリリースされた当時は実⾏行行の正確性が怪しかったので、 必ず動く事を前提としないアーキテクチャー設計をおこなっていた #serverlessconf 参考 「サーバレスアーキテクチャーを運⽤用に適応するために考慮する事」 http://unioce.hatenadiary.jp/entry/20160510/1462869394
  19. 19. MBS動画イズム444  (有料料動画配信) • lambdaの実⾏行行回数制限が厳しかった(2016年年12⽉月はデフォルト100)ので、 どれだけlambdaを使わないでいけるかを念念頭に全体のアーキテクチャ設計 を⾏行行った • 他のクラウドサービス(kintone・sendgrid)が⽌止まっていても、後から⾃自動 で復復旧できるようにSQSなどにJOBを溜溜め込んで、必ず動作させるようにし ている。 #serverlessconf 参考 「『MBS動画イズム444』サーバーレス・アーキテクチャを全⾯面採⽤用」 https://cloudpack.media/27082 「図解!サーバーレスの全⾯面採⽤用の姿」 http://itpro.nikkeibp.co.jp/atclact/active/17/081700122/081700004/
  20. 20. MBS動画イズム系 • cloud  frontを徹底 的に活⽤用 • HTML&javascript で出来ない部分のみ をAPI  GATEWAY  &   Lmabdaで実現 • 他のクラウドサービ スは⽌止まっていても 後からの復復旧は⾃自動 的にできるようにま ずキューイング • CMS部分はkintone で開発費と運⽤用コス トを削減 #serverlessconf
  21. 21. Trinity(世界三点からの運⽤用システム) • 基本機能は監視だが、異異常なアクセスを受けた 場合はWAFでガードする機構も実現 • 監視対象の監視だけではなく、監視している lambda同⼠士も監視して冗⻑⾧長性を担保している • リージョン障害を起こしても、三箇所のどこか のlambdaのどれかが動く構造なので、必ず動 かす必要のあるJOBを実⾏行行する事が可能 #serverlessconf 参考 「サーバーレス・アーキテクチャで構築したシステムの運⽤用はどうやるのか?」 https://cloudpack.media/28885
  22. 22. Trinity(トリガー部分) • 現状はWAFのみだが、今 後は必ず動作させるため の共通のトリガー機能も 実装されていく予定 #serverlessconf
  23. 23. おしゃべりらいよんチャン • 快適なレスポンス実現のために、いろいろな箇所でキャッシュ処理理が動き、 S3への会話の元データのアクセスやLUISへのアクセスは同じ⼊入⼒力力データの 場合はLambdaでキャッシュしたデータにアクセス • その瞬間に処理理する必要のないものは、SQSに保存し、後で処理理して会話の レスポンスを重視 #serverlessconf 参考 「AWSとAzureを同時活⽤用、先端技術を駆使したボットで番宣」 http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101901172/ 「『おしゃべり らいよんチャン』をサーバーレス・アーキテクチャで実装」 https://cloudpack.media/32392 「キャラクター作りの試⾏行行錯誤を味わった「おしゃべり らいよんチャン」の舞台裏裏」 http://ascii.jp/elem/000/001/568/1568113/
  24. 24. おしゃべりらいよんチャン(bot部分) • 会話のデータはkintoneからのデータ⼊入 ⼒力力とAWS  Batchで実⾏行行するWEBのスク レイピングしたデータをS3にUP • S3のデータをbotが取得しユーザーに返 答。 • ⼊入⼒力力されたデータの解析にはMS社の LUISも活⽤用 • ⼀一回⽬目のアクセス時のデータをキャッ シュし、⼆二回⽬目以降降はキャッシュデー タを返す(lambdaのコンテナ単位) • ユーザーの動向データは⼀一度度SQSに保 存し、その後にS3→アテナ→kintone #serverlessconf
  25. 25. cloudpack BOTパッケージ全容(bot部分) • おしゃべりらいよんチャンで使ってい る弊社作成のBOTパッケージ。 • SaaSでは提供せずにお客様にソース 提供 • カスタマイズ可能(要SI) • アプリケーション保守・運⽤用監視も承 ります(トリニティで監視) #serverlessconf Bot案件あればお声がけを!
  26. 26. おしゃべりらいよんチャン(通知部分) • 安価にできるだけ並列列 でメッセージ送信する アーキテクチャー (Lambdaの同時実⾏行行 数分に近いメッセージ 通知が可能) #serverlessconf
  27. 27. 番組宣伝システム • サーバーベースの既存 システムを動画イズム 444のアーキテク チャーでリプレイス。 • kintoneのUIは使わず にDBとしてのみ使っ た(お客様のPCの解像 度度の問題) #serverlessconf 番組宣伝システム承ります! リプレイスで、浮いた予算で別のIT投資しましょう!
  28. 28. サーバーレス開発チームとして設計時に全体的に気をつけていること • 開発コストとランニングコストの兼ね合い • 各利利⽤用サービスが障害発⽣生で動かない場合に後でリカバリーする⼿手 段を設計時にシステム図に明記 • 実⾏行行されても何らかの原因で動かない(接続先のサービスが動かな い・IAMの確保ミス)場合でも、リカバリーする⼿手段を設計時にシス テム図に明記 • 利利⽤用する各クラウドサービスの機能には期待するが、疎結合前提な 部分も含め性能⾯面は期待しない。性能⾯面は作りでカバー! • 本当にその瞬間処理理すべきか?処理理タイミングをしっかりと考える #serverlessconf
  29. 29. SIビジネスとしてのサーバーレスの課題 #serverlessconf
  30. 30. 開発コストが上がりやすいサーバーレスはコンペで負けやすい • イベントドリブンな部分が多くなり、結果的に各機能が並⾛走しやす いサーバーレスなシステムは、システム全体で同期を考える必要が ある為に構成が複雑になりがち • 運⽤用⾯面での復復旧の⾃自動化を最初から考慮しておく必要があるので設 計や実装⼯工数が増える 上記要因により、運⽤用も含めて考えられたサーバーレスアーキテク チャーで作られたシステムは運⽤用フェイズに⼊入れば開発コストを回収 できるが、開発のコンペ時に運⽤用フェイズの話はでなくて、 発注元が安いに主眼がいく為にコンペ負けしやすい。 #serverlessconf
  31. 31. 発注をご検討されている⽅方々。 コンペ形式の場合は⾦金金額だけでなく、 運⽤用⾯面まで考慮している開発ベンダーか?を ご確認ください (サーバーレスだけの話ではないですが汗) #serverlessconf
  32. 32. 上記業種 鋭意募集中! http://cloudpack.jp/recruit 開発エンジニア インフラエンジニア デザイナー 採⽤用情報
  33. 33. 雲勉という勉強会を⼤大阪で開催しています。 ハンズオン形式以外なら、リモート接続もできますので ⼀一⼈人ずつの接続はできませんが、まとめて接続できる 場所とつなげてくれる⼈人がいればつなげます! ⼤大阪での開催時に #kumoben #開催希望 でツイートしてください! 「雲勉」コミュニティに登録を!
  34. 34. ご清聴ありがとうございました #serverlessconf

×