サーバーレスでシステムを開発する時に⼤切な事

サーバーレスでシステムを開発する時に⼤切な事

1. 1. 2017.3.11 Hiroyuki  Hiki サーバーレスでシステムを開発する時に⼤大切切な事 JAWSDAYS2017
2. 2. ⾃自⼰己紹介 cloudpack⼤大阪 セクションリーダー/SA  ⼤大阪拠点⽴立立ち上げ⼈人 構築・24/365運⽤用(2014〜～2015) MSP運⽤用⾃自動化推進役(2015〜～2016) サーバーレスメディア開発部隊(2016) →サーバーレスIoT開発部隊(2017〜～NEW) バックグラウンド 携帯電話/スマートフォン端末開発 エンタープライズシステム開発を経て 2014.4より現職 AWS  SAMURAI  2014受賞 JAWS-‐‑‒UG  MVP  2013受賞
3. 3. SAVE THE DATE
4. 4. 現在のサーバーレスアーキテクチャーの課題 ü ネックとなるLambdaの実⾏行行回数制限 ü Lambdaの実⾏行行が保証されていない(イベントが抜ける問題) ü 現在のcloudのDBは時間課⾦金金が主流流で性能を上げるとコスト増 ü オペレーションレスではなく、運⽤用でフォローができない＆モニタリ ングレスではない現場
5. 5. cloudpack⼤大阪のサーバレス開発/MSP開発チームでま ず考える事 ü 結合先は信じない ü Lambdaの制約 ü DBの選定 ü コンテナとEC2の違い ü EC2のとなりのサーバーレスである意味？ ü 運⽤用でカバーに⽢甘えれない
6. 6. 結合先は信じない ü 利利⽤用するサービスやシステムのトラブルやメンテナンスを設計レベル で対応 ü 接続できない場合のキューイングや、その後のリトライ処理理は必須 ü 接続先の処理理が遅い可能性があり、それにLambdaの処理理時間が取ら れると同時接続数の制限に引っかかるので、あえてタイムアウトさせ るのも必要
7. 7. Lambdaの制約 ü Lambdaの同時実⾏行行数制限(上限緩和申請の上限値は実績値によって増 やせる) ü 処理理時間を気にする(最⼤大5分だが１分以上かかるような処理理は分ける べき) ü そもそもLambdaが必要なのか(WEBの画⾯面を表⽰示するのに本当に必 要なのか？HTML&JavaScriptでできないかを設計レベルで考える)？ ü API  Gatewayのタイムアウトに注意(ファイルのアップロードとかは 単純には難しい ü 処理理の正確な実⾏行行を保証してないので、処理理が抜けた時の処理理を設計 レベルから実施する必要がある
8. 8. DBの選定 ü 基本マネージドサービスのDBを考える ü そもそもDBいるの？S3とかでいけるんじゃない？ ü Kintoneなどの外部SaaSのDBをAPIで叩いてアクセスする⽅方法もあり
9. 9. LambdaというコンテナとEC2の違い ü RESTfullなAPI設計ができればよいって話ではない ü ⼀一つのEC2にたくさんのAPIを⽤用意するのと、API   Gateway+LambdaでAPIを⽤用意するのは、前者はEC2が⽌止まるとシ ステム全部が⽌止まるので同期させなくてもいけるが、後者は⼀一つが⽌止 まっても他が動くので、⾮非同期処理理を同調させる仕組みを考える必要 があり、分散アーキテクチャーで設計する必要がある
10. 10. EC2のとなりのサーバーレスである意味？ ü 監視するポイントがサーバーレスで作ったシステム分増えるので、運 ⽤用を考えるとEC2側に寄せたほうがよいと個⼈人的には思う(開発的には EC2側のミドルウェアに引っ張られないので、ありかなとは思うけど その場合はEC2にコンテナを⼊入れたほうが良良いかなと)
11. 11. 運⽤用でカバーに⽢甘えれない現実 ü 今までは運⽤用メンバーが、なんとかシステムを維持してくれた(不不具合 のないプログラムや性能要件を完璧に満たしているような⼈人は本当に 少数。無意味なエラーログの垂れ流流ししてませんか？) ü サーバーレス開発は運⽤用メンバーがフォローしてくれない、全て開発 者に不不具合は返ってくる ü オペレーションレスかもしれないけど、実⾏行行されないかも含めてモニ タリングは必要 ü 運⽤用時に不不具合が発⽣生した場合でもリカバリー処理理を考慮した設計が 必要で開発コストが上がる現実(Sierなどで開発だけだとコンペに負け る現実)
12. 12. MBS動画イズム444とは ü 「MBS動画イズム444」とは、ドラマ、バラエティ、アニメ、スポー ツ、ドキュメンタリーなど、MBSで現在放送中の番組や、過去の名番 組を、インターネットに接続したPC、スマートフォンなどで視聴いた だけるサービス。 ü ⽉月額定額課⾦金金で全ての作品を⾒見見放題 ü 決済は現在クレジットカードと楽天ポイントに対応
13. 13. MBS動画イズム444のアーキテクチャ特徴 ü インフラ費⽤用はものすごく安価！ ü cloudfrontとS3による⼤大量量のアクセス負荷への耐性の確保 ü dynamodbすら使わない、AWSDBレス(S3とkintone) ü サーバーレスの監視もサーバーレスで。世界三箇所からの監視と Lambda防御⽤用WAF
14. 14. サーバーレスアーキテクチャ採⽤用理理由 ü ⽉月々のインフラ運⽤用コストを削 減するために『AWS   Lambda』を活⽤用したサーバレ スアーキテクチャを選択 ü サーバーレスアーキテクチャで はEC2が存在しないためインフ ラの運⽤用コストが削減可能 ü 不不正侵⼊入などのセキュリティリ スクが減ることについても⼤大き なメリットがある。
15. 15. ⼤大量量のアクセスに対応する仕組み ü ほとんどのWEBページを静的な 表⽰示でできるように設計されて おり、有料料会員以外はcloud   frontとS3のみでサイト表⽰示を 実現。 ü フロントでできる動作はフロン トで対応 ü Lambdaをできるだけ使わない ように設計が⾏行行なわれている ü SNSシェア表⽰示⽤用のキャッシュ データをJSONデータなどから 作成する仕組み
16. 16. 処理理時間が⻑⾧長いものに対する設計 ü S3のステージングから本番環境 へのコピーやS3のコンテンツの バックアップをLambdaでする 場合には、マスターのLambda とWarkerのLambdaに分けて、 ü マスターが各ワーカーの Lambdaをキックして処理理を⾏行行 う。
17. 17. 接続先がトラブルが起きていても⽌止まらない仕組み ü ミッションクリティカルな処理理は、キューイングされる ü kintoneのようなAPIの制限数のあるものに対しては、⼀一定の単位に蓄え て、APIでまとめて処理理を⾏行行う
18. 18. インフラ/開発の両コストを下げたバックエンドの特徴 (Kintone) ü kintoneによる素早い画⾯面開発 ü セキュリティ関連はkintoneで実現 ü CMSとして静的ファイルやサムネイル画像をS3にUPする仕組みを作 成し利利⽤用者に提供 ü CMSとしてステージング環境と本番環境を操作する仕組みも提供 ü コンテンツの公開制御もkintone側で制御可能
19. 19. おまけ)こういう構成にするともっと安く使えるKintone ü システム管理理者の部分を kintoneで作成(ユーザー に⾒見見えない部分はkintone でさっと開発) ü ユーザー側はサーバーレ スで開発(参照系の利利⽤用者 数が多い場合)
20. 20. MBS動画イズム444の運⽤用を⽀支える仕組み (モニタリングと障害通知) ü 世界三箇所からのモニタリング ü 監視間隔は５分(1分〜～5分で変 更更可能) ü モニタリングしているシステム 同⼠士も監視しあっている ü モニタリングシステムが冗⻑⾧長監 視であるのにもlambdaベース で監視インフラコストを下げて いる
21. 21. MBS動画イズム444の運⽤用を⽀支える仕組み (不不正アクセス対策) ü 不不正アクセスによるLambdaの実⾏行行回数制限 などを狙った攻撃への防御対応 ü ⼀一分間間隔で不不正を検知し不不正IPをブロック ü 実はこの機能も世界三箇所から実現
22. 22. まとめ ü サーバーレスで作るには処理理が抜けた部分を考慮する必要がある ü サーバーレスはオペーレーションレスではなく、運⽤用でカバーできな いので開発で運⽤用までを考慮する必要がある ü サーバーレスはモニタリングレスではないので、ちゃんとモニタリン グする必要がある。 ü Lambdaの同時実⾏行行回数制限を意識識して開発を ü サーバーレスはインフラ費⽤用は安くなるが開発⼯工数が⾼高くなる。開発 と運⽤用のコストをトータルで考えないと導⼊入できない ü サーバーレスサーバーレスという前に、⾃自分達が今まで開発してきた ものが本当に運⽤用に耐えれてたのかを考えて、結果⼤大多数の開発者は 運⽤用してくれているエンジニアに感謝の気持ちを持つべきと思う。そ れができないエンジニアはサーバーレスで⾃自分の作ったものの品質に 殺されます汗