MBC CQRS サーバーレス フレームワーク の採用技術 1

運用サーバーについて

以前は自社にサーバーを建てたりVPSを借りたりしていましたがミッションクリティカルなシステムをやり出す事となりAWSを採用することとなりました。
サーバーの運用費用に関してはVPSを借りていた事態と比べると格段に高くなりましたが、優秀な技術者を一人雇う費用と比べると安く確実にサーバーの運営が出来るようになりました。
どうしても費用的なものに目が行ってしまいがちですが、頭を切り替えて優秀なパートナーを雇っているという感覚で情報システムを構築していくとシステムに対するコスト意識も変わってくると思います。
将来的にはAWSだけではなくAzureやGCPにも適用できるフレームワーク作りを考えていきます。

言語について

MBC CQRS サーバーレス フレームワークの採用言語はTypescriptとしました。
今まで作成していたフレームワーク .NET Framework, PHP, Python とありましたが、フロントエンドをJavascriptで開発をする事になりSPA+APIで運用することが多くなりました。
フロントエンドもNuxt.JSからNext.JSに乗り換えて本格的にTypescriptを使用するきっかけとなり、フロントエンド及びバックエンドでTypescriptを使って管理する方が便利だということとなりました。
環境構築について、以前は独自サーバーを建てて環境構築する時にはAnsibleを採用していたこともありましたが、AWSを使用したときにCloudFormationを使用していましたが、CDKでTypescriptで行える事となったため、ほとんどのソースがTypescriptで統一されるようになりました。

設計思想: 結果整合性・楽観的ロック

一度に大量のデータの更新や読込でシステムがロックされてしまいダウンすることがないようにデータの書き込みと読込を別のDBに行なうCQRSパターンにてシステムを構築していくこととしました。
CQRSパターンではデータを更新するためのコマンドとデータが分かれておりますが、ある瞬間を切り取るとコマンドがデータに反映される寸前と言ったことはあり必ずしも正確な状態を現しているものとならないですが、最終的にコマンドが全て反映された結果整合性がとれたデータがデータベースに蓄積されるようになります。
読み込み用データと書き込み用データが分かれたためスケールはしやすくなりデータがロックされてシステムがダウンされるようなことは減少します。
ちなみに結果整合性には強いインフラへの信頼性が重要です。そのためクラウドでもマネージドサービスを使って管理をすることが重要な要素となります。
結果整合性を保つためにはコマンドの受付が正しく行われるかが重要なためコマンド自体にはバージョン番号を付与し、新しいコマンドを受け付ける際には現在のバージョン番号+1のものがPOSTされてきたかどうかチェックする楽観的ロックを採用します。

Nest.JS

バックエンドフレームワークのコアとなるフレームワークはNest.JSとしました。
Typescriptで開発出来、依存性注入(DI)が出来るのが良さそうです。フレームワークとしては拡張性を持たせたいし、テストも出来る限り実装しておきたいということでMBC CQRS サーバーレス フレームワークではNest.JSを採用しました。

AWS Lambda

MBC CQRS サーバーレス フレームワークの実行基盤としては主にLambdaを採用します。使用量に応じて課金となるため初期段階での費用は格段に抑えられるようになります。
また、サーバー自体の管理を行う必要もなくセキュリティ的にもロールで定義した範囲内の事しか出来ないため非常に堅固なシステムを構築することが可能です。
システムが徐々に本格的に稼働しLambdaの費用が高くなって来た際にはECSにシフトチェンジすることも可能です。

AWS DynamoDB

CQRSモデルの主なデータソースとしてはAWS DynamoDBを採用します。
Key-Value型のDBであるため比較的自由にスキーマーを定義できます。サーバーレスアーキテクチャであるため、使用量に応じて課金されますが自動スケールが可能で場合によってはグローバルテーブルレポリケーションも可能です。
イベント駆動アーキテクチャとしてDynamoDB Streamsが使用出来るため、コマンドテーブル → DynamoDB → データテーブルと言ったデータ連係を行なう事が出来ます。