PaaSが昔からあるのにLambda+API GateWayが出てサーバレスアーキテクチャーが、もてはやされ出してから時間が経ち、BOT作成人気もあってLambda+API GateWayで試してみた系の話が多くなってきましたが
運用するにあたって考慮すべき話が出てこないので、Lambdaで実現したプログラムを
実際に運用してみて引っかかったり、問題になった部分をちょっと書いてみます。
ちなみにサーバレスアーキテクチャーの記事は
や、弊社が出しているLambdaの開発者向けホワイトペーパーは
からダウンロード可能ですので是非みていただければと思います。
考慮する点ですが、運用してみた中で、?と思った件があります。
開発時に設定や実装ミスなどもありましたが、エラーが発生せず、
イベントが発火しないケースが存在しました。
問い合わせ時に参考にする記事もあるので一読されることをお勧めします。
クラウドではインスタンスが落ちても良い設計をするという話がありますが
サーバレスアーキテクチャーな設計では、エラー時の処理はもちろんの事、
イベントが発火しなかった場合のリカバリーする方法を設計しておく必要があります。
具体的にはイベントが発火しなかった場合、スケジュールの処理などで発火しなかったも
のを救うなど。
それならいっその事スケジュールの処理で全てすくえば良いって話もありますが、ある程
度リアルタイムかつ効率良く処理させれるイベントドリブンな処理は魅力ではあります。
SLA100%ではない現状では、動作しなかった時の検知方法とリカバリー処理は是非とも
考えておいたほうがいいです。
※IaaSで実施していた場合も、本当はいろいろあったのですが、
※監視方法などが確立され、監視システムのスクリプトなどを
※うまく活用して運用してきたのですが、サーバレスアーキテクチャーは
※まだこなれてないので、スタンダードな手法がまだ確立されていないのが現状だと思います
またシステムの重要度にもよりますが、
Lambdaのメモリ使用量や処理時間などのリソース監視に関しても、注意を払う必要が
あります。
少しずつメモリ使用量や処理時間が増えていって、ある日突然リソース不足でひたすらエ
ラーに陥いり、あとでリカバリー処理が大変にならないためにも日常のリソース監視
も考える必要があるケースもあります。
あとエラーの通知などもよくよく考えずに実装してしまうと、
運用の方がいない場合は開発者の一人24365運用が始まったりします汗。
IaaSなどに比べ、開発者にとって、さらにお手軽に実装できてしまう、
PaaSやLambdaですが、運用を考慮した設計と実装を行わないと、
今まで運用している方に押し付けてきたプログラムの未完成さが
フィルターなしにそのまま返ってきます。
サーバレスアーキテクチャーやPaaS以上が主流になれば
インフラエンジニアや運用する人は、いらなくなるって極端な話もありますが、
インフラエンジニアや運用してくれる人が、もしいなくなれば、
運用を考慮できない開発エンジニアもその後に淘汰されるってのが
サーバレスアーキテクチャーの案件や、MSP向けのサービスを開発し
運用してきた自分の今の意見です。
サーバレスアーキテクチャーで言葉だけではないDevOpsが理解されるようになればと思います。
