こんにちは。技術部プラットフォームグループの sugy です。
私は主に弊社で運用しているカラーミーショップというサービスのインフラ周りの担当をしています。 本記事では、カラーミーショップのバックエンドのシステムの一部で利用している NFS サーバを Amazon EFS に変更した話を書きます。
経緯
弊社では、Nyah という OpenStack を用いたプライベートクラウドを運用しています。 その Nyah も OpenStack のバージョンアップに伴い刷新されています。 今回、移設対象となった NFS サーバは古い Nyah（以降 Nyah-classic ）にあり、この Nyah-classic を廃止する旨が前々から周知されていたため、期日までに別の場所に移す必要がありました。
移設先の検討
移設するにあたりどこに移すのが良いかを検討しました。 選択肢としては下記がありました。
- オブジェクトストレージへの変更.
- 新しい Nyah (以降 Nyah ）への移設.
- Amazon EFS への移設.
案１のオブジェクトストレージへの変更は、NFS サーバを利用しているデータの保存先を AWS S3 等のオブジェクトストレージに変更することで NFS サーバ自体をなくす案です。案２の Nyah への移設は、Nyah で利用出来る OpenStack の Block Storage サービスである Cinder ボリューム(※1)にデータを保存する方法です。案３の Amazon EFS への移設は Nyah と AWS を結ぶ Direct Connect 回線を利用し AWS のフルマネージドの NFS サービスである Amazon EFS を利用する方法です。
※1. OpenStack の Block Storage サービスである Cinder は AWS での Amazon EBS のようなものです。
今回の移設先を検討するにあたり、まずは、案１のオブジェクトストレージへの変更ができないかを検討しました。この方法が採れるのであれば、データ自体は移行する必要はありますが、NFS サーバを運用する必要がなくなるメリットがあります。また、HTTP(S)での通信でデータ保存領域と疎結合になることで低レイヤーを意識せず利用できます。 しかしながら、アプリケーション変更にかかる工数を期日までに捻出できず、この方法は断念することになりました。
次に案２の Nyah への移設と、案３の Amazon EFS への移設を比較検討することにしました。 案２の Nyah に移設する方法は、移設前の Nyah-classic では NFS サーバで共有するデータを OpenStack の VM 内のボリュームに保存していたものを、Cinder ボリュームに保存することで可用性を改善する構成です。 この方法は、移設前とほぼ同様の管理方法となるため、不確実性を最小に抑えられるメリットがあります。一方で Cinder ボリュームを利用することで可用性の面では改善されますが、移設前と変わらぬ管理方法のため運用負担の課題が残るデメリットもありました。
案３の Amazon EFS への移行は、可用性等の機能的には十分でしたが性能的に必要十分なスループット,レイテンシが得られるかが懸念でした。Direct Connect 経由での利用ということもあり、ネットワーク的に離れた場所にある NFS サーバを利用することに漠然とした不安がありました。また、コスト面でどの程度の費用になるかが気がかりでした。
Amazon EFS の調査
移設先を検討する上でより良い実現方法を選択できるよう Amazon EFS について調査しました。
ここでは Amazon EFS についての詳しい説明は割愛させて頂きますが、AWS のサービスの一つで高可用性が担保されており、フルマネージドでの運用となるため作成からバックアップまで簡単な設定で利用でき、スループット等の性能面もコストに応じて自由に選択できる、簡便で可用性・自由度のあるサービスです。
まずは、性能評価として簡易的な調査方法ではあるのですが、 dd コマンドを用いて EFS をマウントした領域への読み書きの I/O スループットについて既存の環境と比較しました。
Amazon EFS にはスループットモードという I/O 性能を設定する項目があり、スループットモードをバースト(スループットはファイルシステムサイズに応じてスケール)に設定してある場合、EFS への保存データ量によってスループットが制限される仕様になっています。ただし、バーストクレジットというものがあり、このクレジットを消費しきるまでは保存データ量に応じてバーストできる速度(バーストスループット)での読み書きができます。 また、バーストクレジットは保存データ量に応じてバーストできる時間(最大バースト期間)も決められています。
バースト出来る速度は保存データ量によって変動します。保存データ量が 1TiB 以下は 100MiB/s でそれ以上では保存データ量によって変化します。例えば保存データ量が 10TiB の場合は 1GiB/s (10 TiB x 100 MiB/s/TiB) までバーストできます。
マウント領域への読み書きについて移設前の NFS サーバと比較したところ、スループットモードをバーストとした場合、書き込みは多少の差がある程度なのに対し、読み込みは大きな速度差があることが分かりました(書き込み速度は移設前の NFS サーバの 80% 程度, 読み込み速度は 30% 程度 ※2)。ただし、この NFS サーバのワークロードとしては、スループットの差が体感できるほどの大きなデータは稀に扱う程度のため、問題となる可能性は低いだろうと考えました。
また、運用開始後に本格的にスループットが問題となるようであれば、スループットモードをプロビジョニング済み(指定した量に固定されたスループット)に設定することでスループットを1～1024 MiB/sの範囲で指定できるため、速度的な問題は解消できる見込みがあると判断しました。(プロビジョニングモードは追加料金が発生します)
その他の懸念としては、Amazon EFS の利用料金がありました。プライベートクラウドの Nyah を利用するよりコスト的には割高になるのですが、それ以上のメリットがあるのか利用料金の見積もりを算出して検討材料とします。利用料金については、Amazon EFS の料金ページに用意されている料金計算ツールを用いて試算しました。(AWS Backup の料金を含めて試算しました）
※2. 速度調査時点（2021年1月中旬）では読み込み速度が 100 MiB/s に制限されていたのですが、その後(1月末)にその制限が緩和され、読み込み速度が 3 倍の 300 MiB/s に緩和されました。とてもタイムリーな変更でした！これで移設前の NFS サーバと遜色ない性能になりました。そしてこの仕様変更は、アプリケーションや設定の変更は不要で追加費用も発生しないということで、さすが AWS さん太っ腹ですね!!! 最＆高!!!
移設先の決定
Nyah への移行と Amazon EFS への移行、それぞれのメリット・デメリットを比較検討した結果、Amazon EFS に移行することになりました。
Amazon EFS を選択した理由としては下記を重視したためです。
- 運用負担を低く維持できること.
- 高い可用性が確保されること.
- 性能的に問題となる可能性が低く問題が発生した場合にスケールアップできること.
- 利用料金が許容範囲内と想定できること.
移設
さて、行き先が決まったので後は進むだけです。
移設に向けての準備としては、Amazon EFS リソースのコード管理, EFS 特有のメトリクス取得・監視, バックアップ設定, データ移行などがありました。
Amazon EFS のコード管理については、HashiCorp の Terraform で管理することにしました。弊社での AWS リソースの管理には、Terraform で管理しているものと AWS CloudFormation で管理しているものがあるのですが、カラーミーショップのシステムでは、ほとんどのリソースを Terraform で管理しており EFS も他のリソースと同様に Terraform で管理することにしました。
Amazon EFS を Terraform で管理するには aws_efs_file_system, aws_efs_mount_target リソースを利用することで非常に簡単にコード管理できます。ただし、バックアップ設定については注意が必要です。AWS コンソールから EFS ボリュームを作成する場合は、「自動バックアップを有効化」というチェックボックスがあるのですが、コードでリソースを扱う場合は aws_efs_file_system リソースにそのようなパラメータ設定はないので、バックアップ設定を aws_backup_vault, aws_backup_plan リソースでコードで管理する必要があります。
EFS 特有のメトリクス取得や監視については、バーストクレジットのメトリクス取得・監視と利用料金の監視を行うようにしました。 バーストクレジットの値を監視することで性能劣化が発生していないかを監視します。また保存データ量に応じて利用料金が発生するため、利用料金が想定範囲内か念の為に監視しています。
バックアップ設定については、バックアップに AWS Backup サービスを利用しているので、AWS Backup のジョブのステータスを監視しています。CloudWatch のイベントルールを設定し Amazon SNS で通知するように設定しています。
リプレイスのためのデータ移行については、AWS には AWS DataSync というデータ同期に特化したサービスがあるのですが、今回はおなじみの rsync でデータを同期し移行しました。DataSync を利用していればもう少しスマートにデータ移行できたのではないかと、個人的には悔しさが残っています。
移設メンテナンス
カラーミーサービスの利用者の方々には不便をおかけすることとなりましたが、NFS を利用している一部のシステムを深夜に停止し移行作業を行いました。久々の深夜メンテで少し緊張しましたが、メンテ時間内に完了することができました。
蛇足ですが、弊社ではコロナ禍になった 2020 年初旬以降、自宅でのリモート勤務を基本としているため、深夜のメンテも自宅から実施しました。以前は夜間メンテに合わせて終電でオフィスに出社することもあったのですが、時代は移りゆくもので自宅から問題なくメンテができる時代になりました。リモートワークが常の状況だからこその恩恵だと思います。
移設後の振り返り
移設後に運用を開始して利用料金が気になっていたのですが、移設検討時に想定したより低く利用できています。(運用開始前に確度の高い利用料金の見積もりが出来るようになりたい :-) )
利用料金が想定より低くなった要因としては、移設の際に見直した不要になったデータの削除処理により想定以上に保存データ量が削減されたことです。 移設という機会に日頃の運用ではあまり注目していない部分に目を向けたことで、保存データを最適化できたことが幸運でした。
Amazon EFS に移行して個人的に良かったことは、AWS のサービスの中でも触れる機会がなかった EFS についての知見を得ることができたことです。 弊社では新しいことに挑戦する機会を自ら作っていける文化があるため、このようなシステム変更も柔軟に採用されるところがよいと思っています。
まとめ
AWS のマネージド・サービスの Amazon EFS を利用することで自社で管理していた NFS サーバを廃止し管理運用の負荷を軽減しつつ可用性を向上できました。今後もパブリッククラウドを積極的に活用して生産性を高めていきたいです。