2018年4月11日水曜日

【AWS Lambda】帳票出力API開発 その2~RDBMSを使うな~

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。


前回に引き続き、AWS Lambdaのご紹介です。

特徴3:RDBMSを使うな

特徴3は重大です。

  • RDBMSを使ってはならぬ。

とだけ言うと語弊があるので、ここは詳しく説明していきましょう。

RDBMSとは

RDBMSが何かということは、各自でwikipediaでも見て貰えば十分かと。
リレーショナルデータベースマネジメントシステム、つまり普通のDBです。

  • Oracle
  • MySQL
  • PostgreSQL

これを使うな、とは過激な話です。

「DBを使えないシステムなんて実質役に立たないだろ!!」

と思う人も多いはず。
これには理由があるんです。

それは「コネクション」です。

コネクションの概念

通常のWebシステムの場合、まずWebシステムのインスタンスが起動し、そこからRDBMSに対してコネクションを張ります。

この時、「SQLを発行する都度、コネクションを張る」という挙動をするシステムは基本無いです。
(大昔のへっぽこシステムなら分かりませんが)

  • Webシステム起動時に一定数のコネクションを確保し、それを使い回す。

これが基本……と言うか、これ以外選択肢は無いと思います。

コネクションをいくつ取るかはアプリ側に任されていて、RDBMSは上限数までは要求されるだけ張るようになっています。



上の図はコネクション数5をイメージしています。

これはつまり、同時にSQLを実行できるのは5つまで。
6つ以上のSQLが発生した場合、5つに収まらない分は待ちになります。

よくある障害発生のパターンとして、SQLがコネクションを使ってそのまま開放しないというものがあります。
これをやられるとシステム全体のSQLが止まってしまうので、インスタンスの緊急再起動をさせることでコネクションを切って張りなおすことで回復させるのが常套手段です。
(DBまで再起動する羽目になったら目も当てられませんが)

上の図はインスタンスが一台のイメージでした。
では、ロードバランサーとかを使って、APサーバが2台ある構成のイメージを見てみましょう。


はい。
説明するまでも無いと思いますが、コネクションが2倍に増えました。

  • インスタンス毎にコネクションを確保する。

それがシステムの基本です。
ここにLambdaの罠があります。

Lambdaの特徴

Lambdaは以下が特徴のサービスです。

  • 処理が無い時はインスタンスが寝る。
  • 処理が増えた時はインスタンスが増える。
  • 処理が激増した時はインスタンスがガンガン増える。

そろそろお分かりになってきたでしょうか。

Lambdaはインスタンスの動的増減に価値を持っているサービスです。

しかし、インスタンス毎にコネクションを張るという物理的な制約は変わらない。
つまり、コネクション数が無限に増えるという仕様なのです。


この有様です。
イナゴとしか言いようがありません。

  • LambdaとRDBMSは相性が悪い。

これは覚えておかなければなりません。必須知識です。

使って良い場合

でも、カラクリが分かれば使えるシチュエーションもあることも分かるでしょう。

「インスタンスが無限に増えた時にRDBMSがボトルネックになる」が問題の核心部分ですから、インスタンスの数が制御されていれば問題にはなりません。

  • Webリクエストをトリガーとしてインスタンスを起動する場合はインスタンスがどれだけ増えるか分からないから絶対に使ってはいけない。
  • 定期バッチのように、インスタンス数がコントロールされている場合は使える。

これは大変重要な部分です。
覚えておいてください。

本システムの場合

本システムでは、Lambdaは帳票出力APIとして使用しています。
帳票出力に必要な情報は外部から全部JSONで貰うという仕様にしました。
DBにはアクセスしていません。

これが解決策なのです。


  • 必要な全データをリクエストから取得し、そのままDBを使用すること無く処理が完了する機能には最強!!


帳票出力APIにLambdaをチョイスしたのは我ながら名案です。

オマケ:それでもDBを使いたい

そんな制約がありながらも、それでもLambdaの拡張性や効率は魅力的です。

  • アクセスが少ないシステムの場合は、インスタンスが寝ているからタダで使える。
  • アクセスが増えても自動拡張してくれる。

この安定性とコストパフォーマンスは捨て難いです。
そんな人はNoSQLに活路を見出してみましょう。


AmazonのNoSQLであるDynamoDBは、GoogleのBigTableと並んで世界一有名なNoSQLです。

っていうか、LambdaもDynamoDBもGoogleのパクリとしか思え……ゲホゲホ

DynamoDBはクラウド型DBを名乗るだけあって、Lambdaのインスタンス激増から来るアクセス急増にも耐えられるように設計されています。

耐久性の秘密は分散にあります。
だから「保存したデータが別の場所からは見えない(伝搬してないから)」という現象が起きたりとか、RDBMSとはまるで別物。

分散を実現する為に「リレーション」というものが無く、従ってテーブル間結合も出来ないとか、DBをRDBMSからDynamoDBに差し替えれば使えるみたいな単純な話ではないところが厄介ですが、ちゃんと勉強して使いどころを見極めれば非常に心強い味方になってくれるでしょう。

終わりに

引き続きLambdaの話を続けます。

0 件のコメント:

コメントを投稿