この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
「何やってる部署なの？」と社内外問わずよく聞かれるのでブログで回答します。
要約
現在十数名の規模で、
- AWS IoT や API Gateway とそのバックエンド
- Angular による SPA
をメインに 開発 しており、コンサル や 運用保守 はまだ多くはやっていません。サーバーレスアプリケーションの構築については部でかなりノウハウもたまり、実現できることも増えてきましたが、モニタリング、ロギング、高負荷アクセスあたりはこれからで、一緒に開発するメンバーを募集しています。
AWS のマネジメントサービスを駆使して、アプリケーションを構築します
部が立ち上がる前、旧AWS事業部（現AWS事業本部）、モバイルアプリサービス部などで、サーバーサイドアプリケーションを構築する際、一部サーバーレスで構築したものがありました。そうして、作ったものとノウハウがたまっていき、また、世の中のサーバーレスに対する熱の高まりも相まって、サーバーレス開発部が創設されたのだそうです。詳しいことは 大橋 に聞いてください。ブログもあるようです。
開発者の視点でいくと、フルサーバーレス というのは、MySQL や PlayFramework などのミドルウェアを使うのと同じくらいトライアンドエラーが必要だなと感じています。AWS のマネージドサービスは間違いなく便利です。よくもまあここまで昇華するもんだなと、日々感心しっぱなしです。一方、道具である以上、できること・できないことをいちはやく把握する必要があります。それがそのまま、アプリケーションの機能要件・非機能要件へダイレクトに関わるためです。要件から設計にすんなり入れることはほとんどなく、たいていの場合、間に検証を行って要件にフィードバックするというサイクルを回すことになります。 開発者も、マネージャーも、そして顧客も、この段階の検証が必要だと認識することが、サーバーレス開発のはじまり といっても過言ではないと考えています。
このあたり、目的と手段の取り扱いが難しいですが、基本は「まずAWSのフルマネージドサービスで完結できないかを考える」方針としています。
どんなものを作っているの
API Gateway、Lambda、DynamoDB を使ったオーソドックスな Web APIサーバーを作ったり、最近は AWS IoT を前段においての IoT バックエンドを構築したりなどです。また、セットで管理画面を作成することも多く、それは Angular による SPA で実現することが多いです。イメージ図で書くと以下。
どんな感じで開発しているの
顧客とのコミュニケーション
まず何をやるにしても、お客様とよく話す必要があります。フルマネージドサービスを使う場合、どう頑張っても絶対に現時点では実現できない要件が出てきますし、AWS の制限にひっかかる場合もあります。そこをよく話して、落とし所を定めることが大事です。
とはいえ、最初からすべての要件、AWSサービスの機能、AWSサービスの制限を照らし合わせて落とし所を完全に決めるのは不可能です。少なくとも私は無理です。正直に話をして、検証するための時間をいただいたり、定期的に振り返って、成果物ベースで不明点を解消していくといった進め方ができないか相談するという手もあります。
サーバーサイド
AWS Lambda をはじめとしたマネージドサービスを組み合わせて構築しています。Lambda Functionは、 Python3.6 で書くことが多いです。これはドキュメントの充実ぶりであったり、Python3系が今後割と長く使えそうという点からです。ですが、私自身は、いつか Scala を使ってやろうと思っています。
デプロイはほとんどの場合 AWS SAM および CloudFormation を使っています。Lambda Function のPython を書くのと同じくらいの分量、 AWS SAM テンプレートや Swagger を書くこともあります。
サーバーサイドアプリケーションは REST API のために構築することも多いですが、最近は AWS IoT で IoT Topic を通じてデバイスと接続する機会も増えてきました。クライアント証明書の取り回しであったり、Thing Shadow を介しての状態の授受であったり、学ぶことは多いです。
サーバーサイドについては岩田やK.Nakayamaがよくブログ記事を書いていますので、覗いてみてください。
- グラフ型データベースAmazon Neptuneでレコメンデーション検索を試してみる(前編)
- Lambdaを使わずにS3にPutされたCSVファイルをRDSに自動一括登録する
- How to Invoke AWS IoT Actions Only When a Reported Value Has Been Changed
クライアントサイド
管理画面のSPAを組んでいます。今のところAngularを使っています。
Angularを使っている理由ですが、私自身特に強いこだわりはないです。が、現在のサーバーレス開発部は、開発メンバー2,3人、少ないときは1人でプロジェクトを回すこともあります。そんな中、お客様と会話しつつ、サーバーサイドも開発している中で…
- React + Redux がイケてるよね
- Webpackの書き方はこう
- Vue.js というのもなかなかいいらしい
- Babelがね
- テストツールどれ使うか
ということを考えている余裕がありませんでした。 Angular であれば、フレームワークとして Typescript をサポートしていますし、プロジェクトを作れば Karma で Unit Test を、 Protractor でE2Eテストの準備を整えてくれます。また、最終的に SPA の形に変換もしてくれます。素晴らしいのは、これらをすべて ngコマンド として実行できる点です。ツールの選定や組み合わせのための設定にかける時間を大幅に削減でき、SPA 開発に集中することができました。
さらにもう一点。Angular が採用している Service の考え方がサーバーレスアプリケーションと相性が良かったというのもあります。ほとんどの場合、SPAの裏にはAPIが居ます。それらのAPIをコールしたり、レスポンスを加工する処理を、Service へ隠蔽することができます。画面構築のためのロジックと、サーバー通信のロジックを明示的に分けられる点も良いと思ったポイントでした。
ただ、このまま未来永劫 Angular を使いつづけるとは思っていません。いまは自分たちで手を広げる余裕がないので、React.js や Vue.js の使者を乗せた黒船をいつでも待っています…。
Angularをはじめとしたクライアントサイドについてもサーバーレス開発部でいくつか記事を上げています。今後も増やしていきたいですね。
何を目指すの
部としてはサーバーレス開発実績No1を目指します。いまは開発業務をメインにすえてノウハウをためます。個々人のAWSを使ったサーバーレスアプリケーション開発スキルは、確実に上がっています。
私個人は、サーバーレスアプリケーションの開発スピードをもっと上げたいと思っています。また、サーバーレスアプリケーションの全体をひとつのアプリケーションとして捉えたときに、既存の設計手法・設計思想を適用していきたいと思っています。例えば CQRSであったり、ドメイン分割であったり、といったものです。あと、どうにかしてサーバーサイドにScalaを入れ込みたいですね。
サーバーレス開発部の課題は？
開発視点になっちゃいますが、以下です。
サーバーレスアプリケーションの運用ノウハウはこれから
作りきりのものであれば大きな問題はないですが、せっかくサーバーレス高可用なバックエンドを構築できるので、ビジネス要件の変化にも追従したいところです。2017年末に立ち上がった部署というのもあり、このあたりがまだ手探りという感想です。具体的には、
- KPIとなる情報の収集
- ビジネスの変化に対する対応
- 異常の検知・修復
といった点の、サーバーレスアプリケーションにおけるベストプラクティスを模索しています。仮設や学んだことは、積極的にブログ化していきたいですね。
| 著者 | 記事タイトル |
|---|---|
| 新井 | AWS SAMでAPI Gatewayのリソースポリシーを設定してみた |
| 新井 | Lambdaが異常終了した際にアラート通知させる仕組みをAWS SAMのテンプレートで一括デプロイ |
| 丹内 | Gatlingで負荷試験をする |
| 夏目 | Web Application向け(?)エラートラッキングツール Faultline の紹介 |
Python と Angular に寄っている
言語やツールは選択肢があると良いと思いっています。これらでもサーバーレスアプリケーションの構築自体は問題なくできますが、もう少し選ぶ余地がほしいです。お客様によっては言語やフレームワークを希望される場合もあるためです。具体的には、Lambda Function は Node.js、SPA は React.js でも構築できるようになっておきたいという思いがあります。
「アプリケーション」という観点での組み立てスキルをもう一段階あげたい
サーバーレスアプリケーションです。アプリケーションなので、設計が必要ですし、追加修正を考慮したコード構造にしておく必要がありますし、ログから事象を追える必要があります。マネージドサービスの台頭で、アプリケーションの組み上げ方は大きく変化しましたが、全体として求められるものは変わりません。具体的には、Lambda Function をただサービスの糊付けの道具として使えるところもあれば、ビジネスロジックが入ることもあります。仕様変更があたっときに、安全に修正を行うために影響を最小限に抑えるためには、ビジネスロジックを切り出しておくということも必要だと思います。また、サーバーレスだからといってテストをしなくて良いということには絶対になりません。Unit Test をどこまでやるか、ローカルに立ち上げられない AWS IoT のようなサービスを 使っている場合、どのようにテストを行うか、まだまだ議論の余地があると思っています。
ところでリモートワークは？福利厚生は？
福利厚生については、クラスメソッド株式会社の福利厚生を余すところなく受けられます。私も、2018年2月に育休をいただきました。
また、サーバーレス開発部はメンバーが各拠点および自宅（東京、大阪、岡山、福岡）に散らばっています。会議・開発業務などすべてがリモート前提になります。私は週一くらいの頻度で自宅でリモートワークしています。
詳しくはこちらを参照ください。
また、リモートワークについては、サーバーレス開発部メンバーの 阿部 が お天道様に見られている気分でサボれない と言っています。ブログ記事をみてみてください。
興味あります！でもサーバーレス開発ってやったことない…
ありがとうございます。スキル面ですが、そもそも今、「サーバーレス開発やってました」という人自体が少ないので、サーバーレス開発自体の経験は問いません。私自身、もともとモバイルアプリサービス部でサーバーサイド開発をやっており、その中でサーバーレス開発を開始した経緯があるので、特に問題ないと思っています。ただ、
- AWS でインフラを構築できる
- サーバーサイドアプリケーションを開発できる
- フルマネージドサービスを使ってアプリを作ったことがある
このあたりのスキルがあると、違和感なくサーバーレス開発を開始できると思います。あと何より、未知のサービスを使って開発することを楽しめることができると、ゴリゴリにスキルアップできます。
その他質問があれば
このページにある問い合わせフォームからでもいいですし、私に直接聞いてもらっても良いです。
2
