• Home
• コーポレートブログ
• My Redmine Gen.2 のサービス運用面での改善点

皆さん、こんにちは！吉岡です。ゴールデンウィーク期間中に少し暴飲暴食をしてしまい、体重が2キロも増加してしまいました。ちなみに、「GW」と聞いてゴールデンウィークよりもGoldWing（バイク）を真っ先に思い浮かべる私ですが、連休中には車と原チャリしか乗ってません！

さて、今回は私たちが提供するプロジェクト管理ツール「My Redmine」の Gen.2 について、リリースから4年余りを経て、安定した運用とともに見えてきた改善点に焦点を当ててお話ししたいと思います。

参考資料
改善案を検討する前に、いくつかの前提条件が関わってくるため、関心のある方は以下の資料も参考にしてください。

改善の概要

My Redmine Gen.2 は多くのアップデートを重ね、現在ではかなり安定して運用されています。しかし、常に改善の余地はあります。特に注目しているのは以下の3つのトピックです。

1. S3のキャッシュ化 - コスト効率とパフォーマンス向上を図るため、S3データのキャッシュ戦略を見直し中です。
2. FargateのGraviton2対応（ARM64） - コスト効率とパフォーマンスのバランスを取るため、ARMベースのプロセッサに対応予定です。
3. Pipelineの改善 - 開発プロセスの効率化を目指し、CI/CDパイプラインの最適化を進めています。

これらのトピックについて、詳細を共有しながら、何かの参考になればと思います。

S3のキャッシュ化によるコスト削減の取り組み

課題

My Redmine Gen.2のユーザー増加に伴い、S3のGetアクションが増加し、コストが上昇しています。

対応

コストを抑えるために、Amazon CloudFrontではなく、より細かくコントロール可能なMemcachedを用いてS3アクセスのキャッシュ化を進めています。具体的にはRedmineで表示される添付ファイルをアップロードした際に生成されるサムネイルをキャッシュ化することで、少なくともGetリクエストが半数程度に軽減できるのではと期待しています。

現状

Memcachedの導入は開発環境でテストを完了し、良好な結果を得ています。現在はアプリケーションへの統合と本番環境への適用のタイミングを調整中です。

FargateのGraviton2対応（ARM64）によるパフォーマンスとコスト改善

課題

My Redmine Gen.2の契約数の増加に伴い、ECSサービスの利用が増え、それによってコストも上昇しています。

対応

既にSaving Planを適用してコスト削減を図っていますが、さらなるコスト削減のために、コスト効率とCPUパフォーマンスの向上が期待されるGraviton2（arm64）への対応を進めています。Graviton2（arm64）に変更したRDSで負荷の高い処理を実行した際、CPU使用率の上昇が抑えられたことから、この変更が有効であることが示されています。

試算

4vCPU、30GBでtaskを2つ（マルチAZ）で、1ヶ月間起動した場合の料金を比較してみたいと思います。
（Saving Planは適用してない状態）

X86

項目	単価（時間あたり）	数量	稼働時間	稼働日数	台数	計
vCPU	$0.05056	4	24	30	2	$291.2256
Memory（GB）	$0.00553	30	24	30	2	$238.896
合計						$530.1216

Graviton2(ARM64)

項目	単価（時間あたり）	数量	稼働時間	稼働日数	台数	小計
vCPU	$0.04045	4	24	30	2	$232.992
Memory（GB）	$0.00442	30	24	30	2	$190.944
合計						$423.936

ECS Service 1つ当たりでも月で$100ドル以上の差額が発生します。これは使わない手はないですね！

現状

この変更は開発環境でのテストを終えており、本番環境への適用タイミングを調整しています。ただし、Graviton2（arm64）への移行にはPipelineの改善が必要であり、その改善作業を先行して行う予定です。(移行期間の間はx86とarm64の両方のコンテナイメージが必要になるため)

Pipelineの改善によるデプロイ効率化

課題

ECS Serviceの増加に伴い、デプロイの時間が長くなり、新しいサービスの追加ごとに修正作業が増加しています。また、x86とarm64の両アーキテクチャでのイメージビルドが必要になっており、これが作業の複雑性を増しています。

対応

この問題に対処するため、以下の改善策を計画しています。

1. マルチビルド対応を導入し、x86とarm64の両アーキテクチャに対応。
2. イメージのビルドとデプロイのプロセスを分け、それぞれのパイプラインでの効率化を図る。
3. デプロイの安全性を保ちつつ時間短縮を目指すため、アクションの並列化を調整。
4. 拡張性を考慮して、パイプラインの構成をCDKで書き換え、より柔軟に対応可能にする。

現状

現状は以下のような構成になっています。

現在、これらの改善案は計画段階にあり、実際の作業はまだ開始されていません。少し簡略していますが、以下のようにPipelineを二つに分けることで、上記課題に対応することを検討しています。

① ではイメージのビルドとテストを実施します。（自動で実行）
② ではビルドしたイメージのデプロイをおこなります。（手動で実行）

この二つを分け、自動実行することで任意のタイミングでデプロイでき、時間の短縮にもつながります。また、ECS Serviceの追加があった際も②だけ更新することで対応でき、更新の心理的負荷も軽減されます。

まとめ

今回ご紹介したMy Redmine Gen.2の改善点は、コスト削減とパフォーマンス向上を両立させるための重要な取り組みです。S3のキャッシュ化、FargateのGraviton2対応、そしてPipelineの改善によって、弊社のサービスはさらに効率的なものになると思います。

これらの改善はまだ道半ばですが、今後さらなる最適化を進めていく予定です。また機会があれば今後のアップデート情報もお伝えできればと思います！

【スタッフ募集中】
弊社ではAWSを活用したソリューションの企画・設計・構築・運用や、Ruby on Rails・JavaScriptフレームワークなどを使用したアプリケーション開発を行うスタッフを募集しています。採用情報の詳細
弊社での勤務に関心をお持ちの方は、知り合いの弊社社員・関係者を通じてご連絡ください。

---