
Akamaiとは
Akamaiとは、世界最大級のコンテンツデリバリネットワーク(CDN)を提供する「Akamai Technologies, Inc.」が展開するサービス群の総称です。
Akamaiが提供するエッジサーバのキャッシュ機能を活用することで、Webコンテンツの高速配信やシステム負荷の軽減を実現できます。一般のユーザーにはあまり目立たない存在ですが、Akamaiを導入している企業は非常に多く、現代のWebインフラを支える重要な存在です。
実際、Akamaiの障害が発生すると広範囲にわたって影響が及ぶことがあり、2021年には大規模な障害が発生しました。私が担当しているシステムもその影響を受けた経験があり、Akamaiの仕組みや役割を理解しておく重要性を改めて痛感しました。
https://xtech.nikkei.com/atcl/nxt/news/18/10626/
Akamai導入後のコンテンツ配信の流れ
Akamaiを導入すると、コンテンツがAkamaiのエッジサーバにキャッシュされ、ユーザーにはそのキャッシュから配信されるようになります。これにより、オリジンサーバへのアクセス頻度が減り、サーバ負荷を大幅に軽減できます。
以下は、コンテンツがAkamaiのエッジサーバにキャッシュされている場合のアクセスフローです。

- ユーザーがサービスを利用するためにURLへアクセスすると、ローカルDNSサーバへ名前解決の要求を送信します。
- ローカルDNSサーバは、あらかじめ設定されたDNSサーバ(例:権威DNS)に対して名前解決の要求を行います。
- このDNSサーバは、Akamai用に設定されたCNAMEレコードを返します。
※事前に、Akamai向けのCNAMEレコードをDNSに登録しておく必要があります。 - ローカルDNSサーバは、CNAMEで指定されたAkamaiのDNSサーバへ名前解決の要求を送ります。
- AkamaiのDNSサーバは、ローカルDNSサーバからの位置情報やネットワーク状況に応じて、最適なAkamaiエッジサーバのIPアドレスを返します(ダイナミックマッピング機能)。
- ローカルDNSサーバは、取得したAkamaiエッジサーバのIPアドレスをユーザーに返します。
- ユーザーは、Akamaiエッジサーバへリクエストを送信します。
- エッジサーバが該当コンテンツをキャッシュしている場合、そのままユーザーにコンテンツを返却します。
Akamai Edgeサーバにキャッシュがない場合の処理フロー
Akamaiのエッジサーバにすべてのコンテンツがキャッシュされているわけではありません。キャッシュが存在しない場合、リクエストはオリジンサーバ(システム側で構築しているサーバ)へ転送され、そちらからコンテンツを取得する必要があります。
以下に、Akamaiエッジサーバにキャッシュが存在しない場合の処理フローを図示します。1~7まではキャッシュがある場合と同様になります。

- ユーザーがサービスを利用するためにURLへアクセスすると、ローカルDNSサーバへ名前解決の要求を送信します。
- ローカルDNSサーバは、あらかじめ設定されたDNSサーバ(例:権威DNS)に対して名前解決の要求を行います。
- このDNSサーバは、Akamai用に設定されたCNAMEレコードを返します。
※事前に、Akamai向けのCNAMEレコードをDNSに登録しておく必要があります。 - ローカルDNSサーバは、CNAMEで指定されたAkamaiのDNSサーバへ名前解決の要求を送ります。
- AkamaiのDNSサーバは、ローカルDNSサーバからの位置情報やネットワーク状況に応じて、最適なAkamaiエッジサーバのIPアドレスを返します(ダイナミックマッピング機能)。
- ローカルDNSサーバは、取得したAkamaiエッジサーバのIPアドレスをユーザーに返します。
- ユーザーは、Akamaiエッジサーバへリクエストを送信します。
- Akamai Edgeサーバがコンテンツのキャッシュを保持していない場合、Akamai Edgeサーバはオリジンサーバ(システムが提供しているWebサーバ等)の名前解決要求を投げます
- DNSサーバは、オリジンサーバのIPアドレスを返却します。
- Akamaiエッジサーバは、取得したIPアドレスを用いてオリジンサーバにリクエストを送信します。
- オリジンサーバは、リクエストに対するレスポンス(コンテンツ)をAkamaiエッジサーバに返却します。
- Akamaiエッジサーバがユーザーにコンテンツを配信します。
Akamai Edgeサーバの変更について
ユーザーがアクセスするAkamaiのエッジサーバは、ユーザーのロケーションに応じて最適なものが自動的に選択されます。Akamaiの導入時には、DNSのTTL(Time To Live)値を設定することができ、TTLが短い場合は一定期間、同じエッジサーバへのアクセスを維持することも可能です。ただし、基本的にはユーザーがアクセスするエッジサーバは変動する前提で、システム設計を行う必要があります。
一方で、セキュリティの観点から「オリジンサーバにアクセス可能なエッジサーバを限定したい」といった要件を持つシステムも存在します。このような場合には、AkamaiのSiteShield機能を利用することで、オリジンサーバにアクセスするエッジサーバをある程度の期間、固定することが可能です。ただし、エッジサーバの変更が発生した際には、ファイアウォール等のアクセス制御設定の更新が必要になる点に注意してください。

Akamai Edgeサーバ故障時の挙動
Akamaiのエッジサーバに障害が発生した場合でも、当該サーバは自動的に切り離され、正常に稼働している別のエッジサーバへリクエストが迂回されます。Akamaiはエッジサーバを世界中に分散配置しているため、非常に高い可用性を実現しています。

Akamai Edgeサーバとオリジンサーバ間故障時の挙動
Akamaiのエッジサーバとオリジンサーバ間で通信障害が発生した場合、ユーザーはオリジンサーバにアクセスできなくなります。このような場合、Akamaiのエッジサーバは Akamai Storage Contentsサーバ にフェイルオーバし、代替コンテンツ(Sorryページなど) を表示する動作になります。

おわりに
Akamaiで導入の効果に関する概要は以上となります。ほかにもAkamai関連の詳細トピックを説明している記事を配信していますので、ぜひ目を通してもらえると嬉しいです。


コメント