Akamai Diversity

Akamai Japan ブログ

皆さん、こんにちは。
アカマイ・テクノロジーズ、プロダクト マーケティング マネージャの北かおりです。

このところ、弊社のImage Managerについてお問合せをいただくことが増えてきました。
これは、ウェブサイトのモバイル対応を本格的に進める企業様が増えているためだと考えています。このサイトのモバイル対応に際して、意外にやっかいな問題になるのが画像コンテンツの変換・編集ワークフローです。
その解決手段として、画像の自動最適化・配信ができるImage Managerをご検討いただくわけですが、導入・検討を進めるお客様から、「最初の設定イメージを知りたい」とのお問合せをいただくことがよくあります。
そこで少し前のエントリーですが、弊社のプリンシパル テクニカルプロジェクトマネージャRaphael Edwardsの記事から抜粋し、「レスポンシブ画像」のコンセプトと「Image Managerの設定イメージ」を簡単にご紹介したいと思います。Image Manager設定に必要なステップはわずか2つ(込み入ったケースでも3つ)です。あまりのシンプルさに驚かれるかも?

Akamai API Protection

APIマネジメント、APIエコノミーなどAPIに関連した言葉をニュースや記事として目にする機会が増えています。Akamaiでも日々Webサイト、動画等々いろいろな種類のトラフィックを配信していますが、APIを利用したトラフィックは非常に大きな割合を占めるようになってきています。現在、Akamai経由で配信しているFQDNのうち約4%でAPIを取り扱っているのですが、実トラフィック量に占める割合は約20%程度となっております。

APIは多くの場合JSONなどのテキストデータになりますので、1リクエストあたりのデータ量は画像等と比べた場合は小さくなりますので、非常に多くのデータが流れていることが想像いただけると思います。

このような中でAkamaiでは重要度を増すAPIのトラフィックに対するユーザ体験を向上させるために大きく以下の5つの機能を提供しています。

  • API Acceleration - 従来から持っているWebの高速化機能をAPIにも適用することにより、APIトラフィックデータをより高速に運ぶ機能の提供
  • API Caching - こちらも従来から持っているWebのキャッシュ機能をAPIにも適用することにより、サーバの負荷低減と高速化を実現
  • API Compression - APIのデータを圧縮しデータサイズを60-90%削減することでAPIトラフィックデータをより高速に運ぶ機能の提供
  • API Prioritization Cloudlet - サーバが高負荷になった場合などに優先度の高いAPIトラフィックをサーバに透過させたり、優先度の低いAPIトラフィックに対して代替レスポンスの実施など行う機能の提供(こちらはCloudletというコンポーネントで提供しています。CloudletについてはBlogサイトをご参照下さい
  • API Protection - JSONやXMLデータのインスペクトやHTTPメソッドの確認、APIリクエストに対するDDoS/流量過多を防ぐためのRate Controlの提供

今回の記事ではKona Site Defenderの新機能であるAPI Protectionについてご紹介いたします。

UDPとTCP

データの大容量化や、モバイルでのインターネットの閲覧の普及により、より良い品質での通信が求められるようになって来ています。 現在、Webの世界で広く用いられているTCPプロトコルは、厳格な通信プロトコルで、通信環境の悪い所でも、再送制御や輻輳制御を実装する事で、信頼性の高い通信を維持する事が可能です。

TCPでは、"スリーウェイハンドシェイク"で送信、受信側のセッションを確立させた後、データパケットの送受信をACKパケットで確認しながら、データが届かない時はデータを再送信する等の制御を行い確実にデータを届けるプロトコルです。

また、一度に送るデータサイズは、小さなデータよりも大きなデータの方が、送受信の制御パケットの数が少なくできるため、転送効率が良くなります。そのため、TCPでは、送信データサイズを、確実に送信できそうな小さなデータからはじめて(スロースタート)、様子をみながら一度に送るサイズ(ウィンドウサイズ)を少しづつ大きくし、転送効率を上げていくなどの制御が行われています。

一方で、一度に大量のデータを送りすぎると、回線が混雑(輻輳)してしまうため、パケットのロスが起きた時は、一旦ウィンドウサイズを小さくするなどの制御も同時に行われ、データを安全、確実に届けるための様々な工夫が実装されています。 udpvstcp.jpg

TCPは非常に良く考えられたプロトコルですが、このような送信側と受信側のきめ細かなやりとりは、やりとりがきめ細やかな分、距離や回線の品質によりネットワークの遅延が大きい時は、データの送受信にかかる時間に大きな影響をもたらす事になります。

TCPの後に開発されたUDPは、音声や動画通信に向けて、低遅延を目指した設計がされています。TCPで実装されていた細かな送受信制御はそぎ落とされており、パケットロスなどデータの到達性については保証されていません。 UDPは、そのようなデータロスが本質的に大きな影響を及ぼさないIP電話やビデオ電話の世界で広く用いられています。

第2回は、キャッシュに関するベストプラクティスについてご紹介しました。
第3回では、キャッシュ対象外のコンテンツにも効果のある、Akamaiによる通信高速化について、お話します。

「遅延」がWebパフォーマンスのボトルネックになることは、第1回で述べました。
 
bestpractice_web_perfromance01_001.png
キャッシュを利用しない場合でも、Akamai経由で通信することで「遅延」の影響を小さくすることが可能です。
  1. TCPコネクション/TLSセッション確立の時間を短縮
  2. TCP最適化による高速通信
  3. 次にリクエストされるコンテンツの先読み
  4. 最適な経路選択により、ネットワーク経路上の混雑を回避

現在のWebサーバーへのアクセスは、非常に多岐に渡るエンドユーザー環境からのアクセスを受けます。そのため、それぞれのエンドユーザー環境に応じたコンテンツ配信が必要となり、その最適化はWebサーバーのコンテンツ提供者にとっては、非常に大きな負担となっています。その上、ユーザー要求、新たな技術、脆弱性などが次々に現れ、日々の業務に併せて、それらの対応もままならない状況になっているWebサーバー管理者の皆様もいらっしゃるのではないでしょうか。今回は、HTTP/2関連技術を用いて、簡単にWebサーバーのパフォーマンスの最適化を行える、Akamaiの最新のソリューションをご紹介したいと思います。

Akamaiを介して配信をすると、簡単にHTTP/2によるコンテンツ配信を実現することができます。

HTTP_2.png

2017年1月24日にアカマイはEnterprise Application Access (EAA)という製品を発表しました。

この製品は今までのアカマイのウェブサイトに対する高速化やセキュリティのソリューションとは一線を画し、エンタープライズのネットワークに向けたソリューションとなります。外部に公開されたウェブアプリケーションではなく、社内アプリケーションが対象となり、それに対するリモートアクセスのソリューションとなります。

このブログでは、リモートアクセスにおける課題と、EAAがどのような価値を提供できるかについて解説させて頂きます。

エンタープライズの社内アプリケーションは、データセンターもしくはAWSやAzureといったクラウド上に置かれています。そしてそのような社内アプリケーションや内部ネットワークに外部(特にインターネット)から接続させないため、ファイアウォールが設置されています。ファイアウォールはコンセプトとしては全てのインバウンド(外部から内部への)コネクションを遮断し、アウトバウンド(内部から外部への)コネクションを許可します。内部ネットワークにいるユーザがその社内アプリケーションにアクセスするのは簡単で、単純に直接アクセスしてアプリケーションを使うだけです。

ただ、リモートユーザのアクセスとなると簡単にはいきません。
ファイアウォールはインバウンドコネクションを遮断してしまいますので、特別な考慮が必要になってきます。
ntakahas-eaa-1.png

Luna トラフィックレポートの確認方法

みなさん、こんにちは。
アカマイ・テクノロジーズ西日本支店の熊澤です。

今日は、Lunaのトラフィックレポートの見方のおさらいをしたいと思います。
Akamaiのサイト配信を使っているけど、あまりLunaは見たことがない方向けの記事です。

WAFをご利用のお客様が急増していますのでセキュリティ関連のレポートの見方もご紹介したいところですが、それは次回にいたします。

早速ですが、私がよく使うレポートは、以下の3つ。

・オフロード
・レスポンス
・ユニークビジター

AkamaiではSIRT(Security Intelligence Response Team)という独立してサイバー脅威の監視、調査、分析を行うグループが存在します。
SIRTは調査を通じて非常に高いレベルのTTPs(Tactics、Techniques and Procedures/戦術、技術および手順)を構築し、これをさらに向上すべく様々な活動をしております。

この活動の一環として得られた知見などについては英語ベースにはなりますがBlogなどで公開させていただいております。ここではAkamai Security Intelligence Response Teamが活動を公開している4つのサイトについて紹介します。

 Akamaiの研究チームは、「IoT(モノのインターネット)」デバイスを悪用した攻撃の増大についてモニタリングを行っています。これらの攻撃は、乗っ取られた様々な種類のデバイスから行われます。Akamaiは、お客様とユーザー様をこれらの攻撃から守るために日夜取り組んでいます。

その他の(汎用的なコンピュータなどの)IoTタイプではないデバイスの場合、デバイスの所有者はシステムをパッチで修正するか再設定するなどを行って、脆弱性をなくすことができます。対して IoT の所有者は ボットネットのメンバーリストから自分のデバイスを取り除く手段が、ベンダーのアップデートだけが頼りであることが少なくありません。場合によってはIoTデバイスのパッチ修正が自体ができず、デバイスを取り除く以外に手段がないこともあります。

このシリーズ記事では、Akamaiの脅威リサーチ(Threat Research)チームとセキュリティ・インテリジェンス・レスポンス(Security Intelligence Response)チームがこれらの課題についての認識を高めるための情報を提供し、IoTデバイスにとってのインターネットの安全性を高めるためにデバイスの所有者とベンダーが行えるアクションについてのご提案をします。

※ この記事は、Akamai Technologies InfoSec DirectorであるEric Kobrinの記事の翻訳を元にしています。

Akamai {OPEN} API を使用したキャッシュ削除

Akamaiの設定を外部アプリケーションから行うために、{OPEN} API と呼ばれるAPIが公開されています。

この記事では、お問合せの多い {OPEN} API を使用したキャッシュのクリアについて解説します。

1 2 3 4 5 6 7 8 9 10