こんにちは！Diverse広報担当です。
先日、Diverse Meetup #1となる『Cloud Functionsを開発担当が徹底解説！』を開催しました！
マッチングアプリHOPの開発に携わる村本章憲さんがご登壇。Cloud Functionとは何かという基本的内容から、参加者からの高度な質問への回答まで、たっぷり1時間かけてお話いただきました。
（開発の合間にご登壇頂いたので相当お疲れだったようです...お忙しいなか有難うございました！）脳が開発モードだと上手く喋れない😇
— nori 村本章憲 (@1amageek) January 18, 2021
メモリが開発に持ってかれてる。
参加者からも好評の声を頂きました
ちなみに本題に入る前に、今回イベントに参加いただいた方から嬉しいコメントを頂いているので、ご紹介したいと思います。
疑問に思っていた部分など、
— 宮前優哉@人事/Reckoner/Relance (@yuyamiyamae) January 18, 2021
丁寧に説明していただきありがとうこざいました！
とても勉強になりました！ https://t.co/ZWetUGW9xM
周りがエンジニアの方々なのでビビってしまって質問出来無かったけど、他の方が質問されていたことも含めて自分にとってめっちゃ勉強になった。
— きなこ (@kinako0626r) January 18, 2021
やっぱりこういう話を聞くのはすごく好きだ。
今回参加出来てよかった。
村本さん(@1amageek )ためになるお話していただき、ありがとうございました！
Diverse Meetupは第二回、第三回と続ける予定ですので、今回参加できなかった方も、次回ふるってご応募くださいませ！ちなみに第二回は現在募集を開始しています（2021/02/17開催予定） diverse.connpass.com
それでは、ここからはイベントの前半の模様、主にクラウドファンクションの基礎理解を余すところなくお伝えします！
当日の資料と動画を共有します
残念ながら当日参加していただけなかった方のために、資料と動画を公開させていただきます！
イベントルポを大公開します
ここからは、当日のイベント（前半）のエッセンスを文字にまとめています。「動画を見ている時間がない！」「要点だけサラッと理解したい！」という方はこちらをご覧ください！
クラウドファンクションとはなにか（00:00）
村本 章憲（以下、村本）：ひとことで言うと、サーバーレスフレームワークです。
Firebaseの中にあるCloud Firestoreと連携したり、HTTPのプロトコルを叩けたり、Pub/Subで スケジューラーでクラウドファンクションを立ち上げたり。メールなどのGCPとはもちろん繋がりますし、AIやAWSにも繋げることができちゃいます。
何とでも繋がる便利なファンクションなのが大きな特徴ですね。
また、オートスケールするので、インフラの知識がそこまで必要ないのも特徴です。
サーバーレスのメリットとは（01:29）
村本：運用がとにかく楽です。
インフラを整える時に「サーバーのインスタンスを立てて」とか「ロードバランサーを」とか考えなくていい。ファンクションだけデプロイすると、あとはFirebaseがやってくれるんです。
また、原因の特定も楽です。見る範囲がファンクションに留まるので、どこで問題が起きてるのか悩まずに開発できます。
あとは安いですね。Firebase全般で「料金どうなんですか」って聞かれることが多いんですが、とにかく安いです。
プラットフォームを横断的に開発できるというチーム運用上のメリットもあります。
質問）実行時間の制限にはどう対処すべき？（03:26）
参加者：クラウドファンクションで重い処理や重いバッチを実行したいのですが、実行時間に制限がありますよね？その場合はどのように運用されていますか？
村本：取れる方法は二つです。ひとつ目の方法は、メモリの量を増やしてタイムアウトの時間を延ばすこと。
ただそれだと、一つのクラウドファンクションに能力が依存します。確か限界（4GBくらいまで？）が決まっていて、それに収まらない場合は別の方法が必要です。
それがふたつ目の方法、分散化させること。
例えばPub/Subでスケジューラーを夜の12時にセットして、そのスケジューラーが起動したらさらにPub/Subがパラレルで複数のクラウドファンクションを叩くようにしています。複数用意してそれぞれのタスクを分散させるんですね。
クラウドファンクションで困ることとその対処法（05:06）
村本：３つ挙げてみました。今回はこの辺りを説明します。
村本：DDDって知ってますか？ドメイン駆動開発といわれるものです。
[DDD]ドメイン駆動設計の定義についてEric Evansはなんと言っているのか - Qiita
ドメインとは、問題解決のために物事の特定の側面を抽象化したもの。僕はざっくり「要らなくなったら消せる単位」と考えてます。
チャットというドメインがあったとして、サービスにチャットが不要になったら消せるじゃないですか。そういうドメインの大きさ、機能の塊の大きさみたいな感じです。
参加者：アカウントはドメインには入らないのですか？
村本：アカウントを管理する機能があったとしたら、それは一つのドメインになります。
ドメインを大きな機能と捉えてもいいです。新しい機能を追加するとき、ドメインも追加しとくかな、みたいなイメージを持つといいですね。
ちなみにこれは、クラウドファンクションズの中のディレクトリ構造をツリーで表示したものです。
functionsの下のfunctions_0とfunctions_1が、僕がいうドメインの話です。
チャットの機能はfunctions_0に、アカウント管理に関してはfunctions_1に、と管理します。こうすれば、functions_0が要らなくなったらディレクトリごと消せるんです。
さらに下には、versionというものを管理してます。例えば、チャット機能をversion1でリリースしたけど、新しい機能を追加しなきゃいけなくなって、今のスキーマだと壊れちゃう。そういう場合、version2にして新しいファンクションズを用意し、そのversionの下にFirestoreのトリガーを書いてます。
サンプルとして、次に行ってみましょう。
ソーシャル機能（いいね）はこう作ります。
index.tsのなかにはこう書きます。
こうすることで、Firestoreの構造でアクションが作られた、消された、まで一貫して管理できます。
さらにこれ、何がいいかっていうとですね...
actionsは、下のファイルから取ってきてエクスポートを重ねます。
こうすると...
これがFirebaseのクラウドファンクションのデプロイコマンドです。
今回のソーシャル機能だけをクラウドファンクションにデプロイすることができます。さらにドットで繋げていくと、ソーシャルのV1の機能だけデプロイする、またはV1のその下のusersだけデプロイするなど細くデプロイを切ることができます。
ファンクションの数が増えて、デプロイ時間が大きくなると運用が大変になります。
本番環境ではなく開発環境であったとしても、みんなが一緒にFirebaseデプロイを叩きまくると次から次に上書きされちゃうのでうまく開発ができません。しかし、ドメインを切る、さらにファンクションを細かく切ることで、運用がとっても楽になります。
さいごに
お読み頂き有難うございました！
前編のイベントルポはこれで終了です。後編もまもなくUPするので、ぜひご覧ください！
なお、Diverseはこのようなイベントの他にも各所で情報発信を行っています。興味のある方はぜひ覗いてください！
