ServerlessConf Tokyo 2018 のLTで発表した資料です

1. クラウドパートナー 中山 桂一
nakayama@chara-web.co.jp
メテオフォール型開発
Ｘ
サーバーレース開発

2. 中山桂一
所属： 株式会社キャラウェブ
クラウドソリューショングループ
ソリューションアーキテクト
役割： クラウド導入コンサル
ソリューション設計、プロジェクトマネジメント
自社関連サービスの開発
→最終的に自社IT部門の何でも屋
好きなAWSサービス：
・AWS Lambda
・AWS CloudFormation
・Amazon API Gateway
・AWS Systems Manager
k1nakayama

3. メテオフォール型開発
■ メテオフォール型開発とは
日本の古き悪しき伝統文化といっても過言でないだろう開発現場でよく見られる（特に中小企業）光景を表し
たもの。
・開発スケジュール、リリース日等のスケジュール全般について、組織内で力をもった人（たち）からの圧力や
指示により勝手に決まり、都合によりプロジェクト期間中に変更がされていく
・開発中に仕様が変更されていく
・組織内の力をもった人（たち）の独断で様々な決定がされ、直前などに
その事実をプロジェクトチームに知らされる
→ どのような場面においても、開発チームは“神”の指示に従わざるを
へず、仮に対抗したとしても全くの無意味であり時間の無駄である
ケースが多い
メテオフォール型開発： http://eiki.hatenablog.jp/entry/meteo_fall
※本スライドで使用している画像等の使用は@eiki_okuma さんから許諾を頂いております

4. サーバーレスを採用した場合

5. 短期間での開発を要求された場合
 従来の開発の場合
 開発環境の構築などコーディング以外の作業に時間を取られる
 複数人での開発は進めづらく、マージやデプロイで問題が起きやすい
 サーバーレス開発の場合
 実行環境はAWS Lambda等のFaaSを使用し、Microserviceな構成でシステムの実装を行う
 開発を進める上での開発環境（開発中用のAppサーバ等）を用意することは必要ない
 Function単位で実装を進めることができるため、複数人で構築を進めやすい
 サービス単位にAPIを用意し、Swaggerとサービス毎のCI/CDパイプラインを作成
 Swagger + CI/CDを外注先に委託することで、開発体制を水平スケールさせることができる

6. 度々発生する仕様変更
 従来の開発の場合
 システム全体が密結合である場合、一部に対する変更もシステム全体に影響しやすい
 場合によってはミドルウェアへ等のサーバ環境上の変更が必要なケースが発生する
 サーバーレス開発の場合
 Microserviceな構成によりサービス間は疎結合となるため、変更への影響が少ない
 既存の機能への変更の場合、API上の一部のリソースに対する変更を行うことで対応ができる
 APIのリソース単位でFunctionを構成することにより、変更時の対応が柔軟に行える
 新規機能の追加の場合、サービスを追加し、関連するサービスのAPIに修正を加えることで対応が行える
 API, Function等のサービスを構成する個々のリソース単位に環境設定を変更することが出来る

7. 予測不可能なトラフィック
 従来の開発の場合
 “神”の思いつきによって動き出したプロジェクトの場合、実際に“神”が思い描いているようなトラフィックは
発生せず、ローンチ当初から過剰なリソース用意した結果、サーバ代が膨れ上がり、理想とは程遠い収益
（損益）となり、その原因がサーバ代にある（開発チームの管轄する問題）として雷が落とされる
 “神”が独断で進めた広告出稿等により、想定していないトラフィックが急に発生し、高負荷対応に追われ、
しまいにサービスがダウンする
 サーバーレス開発の場合
 バックエンドで利用する各サービス（Lamba / API Gateway / CloudFront / S3 etc...) はオートスケーリング
され、利用した分だけの支払いのため、コストが最適化されやすい
 予測不可能なトラフィックに対しても概ね柔軟なスケーリング対応が自動的に行われる

8. ローンチ後の保守・運用対応
 従来の開発の場合
 ローンチすると“神”は当該プロジェクトに対する運用について考えず、保守・運用をするチームが別で存在
しないにも関わらず、新たなプロジェクトや新機能の開発を指示する。
 別プロジェクトの対応にリソースが割かれるため、運用中の障害対応や、脆弱性等に対するメンテナンス対
応が付け焼き刃的な対応になり、悪循環を生む
 サーバーレス開発の場合
 マネージドサービスで構成されているため、原則としてオートスケールされ、従来は度々発生しがちだった
高負荷による障害対応については、“高負荷”としての障害は発生しない
 脆弱性等のセキュリティに関する更新対応は、マネージドサービスとしてクラウドベンダーが対応してくれる
ため、日々のルーチンで対応を行う必要がない
 多くのサービスについてDDoS攻撃等への対策も盛り込まれているため、設計次第で運用後のリスクを軽
減しやすい

9. まとめ
 メテオフォール型開発を強いられる現場において、サー
バーレスは正義
 “神”には逆らわず、柔軟な対応を行うことで“祈り”を届け
やすい雰囲気をつくる
 中小規模の企業でもマイクロサービスアーキテクチャは有
効であり、強い味方になる

10. 最後に…
本スライドで扱った“メテオフォール型開発”やその問題点等は、所
属する組織とは何ら関係はありません。
弊社では一緒にサーバーレス開発を行い、様々な“神”に対応する
術を身に着け、メテオフォール型開発を行っている組織をも幸せにし
ていく仲間を募集中