Serverless Tech/事例セミナー（2019年3月27日 実施） レポート Vol.3

2019年3月27日 実施のセミナーのレポート 3部編の Vol.3 です。他の回は以下のリンクよりアクセスください。

Vol.1 : 手段先行でも悪くはない！Ruby on LambdaではじめるServerless
Vol.2 : Ruby on Lambdaで変わる大規模サービスの裏側
Vol.3 : Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方 [本記事]

Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方 [資料はこちら]

クラスメソッド株式会社 和田祐介氏

これまでの EC2 ベースでの開発からサーバーレスに向かうと、どこに戸惑いがでるのかを自身の経験から説明いただきました。サーバーレスにこれから向かう方にはもちろん良い情報ですし、すでに経験ある方にも共感が持てる内容でした。

サーバーレス流での戸惑い

かつて、Scala、Play Framework での開発を中心に担当しており、その際にあることがきっかけで最初にサーバーレス/Lambda と関わったとの紹介がありました。それは担当されていたシステムに対するログインフォームへ DoS 攻撃がおこなわれたことにより、その対策を行うことが必要になったという経験です。その対策として CloudWatch Logs から DoS アクセス IP を割り出し、Lambda で WAF に動的設定したという経験で、2人で 1 日で開発が終わり、翌日には運用導入することができました。これが講演者の最初のサーバーレスの事例で、今も問題なく動いているとのことです。サーバーレスの威力を感じ（第 1 フェーズ）、その後、サーバーレス開発部へと転属。比較的小さめのプロジェクトを経て、徐々にサーバーレス開発で考えるべきことを認識し始めています（第 2 フェーズ）。そして、その後、LIXIL 様のスマート宅配ポストサーバーのプロジェクト（ちょうどセミナー当日に事例として公開）に参画しました。サーバーレスのプロジェクトとして初めてのチーム開発や外部ベンダーとの連結が必要となる本格的なプロジェクトになります。

そこで経験した色々な戸惑い/課題は、きちんと整理して考えると、あるものは EC2 ベースでの従来型開発でも起こっていたことであり、あるものは少し違う形の課題になっていることが見えてきました。

従来型の方式との整理

例えば、コーディング環境。Lambda では、Python な どを使えば、マネジメントコンソールでちょっとした開発ならできてしまいます。そのため、小さなプロジェクトや PoC では何も用意しなくても実現可能です。 その後、それなりの規模のプロジェクトになって初めて、その開発のやり方では無理があることに気づくわけですが、それは従来型なら当たり前のこと。このように、最初の入り口が入りやすいがゆえに、後になっていろんなことに直面して戸惑う、というわけです。

結果、よく考えてみれば、従来型開発でも同じように考えていたことを単にやっていなかっただけなこともあれば、サーバーレス固有で考えるべきこともありました。例えば、システム単位というより機能単位での見方・考え方になるため、テストやプロジェクトの進め方をどう考えるかは変わってきます。また、サービスごとにある制限事項などの考慮も必要になるので、テストにおいて、End-to-End でのテストを実施して制限事項が影響しないかを早めに確認すべく、AWS 環境に商用と同等の制限を加えた試験をすることなど具体的な解決方法を説明しました。その他の工夫として、複数開発者で成果物を理解しやすくするためのフォルダ分けやネーミングのルールをテンプレート化したことなどを紹介しました。

また、自身の経験としては、開発はフロントからバックまで機能ごとに一人の人物に割り当てるとコミュニケーションコストが少なくて良いなど、これまでの EC2 での開発とは異なる人員配置の考慮も検討に値すると言及しました。 例としてドメイン一つにつき一人の開発者を割り当て、ドメイン分割を前提とした開発のやり方の提案がありました。最後にベンダーロックインについての考えも話されていましたが、ロックインされないように気を使うより、サーバーレスの良い部分を最大限に生かすようにするのも判断の一つだとの説明がありました。

最後に、本セッションの資料はこちらからご覧いただけます。

【補足】

最近よくご紹介している立場別のサーバーレス関連の情報 Web ページのうち、エンジニア/開発者向けのページ（右）では、このセッションでも指摘された開発環境やフレームワークの情報も記載されており、 プロジェクトを進めるにあたっての見落としがないか、チェックする意味でも有用かと思います。

プロジェクト責任者向け	アーキテクト向け	これから始めるエンジニア向け
ビジネス価値、事例、効果	ユースケースパターン	今から始めるサーバーレス

サーバーレス事業開発  杉