博士

ロボ子、大変なのじゃ！AWSの帯域幅コストが思ったよりずっと高いことが判明したぞ！

ロボ子

それは大変ですね、博士。具体的にはどのような状況なのですか？

博士

Upsunのインフラは高可用性のために3つのAZにまたがっているのじゃが、Cephベースのストレージシステムで問題が発生したのじゃ。Cephはデータをクラスタ全体に分散するから、AZ間のトラフィックがめっちゃ増えて、AWSから帯域幅料金をめっちゃ請求されたのじゃ！

ロボ子

なるほど。ディスクI/Oトラフィックの約3分の2がAZを越えていた、と。

博士

そう！そこで、ローカルSSDストレージをリードキャッシュとして使うことを思いついたのじゃ！

ロボ子

具体的にはどのように？

博士

Linuxデバイスマッパー(dm-cache)を使って、3段階のキャッシュ戦略を実装したのじゃ！まず、ローカルSSDを小さな512MBのキャッシュボリュームに分割。次に、dm-cacheを構成して、Ceph RBDボリュームの前に配置し、読み取りをキャッシュしながら、書き込みは直接ネットワークストレージに送るようにしたのじゃ。

ロボ子

ライトスルーモードですね。そして、dm-cacheデバイスをプライマリストレージインターフェイスとしてコンテナに公開した、と。

博士

その通り！dm-cacheは元々、小規模で高価なSSDを大規模HDDの前に置いて、容量とパフォーマンスを両立させるために設計されたものなのじゃ。

ロボ子

アプリケーションI/Oパターンは時間的な局所性を示すことが多いので、同じファイルやデータベースページを繰り返し読み取る傾向がありますから、キャッシュが有効に機能するのですね。

博士

そうそう！本番環境でdm-cacheを使う場合は、キャッシュサイズが重要になるぞ。アプリケーションのワーキングセットに合わせて調整する必要があるのじゃ。今回は512MBのキャッシュが効果的だったみたいじゃ。

ロボ子

キャッシュヒット率を監視して調整するのですね。他に考慮すべき点はありますか？

博士

書き込みポリシーはライトスルーモード一択じゃな。それと、キャッシュヒット率、ネットワーク帯域幅の使用率、アプリケーションの応答時間などのメトリックを追跡して、キャッシュ戦略の有効性を検証する必要があるぞ。

ロボ子

なるほど。実際に効果はありましたか？

博士

5〜50GBのRBDボリュームに対して、わずか512MBのキャッシュボリュームで、ネットワーク経由の読み取りトラフィックが95%も削減されたのじゃ！

ロボ子

それはすごい！

博士

キャッシュされた操作のIOPSが30倍向上、読み取りレイテンシが50%削減、頻繁にアクセスされるデータの読み取り帯域幅が30倍増加したのじゃ！

ロボ子

素晴らしい成果ですね。帯域幅コストも大幅に削減できたのではないでしょうか。

博士

その通り！これでAWSの請求書に怯える日々ともおさらばじゃ！

ロボ子

それは良かったですね、博士。ところで、博士の部屋の電気代も、何かキャッシュのような仕組みで節約できないでしょうか？

博士

うむむ、それは難しいのじゃ。ロボ子の電力消費をキャッシュ… いや、ロボ子は私の最高の助手だから、特別料金じゃ！