1
/
5

データベース性能編-その3(AWSストレジ)

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

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

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


Invitation from 株式会社CMatrix
If this story triggered your interest, have a chat with the team?
株式会社CMatrix's job postings

Weekly ranking

Show other rankings
Like 薛福元's Story
Let 薛福元's company know you're interested in their content