- Java・エンジニア
- SES│在宅あり│契約社員◎
- 未経験大歓迎│Webエンジニア
- Other occupations (52)
-
Development
- Java・エンジニア
- 未経験大歓迎│Webエンジニア
- Webエンジニア
- 上流工程・システムエンジニア
- 未経験歓迎│資格支援
- 未経験も歓迎│Webエンジニア
- Java経験者│リモート有
- リモート有・Java経験者
- Java経験者
- リモートOK・Java
- SES│Java
- SES│在宅ワーク│Java
- 在宅ワーク│C# or VC+
- SES事業│テレワーク
- Webエンジニア│Java
- プログラマー・Java
- Webエンジニア・Java
- Webエンジニア・フルリモート
- JAVA・システムエンジニア
- エラー箇所の特定・修正
- Unisys経験者
- JAVA・TypeScript
- リモートOK・リーダー
- 在宅OK・Oracle EBS
- リモートOK・モバイル開発
- プログラマー
- アプリ開発エンジニア
- アプリエンジニア
- クラウドインフラ案件
- Java新規開発
- 開発経験3年以上│東京勤務
- データ移行
- Python案件
- システムエンジニア
- フルリモート
- プログラマー(Java)
- エンジニア・SE
- Systems Engineer
- Business
最近、既存プロジェクトをAWSにリフトしたところ、システム性能劣化が発生しました、色んな性能問題がありますが、今回はストレジ周りを言いたいです。
AWSはEFSなどネットワーク通信が発生するストレジをの利用は要注意です、もともとローカルディスクですごく早いファイル処理バッチ(実行時間3分程度、入力データサイズ30Gバイトくらい)で、AWSのEFSを使うことで、実行時間が14分以上かかりました、調べたところ、性能のボルトネットがEFSのリード処理にあるらしいです。バッファサイズを大きくするようにプログラムを改修しても、性能改善が全くできませんでした、EFSをEC2のローカルディスクに変更すると、ほぼ既存と同等な性能が出されていました、どうしますかが結構悩まれました、当初EFSの利用はサーバ間のデータ共有の便利を図るためです、ローカルディスクに戻すと、基盤チーム、アプリチームが結構大変な改修作業が発生します。もっと良いもの(例えば、AWSのFSx)を切り替えると、基盤チームのみの作業となります、ただ、大変さが変わりません。AWSの使用は普段ぜんぜん問題にならないところ、落ち穴になるかもしれないです、なので案件初期段階のPOC作業をきちんと検証しないといけません。事前検証して、評価した上でサービスを利用するかどうかを決めるのは大事です、一番普通な機能で、甘くて大丈夫と思って、進めてしまうと、大変なことになることがあります。
最後、今回は1本のファイル処理バッチの性能劣化の話のようですが、実際はシステムが大きくて、同じようなジョブ数百以上あります、同時に遅れると、例えシステムの夜間バッチが普段翌日7時完了する場合、翌日10時で完了すると、このシステムも破綻します。AWSの性能は結構興味深い話で、また次回RDSについて話しましょう。読んでいただいた、ありがとうございます。