aratana Tech blog

ECテクノロジーで 世界をもっと楽しく もっと笑顔に

aratana gatewayとServerless

こんにちは、サーバーレスエンジニアの中島です。

先日、aratana gatewayというサービスをリリースしました。 どんなサービスかはリンク先を見ていただくとして、aratana gatewayで使用している技術について、説明をしたいと思います。

aratana gatewayは、APIベースのサービスになるのですが、全面的にServerlessを用いて設計、開発を行いました。

aratana gateway×Serverless

Serverlessとは

Serverlessとはなにかという明確な説明が難しいですが、AWSでの定義は以下となります。

サーバーレスコンピューティングにより、アプリケーションとサービスを構築して実行する際に、サーバーについて検討する必要がなくなります。サーバーレスアプリケーションでは、サーバーのプロビジョニング、スケーリング、および管理は必要ありません。サーバーレスアプリケーションはほぼすべてのタイプのアプリケーションやバックエンドサービス用に構築でき、高可用性を実現しながら、アプリケーションの実行およびスケーリングに必要なことをすべて自動的に行います。

引用元:サーバーレスコンピューティング|AWS

一言で言えば、サーバー管理をしないで済むってことになります。

使用したものたち

AWSサービス群

  • Lambda
  • API Gateway
  • SQS
  • DynamoDB
  • Cognito
  • S3
  • Elasticsearch

など、他にもデプロイ周りでCloudFormationやCodePipeline、ログ周りでCloudwatchなど使ってますが、書き始めるとキリがないので、このくらいで。

上に並べたサービスのうち、ElasticsearchはServerlessのサービスではないです。 Elasticsearchを使っている理由は、DynamoDBでは難しい検索機能を実装するために使用しています。

言語

Python

主にAWS Lambdaを使用して開発を行っていますが、言語としてはPython3を使っています。 理由は、消去法でした。1年位前に開発を始めたんですが、当時Lambdaで使用できる言語が、JavaJavaScriptPythonくらいしかありませんでした(その後、Golangなど使える言語が増えてます)。

この中でどれを使うかというのを開発メンバーで検討したところ、

  • JavaはLambdaでの動作が遅いという情報があった
  • JavaScriptは進化が早すぎる(Nodeのバージョンがガンガン上がる)のでメンテし続けるのが難しそう

という感じで、残ったPythonでいこうということになりました。 Python2ではなくPython3にしたのは、0から実装するのにわざわざPython2を選択する必要はないだろうというだけで、特別な理由はありません。

フレームワーク

Serverless Framework

フレームワークとしてServerless Frameworkを使用しています。 実装始めた当初はAWS標準のSAMを使用したりしていたんですが、ちょっとずつCloudFormation周りがつらくなっていったので、Serverless Frameworkを使用することにしました。

Serverless Frameworkを使うことで、stageの管理やイベントの管理がだいぶ楽になりました。 また、pluginが豊富なので、Serverless Framework単体で解決できない課題をpluginで解決できることが多かったので助かりました。

例えば、Pythonで実装していますが、一部のPythonライブラリはコンパイルが必要となるケースがあります。 そのため、Lambdaにアップロードする際は、Lambdaの環境に合わせてコンパイルしておく必要がありますが、それはserverless-python-requirementsというpluginを使って実現しています。

Serverless Frameworkを使うことの辛みもありますが、トータルでは利便性の方が上回っている印象です。

設計手法

DDDとレイヤードアーキテクチャをベースに実装してます。

ただ、ここについては試行錯誤を繰り返しながらやっていて、実装初期は作っていたコードを翌週にまるっと書き換えるくらいのこともしていました。

現時点でも、ベストではないですし、改善を繰り返すしかないので、テストコードを書きながらリファクタできる状態を保つように心がけてます。

プロジェクト管理

ZenHub

プロジェクト管理ツールはtaigaを使ったり、Backlogを使ったり、githubのprojectを使ったり右往左往したんですが、最終的にZenHubに落ち着きました。

理由としては、

  • ソース管理をGithubでおこなっているので、Githubに課題管理系を集約したい
  • 期限の管理もしたいがgithubのprojectだと不十分
  • IssueをまとめてEpicレベルで管理したい

というのを総合したときに、ZenHubになった感じです。

ただ、まだまだ試行錯誤中です。

Serverlessのメリット

Serverlessで実装することでサーバの管理から解放されるというのはもちろん大きなメリットですが、それ以上に イベント駆動 で設計する癖がつくというのが大きかったです。

例えば、API Gatewayにリクエストが来てLambdaで処理をしてDynamoDBにデータ格納するという流れがあった際に、DynamoDBに格納されたものをDynamoDB Streamを使ってLambdaにデータを流してデータ加工した上でElasticsearchに流したりできます。

他には、S3に配置されたファイルを検知してLambdaを起動し、SQSにキューとして追加するなど、イベントを起点として設計することで、各処理の結合度を下げることができました。

よもやま話

  • サーバの管理はしませんがサービスの管理はするので監視とかどうしてる?
  • AWSのいろんな上限値でハマった話
  • Serverless Frameworkのプラグインに不具合があってプルリク出した話

などなど、いろいろとネタはありますが、長くなりすぎますので、それはまた別記事で。

次回のServerless話をお楽しみに。