メリークリスマス、弥生でエンジニアをしているおおもりと申します。今年5月に中途入社してからスマート証憑管理というサービスの運用改善を行っています。
今回、スマート証憑管理で実施したAWSコスト削減施策で行ったDR（ディザスタリカバリ）対策で利用しているS3バックアップの見直しについて紹介します。
昨今、円安の影響でいろいろな物が値上げしています。日用品だけでなくAWSサーバー費用もドルで計上されるため円安の影響を受けます。
弥生では、全てのサービスのサーバー費用などのコストを役職に関係なく知ることができるオープンな状態になっています。また全社集会の場でもサービスごとの収益、費用、利益等が目標通り進んでいるかの報告が行われます。
そのためエンジニアの立場でもコストを意識して日々仕事に取り組んでいます。
スマート証憑管理のサービス説明
スマート証憑管理は、領収書・請求書・納品書・見積書などの証憑をクラウド上で保存・管理できるサービスです。
保存された証憑が電子帳簿保存法の保存要件を満たした状態にできるようにサービスが提供されています。
保存された証憑データを「11年4ヶ月」保存すると規約で定めています。
これらのサービス要件をAWSのS3を使って実現しています。電子取引のデータ保存の保存要件によりデータ削除できないため日々S3のデータは増えていきます。
現在は、TBを超える膨大なデータ量になっています。
DR（ディザスタリカバリ）対策
スマート証憑管理のサービス説明で記載した通りサービスの要は、お客様から預かっている証憑になります。
DR対策としてAWSの東京リージョンで万一何かあったときにも対応できるように大阪リージョンにもS3のデータを複製しておく必要があります。
AWS Backupを使ってバックアップ対応を行っていたのですが、費用が高いという問題がありました。
データ量が多いため毎月2000ドルを消費しており、今後データ量が増えるとさらにコストがかかるという問題がありました。
AWS社からのS3バックアップ改善提案
弥生ではAWS社のTAM(テクニカルアカウントマネージャー)やSA(ソリューションアーキテクト)に相談しサポートを受けることができます。
今回コスト最適化のテーマだったためTAM担当者の方からS3のCRR(クロスリージョンレプリケーション)機能を使えば安くなるというご提案とCRR機能を使った場合と現状のままAWS Backupを利用し続けた場合を比較したグラフを提示いただきました。
開発環境での改善提案の検証
以下の3つの条件を開発環境で検証しました。
1. 現在運用しているAWS Backup
AWS Backupは各サービスのバックアップを一元管理・設定できるサービスです。
定刻でバックアップを取得するよう設定を行い、S3バケットのスナップショットを作成し、大阪リージョンへ送信するようにしていました。
結果
バケット内の全オブジェクトを東京リージョン内でスナップショットにしてから大阪リージョンにスナップショットを送信していました。
そのためオブジェクト量に比例して、毎日コストがかかることがわかりました。
さらにスナップショットを復元した際にオブジェクトの日付が復元した時間になってしまっていることも判明しました。
2. 改善案のCRR +CRR Batch
CRR(クロスリージョンレプリケーション)はS3で設定できる機能です。
設定するとほぼ同期的にオブジェクトが作成・変更・削除されたタイミングで連携先のS3バケットで同じようにオブジェクト操作が行われます。
CRR Batch(クロスリージョンレプリケーションバッチ)はCRRを設定する際に今まで貯めていたデータを一括で連携先のバケットに送信できる機能です。
結果
CRR Batchで連携されたオブジェクト含め大阪リージョンのオブジェクト日付は、東京リージョンと同じ日付になることを確認できました。
また開発環境では少量データで検証していましたが、CRR Batchはデータ量に比例して転送時間がかかることがわかりました。
結果から本番データでは、膨大なデータ量のため数日かかるという予測をあらかじめ立てることができました。
3. 改善案のCRR +CRR Batch +ストレージクラスGIR
ストレージクラスGIR(Glacier Instant Retrieval)は、S3標準よりも安いストレージクラスです。
S3標準ストレージクラスよりも安いストレージクラスGIR(Glacier Instant Retrieval)を大阪リージョンで利用するように設定します。
結果
ストレージクラスGIRを利用する場合には、オブジェクトサイズが128KB未満だと逆にコストが多くかかることがわかりました。
ストレージクラスGIRからオブジェクトを取り出す必要があり、以下の2点の課題があることがわかりました。
・ストレージクラスGIRからオブジェクトを取り出す仕組みを構築する必要があります
・ストレージクラスGIRから取り出した日付がオブジェクト作成日になってしまいます
開発環境での検証結果まとめ
開発環境での検証結果からCRR +CRR Batchに変更することを決定しました。
本番環境でのCRR +CRR Batchへの変更対応
事前の認識合わせ
AWS BackupからCRR +CRR Batchへの変更にあたってTAM担当者の方から連携された数値も利用してコスト改善の見積を行いました。
CRRの設定をする際に今までのオブジェクトデータを送信する1度しか動かないCRR Batchで2000ドルかかり、CRRでは毎月400ドルかかるということを見積として出しました。改善前のAWS Backupでは2000ドルかかっており、CRRに変更すれば400ドルになるため1600ドル削減できます。
そのため初回に投資する2000ドル含め2カ月ほどでコスト削減するという見積りをたてることができました。
コスト見積りを事前に出し、初回には一時的に費用は上がるが毎月の削減で改善できることを示したおかげでPMや開発部関係者とすぐに合意が取れリリースに進むことができました。
実施結果
CRR Batch費用
CRR設定開始前のデータを一括で転送するCRR Batchにより大阪リージョンへの連携に2日かかりました。青色のS3のコストは約2000ドルの費用でした。
データ量が多いこともあり失敗せずに完了するか不安がありましたが無事予想通りのコストで完了しました。
CRR効果
CRRの設定によりS3の費用は、予想通り数十ドル増えましたが、緑色のAWS Backupが丸々費用として削減されました。
結果から、毎月1600ドルの費用を削減することができました。
今後の取り組み
AWS Backupの費用削減に成功したので、次に費用がかかっているECRの費用削減に今は取り組んでいます。現在弥生では、AWS費用を削減することに力を入れています。
大規模なユーザデータを扱ったコスト改善などに興味がある方がいればぜひ弥生に入社していっしょに頑張りましょう。
