The use of database in Cloud Native Application

【6/19開催】Kong Community Japan Meetup #4
本イベントでは、Kong Inc. のVP of ProductであるReza Shafii氏もプレゼンターとして参加。当社からはアーキテクト マネージャーの槌野の登壇が決定!参加無料です!!

【6/21開催】開発者目線でのSBOMとの向き合い方
SBOMの導入から開発者がSBOMの作成・管理を自動で行っていくための方法(デモ)を紹介します。

【7/5開催】azd+Terraform? ~ポイントを押えてAzure上へのアプリケーション環境をラクチン構築~
ツールの概要説明から、実際の開発におけるポイントをお伝えします!

【7/19開催】現場で役立つAzure神小技10+α 〜生成AI,RAG,コスト削減など旬な技術満載のLT大会〜
Azureの最新技術や実用的な小技を紹介する特別なライトニングトーク大会を開催します!

【7/26開催】最適なIaCツールを選ぼう
プロジェクトでのツール選びに困らないための重要な観点をご説明します!

Recently, ”Cloud Native Application” is getting very popular.The definition of Cloud Native Application varies on case by case,but here it is defined that Cloud Native Application is one developing by FaaS(Functions as a Service) like Lambda(AWS), Azure Functions(Azure) and so on.

When using FaaS,we have to consider a database for FaaS to use.

Generally, Connection-Less and Schema-Less database like CosmosDB(Azure), DynamoDB are suitable for FaaS.

FaaS is “Stateless” which means that one function can not use values other functions use.(“Durable Functions” makes it possible for FaaS to be Stateful)

In other words, Stateless prevent us from using Connection Pooling.A relational Database like MySQL, PostgreSQL and so on is required to establish a connection per executing SQL.It is said that to establish a connection needs high computer resource.The combination of RDB and Connection Pooling is very popular.I’ve heard that Using RDB with FaaS is anti-pattern of Serverless.

In addition, using RDB with FaaS has a problem that RDB reaches the limit of max connections as the result of scaling out of instances caused by increase of requests.

Despite that, I’d like to use RDB with FaaS!!

CosmosDB and DynamoDB is so great product.It is very useful to store data the schema of which is highly likely to be changed and which has very simple structure.But RDB is more suitable for joining some tables to meet the customer’s complicated demand.

I did some investigations as below.

I executed a quite simple SQL “select 1” for 10000 times in the two following cases:

  • establish a connection per executing SQL
  • pool connections and reuse ones

The following code is one establishing a connection per executing SQL.

The following code is one using connection pooling.

The result is as follows:

  • establish a connection per executing SQL:22,497 ms
  • pool connections and reuse ones:2,380 ms

The difference is large, but in the aspect of connection per execution of SQL, it is small difference of only 2 ms.

In case of developing small applications customer’s demand of which is significantly complicated, I guess that RDB is more suitable.

I said that using RDB with FaaS has a problem that RDB reaches the limit of connections as the result of scaling out of instances caused by increase of requests,but in case of Azure Functions, it is likely to be solved by adjusting batchSize and using SIngletionAttributes as following link.

https://github.com/Azure/azure-webjobs-sdk/wiki/Singleton

アバター画像
About 武井 宜行 271 Articles
Microsoft MVP for Azure🌟「最新の技術を楽しくわかりやすく」をモットーにブログtech-lab.sios.jp)で情報を発信🎤得意分野はAzureによるクラウドネイティブな開発(Javaなど)💻「世界一わかりみの深いクラウドネイティブ on Azure」の動画を配信中📹 https://t.co/OMaJYb3pRN
ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。


ご覧いただきありがとうございます。
ブログの最新情報はSNSでも発信しております。
ぜひTwitterのフォロー&Facebookページにいいねをお願い致します!



>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

Be the first to comment

Leave a Reply

Your email address will not be published.


*


質問はこちら 閉じる