Akamai Japan ブログ 購読
世界一スケーラブルなMQTTブローカー - IoT Edge Connect -
ここ数年様々なニュース、アナリストによるレポート等で叫ばれている通り、いわゆる"IoTデバイス"の数は加速度的に増え続けています。増加見込みについても様々な機関が予測を発表しており、その内容にはバラつきもありますが、今後数年で数百億台程度に達するとしているものが多く見られます。また5Gネットワークの普及が、従来は実現困難であったIoTサービスの創出を後押しすると考えられます。
Akamai クラウドセキュリティ製品のアップデートのご案内
※ このBlog 記事は2018.3.18に執筆された Akamai Developer Blog 記事を翻訳した内容を元に作成しています。 Akamai はお客様のユーザー体験の向上に常に力を注いでいます。本ブログでは、今後数か月間に予定されている Akamai クラウドセキュリティ製品の具体的なアップデートについて、いくつかご紹介します。これらの改善点のロールアウトは本年6 月にかけて継続的に実施される予定です。最新の変更点についてはお客様の Akamai インタフェースにバナーメッセージでお知らせします。 ここでは今後数か月でどのような変更が行われるか、概要をご説明します。主な変更対象は以下の 5 つの領域です。
AKAMAI の Security Configuration のアップデートに関するご案内
※ このBlog 記事は2019.4.10に執筆されたAkamai Developer blogの記事を翻訳した内容を元に作成しています。 Akamai Security Configuration の 4 回目にして最後となる UX アップデートが完了したことをお知らせします（4 つの段階についてはこちらを参照）。最新バージョンでは開発者および管理者向けのプロセスが効率化され、タスク完了までの時間が短縮されたほか、保護機能がさらに強化されました。これにより、将来 Akamai が新機能を追加するための強力な基盤となっています。Akamai の Kona Site Defender、Bot Manager、Client Reputation、Web Application Firewall については、次の 4 つのセキュリティ設定の領域で機能強化が行われました。 設定の概要とチューニングステータスのページ 設定バージョン比較ツール アクティブ化履歴 「Protection Coverage」を「Hostname Coverage」に変更 注：これらの新しい機能強化は現在、Akamai の Security Configuration のベータ版ユーザーのみご利用いただけます。2019 年 5 月にはすべてのユーザーにご利用いただける予定です。弊社は改良を加えたバージョンがユーザーの皆様に歓迎されること、およびシームレスな体験を提供できることを確信しています。ただし、ベータ版のご利用中に予期しない問題が発生した場合は、［Back to Classic View］ボタンをクリックして以前のバージョンに戻ることが可能です。 ここからは上述の 4 つの機能強化のそれぞれについて、もう少し詳しく説明します。
ENHANCED PROXY DETECTIONによる不正視聴対策のご紹介
アカマイCDNを通して、映画やアニメなど様々なコンテンツが世界中に配信されております。そしてそれらのコンテンツは特定の地域でのみ配信が許可されるべきライセンスコンテンツであることも多々あり、ユーザーの地域判別とアクセス制御の仕組みが必要です。その仕組みはアカマイのContent Targetingという機能で提供されております。それはIPアドレスと地域情報を紐づけたデータベースを参照することでエンドユーザーの地域を特定、アクセス制御するというものですが、VPNを使われると地域判定ができなくなるという側面もありました。本稿では、その抜け道を塞ぐENHANCED PROXY DETECTION (EPD)という新しい機能をご紹介いたします。 ※ この記事は2019.3.4に執筆されたThe Akamai Blogの記事を元に加筆、作成しています。
Web Application Protector による API Protection
インターネットを流れるトラフィックの中でも、近年APIトラフィックは特に増加傾向にあります。利用者が増え、トラフィックが増えるにつれて攻撃者たちも活動範囲を広げてきていますのでAPIに対してもセキュリティ対策が求められています。※ この記事は2019.3.4に執筆されたThe Akamai Blogの記事を翻訳した内容を元に作成しています。
DATASTREAM - リアルタイムロギングの実社会における利点
近年CDNの領域でも、システム全体の安定運用のためにリアルタイムなログの収集および分析が重要になっています。そこで今回はAkamaiのリアルタイムロギングソリューションであるData Streamとその活用方法についてご紹介いたします。※ この記事は2019.3.4に執筆されたThe Akamai Blogの記事を翻訳した内容を元に作成しています。
ハイブリッド＆マルチクラウド時代のグローバルトラフィックマネジメント
※ この記事は2019.3.6に執筆されたThe Akamai Blogの記事を翻訳した内容を元に作成しています。 20年前は複数のデータセンターを負荷分散するために専用デバイスを利用することは一般的であり、複数のデータセンターにホストされたアプリケーションはDNSを使用して宛先となるデータセンターに割り振られていました。DNSシステムはデータセンター単位で設定するため、データセンター間を「ラウンドロビンに割り振られる」結果となっていました。仮に4つのデータセンターを利用している場合であれば、ユーザーは各データセンターを「ラウンドロビンに割り振られる」結果となってしまいます。DNS参照によるラウンドロビンは本質的には負荷分散とは言えるのものではありません。設計者は複数の物理的な場所またぎトラフィックを分散し、過負荷となっているデータセンターに対してはトラフィックを減少させるツールを必要としていました。また、ユーザに最も近いデータセンターが選択され、地理的に負荷分散できるツールについても必要としていました。さらにデータセンターに障害が発生した場合にはトラフィックが再ルーティングされるリカバリーオプションも必要としていました。これらに対応するソリューションとしてグローバルサーバーロードバランサー (GSLB) が生み出されました。GSLBはアプリケーションが属するゾーンに対するプライマリ DNS サーバーになります。通常GSLBはデータセンター毎に1つ設置され、他のデータセンターの負荷を監視し、各ユーザーのクエリを最も適切で、最も近い、かつ負荷の低いデータセンターに割り振ります。またGSLBはデータセンターの障害や過負荷を回避することが可能です。GSLBは異なるデータセンターに配置されたプライマリおよびセカンダリGSLBが連動しリカバリーを実現します。
DevOpsを加速するAkamai CLI - CLI を使用したキャッシュの purge
こんにちは、Akamai Solutions Engineer のYuhki です。 以前から AKamai では、Akamai の製品を HTTP リクエスト経由で使用できる Web APIを提供してきましたが、一昨年からさらにそれらを使いやすくした Akamai CLI (Command Line Interface) の提供を開始しました。Akamai CLI とは、これまで Akamai {OPEN} API で提供していたプリミティブなレベルの複数の操作を組み合わせ、まとめた形で簡単なコマンドとして実行できるようしたものです。Akamai {OPEN} API では簡単な操作をするにもある程度のプログラミングが必用でしたが、Akamai CLI ではより簡単な手順で Akamai のサービスの機能をコマンドラインから取り扱う事ができるようになります。開発・運用局面の自動化プロセスへの Akamai サービスの取り込みがより簡単にできるようになり DevOps への取り込みも楽になっています。コマンドですのでバイナリ形式で提供されていますが、ソースコードは、 GitHub で公開されています。 この記事では Akamai CLI のパッケージ構造、実際にインストールして purge 作業を実行するまでの具体的な作業について解説致します。
GraphQL Caching について
はじめに GraphQL (Query Language)は、Facebookにより開発され、2015年にリリースされたAPI用のデータクエリ言語であり、REST APIの次のパラダイムとして益々注目されています。GraphQLの主な特徴として、クライアントが送出するAPIコールであるHTTP POST Bodyにサービスに必要なリソースを明示的に記述することで、過剰なAPIコール数の削減や、レスポンス内の余分な情報を無くすことでペイロードサイズの削減ができる点などがあげられます。また、基本的に単一のエンドポイントのみを利用すること、APIのバージョンという概念が存在しないことなどもGraphQLの特徴となります。 REST APIと比較して利点が多いように思われるGraphQLですが、一つの課題としてCDNにおけるキャッシュが難しいという点があげられます。REST APIにおける多くのケースでは、APIリソース毎にURLが一意であれば、URLをベースにキャッシュキーを生成する事ができます。（「キャッシュキー」についてはこちらをご参照ください。）一方、GraphQLでは単一のエンドポイントのみを利用し、HTTP POST Bodyの内容によってレスポンス結果が異なるため、URLベースでキャッシュキーの生成ができず、これまでのCDNの仕組みではキャッシュを実現する事ができません。結果として、CDNによるオリジンサーバのオフロードを実現ができなかったり、クライアントのパフォーマンスやユーザ体験に影響を及ぼす可能性があります。 このような課題を解決するために、昨年リリースしたAkamai API Gatewayという製品における拡張機能として、「GraphQL Caching」が実装されました。本機能ではGraphQLで記述されたリクエストに対して、HTTP POST BodyのParseおよびHash値を取り一意のキャッシュキーを生成することで、GraphQLで呼び出されたレスポンス結果をCDN上のエッジサーバーでキャッシュすることが可能になります。 本ブログではGraphQL Cachingについて具体例を交えて説明したいと思います。尚、GraphQLそのものの技術仕様についてはこちらを参照ください。