ココナラのCDN構成についてご紹介
お久しぶりです。
株式会社ココナラのシステムプラットフォーム部インフラ・SREチームに所属している ぐっさん です。
前回はAWSへログインするための仕組みを見直しした際のことをご紹介させていただきましたが、今回は打って変わってココナラで利用しているCDNについてご紹介しようかと思います。
CDNとは
そもそもCDNとは何かということをざっくりと説明すると、ユーザーがWebサイトにアクセスした際に受け取るコンテンツを配信専用のサーバーにキャッシュとして持たせて配信することでユーザーに高速に届ける仕組みです。
CDNはコンテンツを配信することに特化しているため、高速かつ障害性にも優れています。
また世界のいたるところに配信サーバーが配置されています。
そのため、オリジナルのWebサイトと国を跨ぐほど離れた場所からのアクセスであっても、その距離を感じさせないほど高速にページを閲覧することができるようになります。
Webサイトとアクセス元がそれほど距離が離れていない場合においても、CDNから配信する方が高速な上、CDNの性質上、突発的にアクセスが集中した際などの影響を軽減したりすることができます。
ココナラでの利用
CDNが配信したいページやファイルを配信サーバー内にキャッシュとして持たせた上で、キャッシュをクライアントに配信する仕組みであることから、ココナラでは利用範囲をページ全体ではなく静的なファイルを個別配信することに絞って利用しています。[1][2]
それでも各々のファイルを直接S3から配信するよりは十分高速なため利用していました。
ココナラで利用しているCDNについてですが、AWS社のAmazon CloudFront（以下、CloudFrontと記載）とAkamai社のCDN（以下、Akamaiと記載）の2つのCDNを併用しています。
CloudFrontの利用状況
- かなりシンプルなCDNで導入しやすくココナラはAWS上で動作していることから、利用している他のサービスとも親和性も高いため、単純にCDNを利用したい場合に使用しています
- 機能がシンプルで導入しやすい反面、凝った機能はLambda@Edgeをはじめとしたアプリケーションの開発が必要となるのですが、そういった機能拡張はほとんど行ってはいません
- AWSサービスの1つであることから、他のサービスと関連付けた形でのコード化もしやすく導入・運用が楽だと感じています[3]
Akamaiの利用状況
- CDNサービスを提供している事業者の中でも老舗なだけあり標準で多機能です
- ココナラではAkamaiのImage & Video Managerを活用した画像ファイルの最適化を主に利用しています
- また、CloudFrontとLambdaを組み合わて行なっていた軽度な画像処理も、Image & Video Managerの機能で実現できるため、こちらで行うようにしています
- 運用面では利用状況の可視化や定期的なレポート機能など、運用していく中で欲しい機能も一通り揃っており、調査や確認を行う際には活用しています
- 構築や設定変更にAPIを用いて作業を行うことができますが、現時点では導入後に大きく設定変更を行う機会も少ないことから、コード化は行わずWebコンソール経由で作業を行っています
使い分けと経緯
私が入社する前の話となってしまうため詳細は不明ですが、ココナラ初期にCDNとしてAkamaiを導入したものの、途中からCloudFrontを活用する流れになり、そのままCloudFrontを中心に利用しているような状況でした。
CloudFrontにLambdaを組み合わせることで軽度な画像処理を行っているものもありますが、Akamai含め基本的には単純にファイルをキャッシュして配信するためにCDNを利用していました。
このような利用状態でもS3からファイルを配信することと比べると、十分高速ではあるため上記のような形での利用がしばらく続いていました。
そんな中、2年ほど前からココナラ内でサービスのパフォーマンスを改善する活動が始まりました。
パフォーマンスの改善活動を進めるにあたり、各種指標をモニタリングしていく中で問題となっている箇所が幾つか見えてきました。
問題を調査していくと、原因の一つに画像ファイルの配信に時間がかかっているという問題が明らかになりました。[4]
この問題を解決するため、画像ファイルをWebPやAVIFといった比較的新しい画像フォーマットに変換を行い、画像ファイルのサイズを削減することで画像ファイルの配信時間の短縮を目指すこととなりました。
当初は画像フォーマットを変換するためのアプリケーション開発を予定していたのですが、AkamaiのImage & Video Managerを導入することで簡単に実現できることが分かったため、アプリケーション開発を中止しImage & Video Managerを導入することになりました。
また、その流れで主に画像の表示に利用している部分で利用しているCDNをCloudFrontからAkamaiへ移行することとなりました。
現在の構成で運用してみて
Image & Video Manager導入の動機となった画像ファイルのフォーマット最適化によるサイズ削減とパフォーマンスの改善ですが、導入したことで良い結果が得られました。
具体的には、サイズ削減では画像にもよりますが、画像フォーマットをAVIFに変換することでファイルサイズが9割以上削減された画像があることを確認しています。
パフォーマンスの改善では先のサイズ削減の効果に加え、CDNの重要な指標の一つであるキャッシュヒット率で見ても、頻繁に表示される画像やファイルサイズが大きくなりがちな箇所でのヒット率が高く、安定して90%を超えていたりします。
その結果としてパフォーマンスが改善されました。
これらの結果から、ネットワークの速度が安定していなかったり、十分な速度が出ない環境で利用されている方などには特に効果が大きかったのではと考えています。
上記の結果を踏まえ、CDNをすべてAkamaiに寄せるのかと聞かれれば、答えとしてはNOとなります。
CloudFrontを利用するメリットも一定あり、原則としてCDNはCloudFrontを利用する方向になると考えています。
その理由として、画像以外の静的ファイルを配信するだけであればCloudFrontでも十分高速であり、構築がAWS内で完結することから導入のコストも軽いです。
また、画像ファイルを配信する場合でも画像フォーマットを変換したくないケースや、セキュリティに気を使う必要があるケースなど、明確にCloudFrontで実装した方が都合の良いケースもあったりします。
まとめ
原則、CDNにはCloudFrontを使いつつ、画像ファイルを中心に配信する用途についてはAkamaiを利用する形を今後も継続していくことになると考えています。
とはいえ、CloudFrontからAkamaiに置き換えた方が良さそうな箇所はまだありそうなので、必要に応じて置き換えは進めていきたいと考えています。
Akamaiについては、今後AVIFよりも圧縮率の高い新しいフォーマットが出てきたとしても、Image & Video Managerを利用していることで知らない内に対応されていくことになるかと思いますので、ここはこれからもお任せしていこうと思っています。
今回はCDNに絞ってご紹介いたしましたが、それ以外でも様々な改善活動を行なっていたりするので、いずれご紹介できればと思います。
最後に
ココナラでは一緒に事業のグロースを推進していただける様々な領域のエンジニアを募集しています。
SRE領域だけでなく、フロントエンド領域・バックエンド領域などでも積極的にエンジニア採用を行っています。
少しでも興味を持たれた方がいましたら、エンジニア採用ページをご覧ください。
SREも募集していますので、ぜひご覧ください。
-
ページ丸ごとキャッシュできるとパフォーマンスや耐障害性の面でメリットを最大限享受できるのですが、ココナラではユーザー毎に最適化したページの提供を行っている関係でページ丸ごとをキャッシュすることが難しいです ↩︎
-
主な配信対象のファイルは、jsやcssといったページの装飾に必要なファイルや、jpegやgifといった画像ファイルです ↩︎
-
ココナラでは、AWSのリソースをTerraformを用いて管理・運用しています ↩︎
-
この改善活動では並行して、フロントエンド開発グループの加藤さんが投稿されている良好URLを1%から99%に爆増させたパフォーマンス改善の話のような施策も行われました ↩︎
Discussion