データベース性能編－その3（AWSストレジ）

最近、既存プロジェクトをAWSにリフトしたところ、システム性能劣化が発生しました、色んな性能問題がありますが、今回はストレジ周りを言いたいです。

AWSはEFSなどネットワーク通信が発生するストレジをの利用は要注意です、もともとローカルディスクですごく早いファイル処理バッチ（実行時間3分程度、入力データサイズ30Ｇバイトくらい）で、AWSのEFSを使うことで、実行時間が14分以上かかりました、調べたところ、性能のボルトネットがEFSのリード処理にあるらしいです。バッファサイズを大きくするようにプログラムを改修しても、性能改善が全くできませんでした、EFSをEC2のローカルディスクに変更すると、ほぼ既存と同等な性能が出されていました、どうしますかが結構悩まれました、当初EFSの利用はサーバ間のデータ共有の便利を図るためです、ローカルディスクに戻すと、基盤チーム、アプリチームが結構大変な改修作業が発生します。もっと良いもの（例えば、AWSのFSx）を切り替えると、基盤チームのみの作業となります、ただ、大変さが変わりません。AWSの使用は普段ぜんぜん問題にならないところ、落ち穴になるかもしれないです、なので案件初期段階のPOC作業をきちんと検証しないといけません。事前検証して、評価した上でサービスを利用するかどうかを決めるのは大事です、一番普通な機能で、甘くて大丈夫と思って、進めてしまうと、大変なことになることがあります。

最後、今回は１本のファイル処理バッチの性能劣化の話のようですが、実際はシステムが大きくて、同じようなジョブ数百以上あります、同時に遅れると、例えシステムの夜間バッチが普段翌日7時完了する場合、翌日10時で完了すると、このシステムも破綻します。AWSの性能は結構興味深い話で、また次回RDSについて話しましょう。読んでいただいた、ありがとうございます。