**HTML5とは、ハイパーテキスト記述言語（HyperText Markup Language）の5回目の改訂版を指します。**HTMLの仕様はWeb Hypertext Application Technology Working Group（WHATWG）が策定し、World Wide Web Consortium（W3C）で勧告されています。

【参考】：[WHATWG HTML Living Standard](https://html.spec.whatwg.org/multipage/)

HTML 5.1以降はHTML Living Standardに基づいており、現在最新の仕様はHTML 5.2を勧告後、HTML Living Standardに統合され仕様統一されています。

【参考】：[HTML 5.2 W3C Recommendation](https://www.w3.org/TR/html52/)

*HTML5のベースとなっているHTMLは、ハイパーテキスト記述言語です。*ハイパーテキストとは、複数の文書を相互参照するためのリンク（ハイパーリンク）機能を有する仕組みを指します。

ハイパーテキストはWeb（World Wide Web）を始めとするウェブ系システムで標準利用されています。ウェブ系システムで使用するウェブコンテンツはHTMLで記述されており、コンテンツの通信や表示をしたり、直接PCに格納されたHTML文書をブラウザで表示したりすることができます。

HTMLとは？できることや初心者向けのタグの例、CSSについても紹介

HTML入門：基本から学ぶHTMLの構造と構成要素を解説！

HTMLは登場以来文書（コンテンツ）の構造と見栄えを指定できました。その後、煩雑な言語仕様を整理するために文書構造をHTMLが担当し、見栄えをCSSが担当することで役割を分離しました。

それからHTML4では文書構造を表すために利用されていたものの、ウェブサイトの高機能化によりリッチウェブアプリケーションのプラットフォームとしてのニーズが強まりました。

リッチウェブアプリケーションでは、視覚的なリッチコンテンツやマルチメディア機能が必要とされます。*HTML4では十分とは言えないために各ベンダーが独自拡張を進め、このバラバラの実装を整理したものがHTML5です。*HTML5は検索エンジン向けのタグが用意され、利便性が向上しました。

さらに、ビデオやオーディオの再生やオフライン表示のAPI等が追加されており、アプリケーションプラットフォームとしての機能追加が特徴です。

【初心者必見】HTMLとCSSの違いは？基本知識と学習方法も解説！

Adobe Flashは、長らくMacromedia Flashとしてリッチコンテンツのプラグインとして活用されていました。FlashはHTMLで用いるプラグインで動画やゲームで利用されていましたが、脆弱性が多数発見され、ブラウザがクラッシュすることが多かったのが実態です。

上記理由から、Apple社の当時のCEOスティーブ・ジョブズ氏はFlashを使用せずにHTML5を強力に推進しました。このためAdobe社はFlash継続をあきらめ、2020年末にFlash Playerの開発と配布を終了しました。

*ブラウザ提供各社は2015年から2016年にFlashのブロックを開始しており、2020年末のFlash終了への影響はほとんどありませんでした。*

*HTML5 プレイヤーとは、Flash Playerで提供していた動画再生機能をHTML5に置き換えたものです。*HTML5ではプラグインなしで動画やアニメーションを再生できます。そのため、HTML5 プレイヤーとは\<video\>要素を用いて動画再生機能を実装したものを指します。

HTML5 プレイヤーの実装例は、YouTubeが有名です。YouTubeでは2015年からHTML5 プレイヤーをデフォルトの動画プレイヤーとしています。その他にも、JavaScriptのライブラリとして提供するVideo.jsも数多く利用されています。

【参考】：[Video.js](https://videojs.com/)

*HTML5 ゲームとは、主にモバイル向けゲームで用いる用語です。*従来のスマホアプリはApp StoreやGoogle Playにアプリを登録し、Apple社やGoogle社のコントロールの下、アプリ配信を行っていました。主にアプリはゲームエンジンやライブラリ等を用いて開発するネイティブアプリとなります。理由は当時のスマホの性能が追いつかなかったためです。

近年スマホの性能向上が著しいために、ネイティブアプリではなくHTML5を用いてゲームを提供することが増えています。これは性能向上の他にも、Apple社やGoogle社のコントロールを受けないで配信や課金をしたいことが背景にあります。そのためHTML5 ゲーム市場は今後の成長が見込まれる領域です。

HTML5の最初の企画となるHTML 5.0は2008年にドラフトが公開され、2014年に勧告されました。2014年から2015年にかけてHTML5対応ブラウザが整備されています。*そのため代表的なブラウザであるEdge・Firefox・Chrome・Operaは問題なく動作しますし、そのほかのブラウザも順次対応機能が実装されています。*

ブラウザの対応状況を確認するには、「Can I use」や「HTML5test」等でHTML5の実装状況やお使いのブラウザの機能適合が確認できます。さらに、YouTubeでも対応ブラウザかどうかを表示してくれます。

【参考】：[Can I use](https://caniuse.com/)
【参考】：[HTML5test - How well does your browser support HTML5?](https://html5test.opensuse.org/)
【参考】：[YouTube サポートブラウザ](https://www.youtube.com/supported_browsers)

*HTML5の開発は、マークアップ言語に沿ったコンテンツをテキスト形式として作成します。*したがって、テキスト文書を作成する環境があればすぐにでも開始できます。具体的には、テキスト編集するためのエディタ、およびHTML5を表示するブラウザの準備ができれば問題ありません。

なお、HTML5に対応する統合開発環境（IDE）があるとさらに簡単に開発を行うことができます。具体的にはMicrosoft社のVisual Studio、オープンソースソフトウェアのNetbeansやEclipseの利用者が多いです。いずれも日本語に対応しています。

【参考】：[Microsoft Visual Studio](https://visualstudio.microsoft.com/ja/)
【参考】：[Apache NetBeans](https://netbeans.apache.org)
【参考】：[Netbeans 日本語化](https://github.com/junichi11/netbeans-translations-ja/releases)
【参考】：[ECLIPSE](https://www.eclipse.org/)
【参考】：[Pleiades All in One Eclipse日本語化](https://willbrains.jp/)

IDEとは？詳細やメリット、おすすめのIDEを紹介します！

Visual Studio 2022の新機能がIDEで歴代最高な理由

Eclipseとは？統合開発環境を日本語プラグインで快適に構築する方法を解説！

**HTML5はブラウザ機能とテキストエディタを用いるため、特に追加インストールは必要ありません。**統合開発環境（IDE）を使用する場合はそれぞれダウンロード・インストールを行い利用していきます。

動画編集ソフトによっては、ブラウザの拡張機能を使用するためにインストールが求められる場合がありますが、通常は必要としません。

**HTML5はHTML4と後方互換性を維持しながら、機能改善が図られています。**以下に代表的な変更点を記載しておきます。

・*文字エンコーディング*
従来の指定に加えて、以下のシンプルな指定が可能となり使いやすくなりました。
HTML4：\<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"\> 
HTML5：\<meta charset="UTF-8"\>

・*DOCTYPE*
こちらも従来の記述をシンプル化し、\<!DOCTYPE html\>と簡略化されました。

・*言語要素*
section、article、aside、hgroup、header、footer、nav、figure、の要素が追加されました。従来div要素で行っていた文書構造がより分かりやすく整理されました。

・*マルチメディアコンテンツ用言語要素*
audio、videoの要素が追加されました。ともにAPIが提供されており独自のインターフェイスを開発可能です。その他グラフィックス用canvas要素や、ダウンロード管理用progress要素等が追加されました。

上記のほかにも追加された要素や変更された要素があります。詳細はW3Cのドキュメントで定義されています。

【参考】：[W3C HTML5 Differences from HTML4](https://www.w3.org/TR/html5-diff/)
【参考】：[W3C HTML5 における HTML4 からの変更点](https://standards.mitsue.co.jp/resources/w3c/TR/html5-diff/)

冒頭で記述した通り、HTMLの仕様はWeb Hypertext Application Technology Working Group（WHATWG）が策定し、World Wide Web Consortium（W3C）で勧告されています。HTML 5.1以降はHTML Living Standardに基づいており、現在最新の仕様は、HTML 5.2まで勧告されています。

この標準化の過程の中で、HTML5をW3Cがしっかり仕様策定する流れと、機能拡張を順次実施したいWHATWGで仕様の差異が生じてしまいました。そのため、ウェブブラウザ開発ベンダにより立ち上げられたWHATWGのHTML Living Standardが、HTMLの標準規格として存続することになりました。

現在、2021年1月にWHATWGのHTML Living StandardがW3Cによって勧告されており、ダブルスタンダードが廃止されたことで統一化がなされました。**HTML Living Standardの仕様ドキュメントを見ると、「HTML Living Standardは一言で言うとHTML5である」と説明しています。**

HTML5はなぜ廃止された？いつからなのか、仕様変遷も紹介！

## HTML5プロフェッショナル認定試験とは

HTML5が「HTML Living Standard」に変更されたことで、HTML5の認定資格であった「HTML5プロフェッショナル認定試験」についてはどうなるのでしょうか。

公式サイトによると、「HTML5プロフェッショナル認定は今後も、HTML Standardとしてバージョンアップを行い、Webエンジニアの認定としての価値を維持していく」としており、*これまで資格を取得した方やこれから受験を検討している方に対する影響はないようです。*

【参考】：[HTML5はHTML Standardへ呼称変更　～ HTML5プロフェッショナル認定試験は今後も有効 ～ ｜「HTML5プロフェッショナル認定試験」公式サイト](https://html5exam.jp/measures/column_01.html)

これを踏まえ、ここでは「HTML5プロフェッショナル認定試験」について、試験概要や難易度について紹介します。

**HTML5プロフェッショナル認定試験とは、HTML5・CSS3・JavaScriptなどのWebコンテンツ制作やWebアプリケーション、動的なWebコンテンツの開発・設計の技術や知識を測る試験のことです。**

【参考】：[試験概要｜Web資格なら「HTML5プロフェッショナル認定試験」公式サイト](https://html5exam.jp/outline/)

試験は、Webコンテンツ制作の基礎の実力を測るレベル1と、JavaScriptを中心とした動的Webコンテンツの開発・設計の能力を認定するレベル2に分けられます。

*【レベル1】*
・試験名：HTML5プロフェッショナル認定試験 レベル1
・試験時間：90分（試験後の簡単なアンケートの時間を含む）
・問題数：約60問
・受験料：16,500円（税込）
・有効期限：5年間

*【レベル2】*
・試験名：HTML5プロフェッショナル認定試験 レベル2
・試験時間：90分（試験後の簡単なアンケートの時間を含む）
・問題数：40～45問
・受験料：16,500円（税込）
・有効期限：5年間

両試験はどちらもCBT（コンピュータベーストテスト）で実施され、全国各地の試験センターでの受験、または自宅や職場からのオンライン受験が可能です。試験日程においては空いている日時に予約できるため、受験スケジュールを立てやすいでしょう。

合否については、テストセンターで受験した場合は、テスト終了後すぐにその場で結果が表示され、オンライン試験の場合はピアソンVUEにログインした後に確認できます。

HTML5プロフェッショナル認定試験は合格率などを公表していないため、具体的な難易度を測るのは難しいですが、*レベル2に合格するにはレベル1に合格する必要があります。*

そもそもの認定条件として、レベル2はレベル1に合格することを前提とされた試験であるため、難易度はレベル2の方が高いことがわかります。

また、学習期間の目安としてレベル1は3か月〜半年程度、レベル2は半年〜1年程度と公表しています。さらに公式サイトの資格体系の紹介において、レベル1とレベル2の難易度の差を表したグラフが掲載されているので、気になる場合は参考程度にチェックしておきましょう。

【参考】：[HTML5プロフェッショナル認定試験 レベル1について（Ver2.5）｜試験概要](https://html5exam.jp/outline/lv1.html)

HTML5プロフェッショナル認定試験が難しい？試験内容や取得方法

HTMLからJavaを動かせる？JavaScriptを動かす方法も解説

## HTML5を理解して多様なウェブアプリケーションに活用しよう

**HTML5は文書構文がシンプル化され、リッチコンテンツや動画配信等広範囲に活用されています。**特にスマホの動画再生やすきま時間のゲームや学習コンテンツは市場拡大が続いています。

このためHTML5を理解したら多様なウェブアプリケーションに活用し、スキルアップを図ることをおすすめします。

HTML・CSSは独学で習得できる？初心者におすすめな最短の勉強方法

初学者必見！HTMLを勉強するのにおすすめの本を5つ厳選

初心者におすすめのHTMLエディタ5選！便利な機能で開発効率もアップ

HTML5とは、ハイパーテキスト記述言語の5回目の改訂版を指します。Flashの終了に伴いHTML5で動画やアニメーションへの用途が拡大しています。ここでは、HTML5の特徴やHTML4からの変更点、さらに関連用語や対応ブラウザ等を多岐にわたって解説します。

HTML5とはHTMLの5回目の改訂版を指し、マルチメディアやリッチコンテンツに対応します

HTML5は、現在HTML Living Standardにおいて仕様化と機能拡張を行っています

HTML5では構文の簡略化がされており、多用途に活用が期待されています

HTML5とは？特徴や変更点・関連用語・対応ブラウザを解説！

[【関連記事】AWS資格の難易度はどれくらい？内容や初心者におすすめの勉強方法を解説](https://and-engineer.com/articles/YZtFsREAACIAjrpS)

[【関連記事】AWS認定ソリューションアーキテクト-アソシエイトとは？難易度と勉強方法を解説！](https://and-engineer.com/articles/YXEoUBIAACEANWUF)

[【関連記事】AWS認定クラウドプラクティショナーとは？難易度や勉強時間の目安を解説](https://and-engineer.com/articles/YwGSlRAAACEAsVo8)

*AWS*とはAmazon Web Serviceの略で、**最大のクラウドサービス事業者**です。AWSではウェブサービスと名称付けしていますが、クラウドコンピューティングの*サービス全般*を事業としています。AWSは全世界を25の地域から成る*リージョンに分割*し、*均一なサービスを提供する*ために適宜新たなリージョンを開設しています。

AWSの*エンドポイント*とは、AWSのサービスに接続するために**必要なURL**を指します。エンドポイントへは*ウェブアクセス*の他、*AWS SDKやAWS CLI*等の提供ツールからもアクセス可能です。

一般的な構文は以下の通りです。
*protocol://service-code[.region-code].amazonaws.com*
・*protocol*
　プロトコル、使用するプロトコル
・*service-code*
　サービスコード、使用するAWSサービス
・*region-code*
　リージョンコード、アクセスするリージョンのリージョンコード
　リージョンがサポートされていない一部のサービスではリージョン名を省略します

### リージョンエンドポイントとは？

AWSは世界のサービス提供エリアに均一なサービスを提供するために、地域を物理的なロケーションに分割してサービス提供しています。その分割単位を、リージョンと呼びます。

*リージョンエンドポイント*とは、リージョンに割り当てられている*リージョンコード*を用い、それぞれのリージョンの**コードを含むエンドポイント**を指します。

### リージョンとリージョンコードの対応は？

各リージョンには、以下の通り**リージョンコードが割り当てられています**。

＜*北米地域のリージョンのリージョンコード*＞
・米国東部（バージニア北部）リージョン　   リージョンコード： us-east-1
・米国東部（オハイオ）リージョン　　　　   リージョンコード： us-east-2
・米国西部（北カリフォルニア）リージョン   リージョンコード： us-west-1
・米国西部（オレゴン）リージョン　　　　   リージョンコード： us-west-2
・カナダ（中部）リージョン 　　　　　　 　 リージョンコード： ca-central-1
・GovCloud（米国西部）リージョン　　　 　リージョンコード： us-gov-west-1
・GovCloud（米国東部）リージョン　　　 　リージョンコード： us-gov-east-1

＜*南米地域のリージョンのリージョンコード*＞
・南米（サンパウロ）リージョン　　　　       リージョンコード： sa-east-1

＜*欧州/中東/アフリカ地域のリージョンのリージョンコード*＞
・欧州（フランクフルト）リージョン　　　　リージョンコード： eu-central-1
・欧州（アイルランド）リージョン　　　　　リージョンコード： eu-west-1
・欧州（ロンドン）リージョン　　　　　　　リージョンコード： eu-west-2
・欧州（パリ）リージョン　　　　　　　　　リージョンコード： eu-west-3
・欧州（ミラノ）リージョン　　　　　　　　リージョンコード： eu-south-1
・欧州（ストックホルム）リージョン　　　　リージョンコード： eu-north-1
・中東（バーレーン）リージョン　　　　　　リージョンコード： me-south-1
・AWS アフリカ（ケープタウン）リージョン  リージョンコード： af-south-1

＜*アジアパシフィック地域のリージョンのリージョンコード*＞
・中国本土（北京）リージョン　　　　　　　リージョンコード： cn-north-1
・中国本土（寧夏）リージョン　　　　　　　リージョンコード： cn-northwest-1
・アジアパシフィック（東京）リージョン　　リージョンコード： ap-northeast-1
・アジアパシフィック（ソウル）リージョン　リージョンコード： ap-northeast-2
・アジアパシフィック（大阪）リージョン　　リージョンコード： ap-northeast-3
・アジアパシフィック（ムンバイ）リージョンリージョンコード： ap-south-1
・アジアパシフィック（シンガポール）リージョン リージョンコード： ap-southeast-1
・アジアパシフィック（シドニー）リージョンリージョンコード： ap-southeast-2
・アジアパシフィック（香港）リージョン　　リージョンコード： ap-east-1

### サービスエンドポイントとは？

AWSでは、AWSの**サービス単位**で*エンドポイント*が設定されています。これを*サービスエンドポイント*と呼びます。サービスエンドポイント毎に指定可能な*リージョンコード*と*プロトコル*が決められています。各サービス毎の詳細は、以下のリンクをご確認ください。
参考：[AWS リファレンスガイド サービスエンドポイントとクォータ](https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-service-information.html)

*FIPSエンドポイント*とは、**連邦情報処理標準（FIPS）140-2**に準拠した**TLSを用いるエンドポイント**を指します。FIPSエンドポイントは一部のAWSサービスで利用可能です。
参考：[AWS リファレンスガイド AWS サービスエンドポイント](https://docs.aws.amazon.com/ja_jp/general/latest/gr/rande.html)

### 実際のエンドポイント指定は？

エンドポイントアクセス構文に従い、**実際の指定方法**を見てみましょう。
アジアパシフィック（東京）リージョンを用いてAmazon Elastic Compute Cloud（EC2）にアクセスするには、以下の様に指定します。

「構文」
*protocol://service-code[.region-code].amazonaws.com*
「指定例」
*https://ec2.ap-northeast-1.amazonaws.com*
・protocol
　プロトコル、使用するプロトコル、Amazon EC２の場合「httpまたはhttps」
・service-code
　サービスコード、使用するAWSサービス、Amazon EC2の場合「ec2」
・region-code
　リージョンコード、アクセスするリージョンのリージョンコード、東京の場合「ap-northeast-1」

Amazon VPCとは、*Amazon Virtual Private Cloud*の略です。Amazon VPCによりAWSアカウントで*仮想ネットワーク*が利用可能となります。Amazon VPCは、IPアドレスおよびサブネットの管理・ルーティング・ゲートウェイの設定等**一連の仮想ネットワークの制御**を行います。
参考：[Amazon Virtual Private Cloud](https://aws.amazon.com/jp/vpc/)

*AWS PrivateLink* はプライベートIPアドレスを使用して、*AWSサービスにプライベートアクセスするサービス*です。*VPCエンドポイント*とは、AWS PrivateLinkを利用した**プライベートアクセス**の際に用いる*エンドポイント*を指します。

VPCエンドポイントは、以下のタイプから選択し作成して利用します。
・*インターフェイスエンドポイント*
　サポートされているAWSのサービスや VPCエンドポイントサービスに使用
・*Gateway Load Balancerエンドポイント*
　セキュリティ検査などのためにGateway Load Balancerにより設定サービスにルーティング
・*ゲートウェイエンドポイント*
　Amazon S3およびDynamoDBをルーティング
参考：[Amazon VPC AWS PrivateLink VPC エンドポイント](https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/vpc-endpoints.html)

### VPCエンドポイントのメリットは？

*VPCエンドポイント*はプライベートクラウドなため、より**安全にサービスを利用する**ことが可能です。

同様に、AWS PrivateLinkを用いることから、*インターネットゲートウェイ*の代わりに*ゲートウェイエンドポイント*を経由してアクセスします。そのため、NATインスタンスやNATゲートウェイの費用が発生せず、**AWSの利用料を削減する**効果があります。

### AWS PrivateLinkを利用可能なAWSサービスは？

以下のリンク記載のサービスが**AWS PrivateLinkで利用可能**です。*AWSサービス*により、*VPCエンドポイントポリシーのサポート状況が異なります*。合わせてご確認ください。
参考：[Amazon VPC AWS PrivateLink AWS PrivateLink と統合する AWS のサービス](https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/integrated-services-vpce-list.html)

## AWSのエンドポイントを目的に合わせて利用しましょう

AWSは多くのサービスを提供する最大のクラウドサービス事業者です。利用目的に応じたサービスが順次提供されており、*サービス品質を維持*するために*リージョンが適宜開設*されています。AWSのエンドポイントは*拡大するサービスの入口*となるため、**目的に合わせて利用を進めましょう**。

AWSは最大のクラウドサービス事業者で、利用者ニーズに合わせて多様なサービスを提供しています。AWSではアクセス方法を簡素化するために、エンドポイントを設定し利便性を高めています。ここでは、エンドポイントの利用方法や関連用語を説明していきます。

AWSのエンドポイントとは、AWSサービスを利用するためのURLを指します

エンドポイントは、プロトコル・サービス・リージョンコードで構成されています

指定方法は簡単で、多様なサービスのアクセス方法を簡素化するために考えられました

AWSのエンドポイントとは？利用方法並びに関連用語を解説！

## AWSのエッジロケーションとは

AWSの*エッジロケーション*とは、AWSの*リージョンデータセンターとは別に*コンテンツ配信を高速・広帯域なネットワークを介して行うものです。コンテンツ配信は、*Amazon CloudFront*サービスによりエンドユーザーに配信されます。Amazon CloudFrontは*AWSリージョン*と*Tier 1/2/3のテレコムキャリアを接続*し、**低レイテンシーなコンテンツ配信を実現**しています。

AWSは世界のサービス提供エリアに*均一なサービス*を提供するために、地域を*物理的なロケーションに分割*してサービス提供しています。その分割単位を*リージョン*と言います。AWSは最大のユーザーを抱えるクラウドサービス事業者のため、**サービス提供範囲が広い**ことが特徴です。そのため、継続的に必要とされる地域をカバーするリージョンを開設しています。
参考：[AWS グローバルインフラストラクチャ](https://aws.amazon.com/jp/about-aws/global-infrastructure/regions_az/)

### AWSのアベイラビリティゾーンとは？

AWSの*アベイラビリティゾーン（AZ）*とは、1つのリージョンを*冗長性・信頼性・可用性*を確保した*1つ以上のデータセンター*で構成する単位を指します。アベイラビリティゾーンは、冗長的な電力源・ネットワーク、そして接続機能により**相互に接続され**運用されています。

<center>[AWS案件に強みを持つ企業の求人情報もアリ？<br>『<b>マイナビIT AGENT</b>』で転職相談を受けてみる](https://mynavi-agent.jp/it/lp/029.html?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv15)</center>

*Amazon CloudFront*は、AWSの提供する*コンテンツ配信ネットワーク（CDN）*のサービスを指します。CDNとは、*ウェブコンテンツ*を**高速・効率的に配信する**ことを目的とします。CDNによりコンテンツを地域ごとのキャッシュするサーバーを*分散配置*することで、ユーザー要求が*特性のサーバーに集中することを防止する*分散ネットワークが構築可能です。

Amazon CloudFrontは、AWS Shield・AWS Web Application Firewall・Amazon Route 53 と連携し、*セキュリティを保証*しながら*高速なコンテンツ配信*を実現しています。
参考：[Amazon CloudFront](https://aws.amazon.com/jp/cloudfront/)

AWSの*ローカルゾーン*は、*ミリ秒単位のレイテンシー*が求められるアプリケーション向けに提供されています。主に、メディアエンターテイメントのコンテンツ作成・リアルタイムゲーム・ライブビデオストリーミング等のアプリケーションを想定しています。

AWSローカルゾーンはAWSのリージョンを拡張し、*レイテンシーの影響を受けやすいアプリケーション*を*エンドユーザー近接の地域で実行*させます。現在、北米地域のロサンゼルスに加えて、ボストン・ヒューストン・マイアミでもサービスが提供されています。今後さらに12の北米地域でサービス開始を予定しています。

現在ローカルゾーンは*北米地域に限定*されているため、*高速コンテンツ配信*においては*グローバルで分散アクセス可能*な*Amazon CloudFrontによるCDNサービス*を利用する方が**利用者に対するメリットが大きい**でしょう。

### エンドユーザーをエッジロケーションに誘導するには？

*Amazon Route 53*は、AWSの*ドメインネームシステム （DNS）*を指します。Amazon CloudFrontとAmazon Route 53を併用することで、エンドユーザーを適切に**エッジロケーションに誘導する**ことが可能です。
参考：[AWS Amazon Route 53](https://aws.amazon.com/jp/route53/)

### Amazon CloudFrontの利用料金は？

*Amazon CloudFront*は、データ転送出力（インターネットおよびオリジン）とHTTP／HTTPS リクエストによる*従量課金制*をとっています。その他*割引料金プラン*も設定されており、**コスト低減**を図ることができます。

加えて、他のAWSサービス同様に*AWS無料枠*が設定されており、サインアップ後50GBのデータ送信（アウト）と2,000,000件のHTTP／HTTPSリクエスト、2,000,000件／月のCloudFront Function呼び出しが1年間無料提供されます。

## エッジロケーションの構成は？

*エッジロケーション*を説明するにあたり、最初に*関連用語*を説明しておきます。

・*オリジンサーバー*
オリジナルのコンテンツが格納されているウェブサーバーで、CDNが参照する接続サーバーを指します。
・*エッジキャッシュ*
CDNにより、次回以降でアクセスするコンテンツをキャッシュするサービスを指します。
・*POP*
POPとはPoint Of Presenceの略で、世界に配置されているエッジロケーションを指します。
・*リージョン別エッジキャッシュ*
AWSはリージョン別に物理ロケーションを分割管理しており、オリジンサーバーとPOPの間にリージョン別エッジキャッシュを設置しています。

*エッジロケーション*は*オリジンサーバーとPOP*を接続し、*エッジキャッシュ*として利用する構成をとります。*オリジンサーバーとのアクセス*は*リージョン別エッジキャッシュ*を介して行い、*オリジンサーバー*の**負荷を低減させる**形態を取っています。

### 日本のエッジロケーションは？

日本は*アジアパシフィックリージョン*として、*東京 に16*、*大阪 に1つ*のエッジロケーションを持っています。東京はコンテンツアクセスが多いため、エッジロケーションの設置数が多くなっています。

同様に、東京に*リージョン別エッジキャッシュ*を設置し、オリジンサーバーとの**レイテンシー低下を最小**に図っています。

### エッジロケーションの展開状況は？

AWSではコンテンツアクセスの*レイテンシーを低減*するために、**通信距離と利用ユーザ―**に応じてエッジロケーションを設置しています。そのため、国土面積が広い米国や*ブラジル・インド・ドイツ*に多くのエッジロケーションを展開しています。加えて、国数の多い*欧州やアジアパシフィック*においてもエッジロケーションが数多く設置されています。

現在、47か国90都市にある225以上のPOPにより、高速コンテンツアクセスの環境が整備されています。

### 北米地域のリージョンにおけるエッジロケーションは？

*北米地域*におけるエッジロケーションとリージョン別エッジキャッシュは以下の通り設置され、**サービス利用**されています。

*エッジロケーション：*
「米国」
・バージニア州アッシュバーン （6）・ジョージア州アトランタ （6）・マサチューセッツ州ボストン （3）
・イリノイ州シカゴ （6）・テキサス州ダラス/フォートワース （6）・コロラド州デンバー （2）
・カリフォルニア州ヘイワード・オレゴン州ヒルズボロ （3）・テキサス州ヒューストン （4）
・フロリダ州ジャクソンビル・カリフォルニア州ロサンゼルス （5）・フロリダ州マイアミ （4）
・ミネソタ州ミネアポリス・ケベック州モントリオール・ニューヨーク州ニューヨーク （2）
・ニュージャージー州ニューアーク （7）・カリフォルニア州パロアルト・ペンシルベニア州フィラデルフィア （2）
・アリゾナ州フェニックス （2）・ユタ州ソルトレイクシティ・カリフォルニア州サンノゼ （2）
・ワシントン州シアトル （3）・オンタリオ州トロント （2）・ブリティッシュコロンビア州バンクーバー
「メキシコ」・ケレタロ （2）

*リージョン別エッジキャッシュ： *
「米国」・カリフォルニア・オハイオ・オレゴン・バージニア

### 南米地域のリージョンにおけるエッジロケーションは？

*南米地域*におけるエッジロケーションとリージョン別エッジキャッシュは以下の通り、**サービス利用**されています。

*エッジロケーション：*
「コロンビア 」・ボゴタ 
「アルゼンチン」・ブエノスアイレス 
「チリ」・サンティアゴ 
「ブラジル」・リオデジャネイロ （2）・サンパウロ （2）

*リージョン別エッジキャッシュ： *
「ブラジル」・サンパウロ 

### 欧州/中東/アフリカ地域のリージョンにおけるエッジロケーションは？

*欧州/中東/アフリカ地域*におけるエッジロケーションとリージョン別エッジキャッシュは以下の通り、**サービス利用**されています。

＜欧州＞
*エッジロケーション： *
「オランダ」・アムステルダム （2）
「ギリシャ」・アテネ 
「ドイツ」
　・ベルリン （2）・デュッセルドルフ ・フランクフルト （10）・ハンブルク ・ミュンヘン （2）
「ベルギー」・ブリュッセル 
「ルーマニア」・ブカレスト 
「ハンガリー」・ブダペスト 
「デンマーク」・コペンハーゲン 
「アイルランド」・ダブリン 
「フィンランド」・ヘルシンキ 
「ポルトガル」・リスボン 
「英国」・ロンドン （9）・マンチェスター （2）
「スペイン」・マドリード （3）
「フランス」・マルセイユ ・パリ （5）
「イタリア」・ミラノ （3）・パレルモ ・ローマ 
「ノルウェー」・オスロ 
「チェコ共和国」・プラハ 
「ブルガリア」・ソフィア 
「スウェーデン」・ストックホルム （3）
「オーストリア」・ウィーン 
「ポーランド」・ワルシャワ 
「クロアチア」・ザグレブ 
「スイス」・チューリッヒ （2）

*リージョン別エッジキャッシュ： *
「アイルランド」・ダブリン 
「ドイツ」・フランクフルト 
「英国」・ロンドン

＜中東＞
*エッジロケーション： *
「アラブ首長国連邦」・ドバイ ・フジャイラ 
「バーレーン」・マナマ 
「イスラエル」・テルアビブ 

＜アフリカ＞
*エッジロケーション： *
「南アフリカ」・ケープタウン ・ヨハネスブルグ 
「ケニア」・ナイロビ 

### アジアパシフィック地域のリージョンにおけるエッジロケーションは？

*アジアパシフィック地域*におけるエッジロケーションとリージョン別エッジキャッシュは以下の通り、**サービス利用**されています。

*エッジロケーション： *
「インド」
　・バンガロール （3）・ハイデラバード （3）・コルカタ （2）・ムンバイ （4）
　・ニューデリー （5）・チェンナイ （4）
「タイ」・バンコク （2）
「中国」・北京・深川・上海・中衛
「中国特別行政区」・香港 （3）
「インドネシア」・ジャカルタ 
「マレーシア」・クアラルンプール （2）
「フィリピン」・マニラ
「日本」・東京 （16）・大阪 
「韓国」・ソウル （4）
「シンガポール」 （4）
「台湾」・台北 （3）
「ニュージーランド」・オークランド （2）
「オーストラリア」・メルボルン （2）・パース ・シドニー （4） 

*リージョン別エッジキャッシュ： *
「インド」・ムンバイ 
「シンガポール」
「韓国」・ソウル 
「日本」・東京 
「オーストラリア」・シドニー

## 世界中のエッジロケーションを用いたCDNサービスを有効活用しましょう

ウェブコンテンツは、テキストから画像・音楽・動画等多岐に渡ります。近年モバイルデバイスの急速な普及により、*高解像度のコンテンツを高速・高品質に配信*するニーズが高まっています。

*Amazon CloudFront*では、AWSのCDNサービスとして*全世界をカバーするエッジロケーション*が利用されています。*大容量コンテンツ配信*には特に**有効なサービス**なため、サービス品質を高めるために利用検討してみましょう。

近年、モバイルデバイスの急速な普及により、高解像度のコンテンツを高速・高品質に配信するニーズが高まっています。ここでは、AWSのエッジロケーションと関連用語を説明します。加えて、エッジロケーションの設置状況についても解説していきます。

AWSのエッジロケーションとは、AWSのリージョンデータセンターとは別にコンテンツ配信を行う仕組みを指します

AWSのエッジロケーションを利用するには、Amazon CloudFrontサービスを用います

モバイルデバイスで求められる高解像度のコンテンツを高速・高品質に配信することが可能です

AWSのエッジロケーションとは？CloudFrontなど関連用語も解説

システム開発の手法について、エンジニアの皆さんは学ばれたと思いますが、システム開発と運用は別個のものであると考えている方も少なくないのではありませんか？しかし、本来は開発と運用は両輪で、この2つがしっかり働いて、ITは機能すると考えるべきでしょう。

最近DevOpsという新たな概念や、SREという手法が登場して、これまでのシステム開発と運用の概念が大きく変わりつつあります。この記事では、**DevOpsとの違いを見ながらSREについて解説**していきます。まだご存じない方は、ぜひSREについて理解をしてください。きっとエンジニアの皆さんには役立つ知識です。

### SREはITサービスの信頼性を高めるアプローチ

SREとは何でしょう？SREは'Site Reliability Engineering'の頭文字を取った略語です。直訳すると、*「サイトの信頼性を高めるエンジニアリング」*ですが、サイトはWebサイトのことではありません。IT全般のサービスと解釈した方が正しいでしょう。すなわち、SREは「ITサービスの信頼性向上のための設計やアプローチ、またはそれを行うチーム」を指します。

従来からソフトウェア・エンジニアリングという、ソフトウェア開発や保守の効率を高めるエンジニアリングがありましたが、**SREはITサービスの信頼性向上を主眼にソフトウェアエンジニアリングを用いた新たなアプローチ**と考えて良いでしょう。

SREは2000年頃にGoogle社が自社のサービスである、**検索エンジンサイト「google.com」の安定稼働を図るために行った取組がその誕生の発端**です。

その取り組みでは運用エンジニアではなく、ソフトウェアエンジニアの力を借り、開発と運用の垣根を超えたアプローチを行いました。この時のアプローチである「Site Reliability Engineering」）の頭文字がSREの語源です。

SREの対象は「サイト（Site）」に限ったものではありませんが、Google社の信頼性向上取組みの対象が「google.com」のWebサイトであったことから、「サイト（Site）」の'S'が残され、「SRE」として広まりました。

当時のGoogle社の主なビジネス領域は「google.com」の検索サービス提供でした。そのため「google.com」に対する訪問者の信頼性確保が、ビジネスの成長と拡大にとって必須要件だったのです。

すなわち、当時のGoogle社にとっては、サイトの安定稼働が同社の生命線であり、それは「Google社のサービスに欠くことができない基本機能」であったのです。

現在、SREは「Webサイト」以外にも、広く分散コンピューティングシステムなどのアプローチの1つとなっています。

SREがITサービス信頼性向上へのアプローチの1つということは理解できたでしょうか？それでも、まだ漠然としている点があるかと思いますので、ここでは**SREによく似た概念、よく似た職種との違い**について明らかにしていきます。

### SREとインフラエンジニアの違い

最近では、SRE（エンジニア）募集という求人情報を時折目にしますが、SREという職種はIT業界でも広く認知され始めました。実際に「SRE課」などの部署を設けている企業もあり、サービス向上に向けた取り組みが注目されます。

しかし、その実態はブームに便乗し、従来のインフラチームが名称を変えただけの企業もあり、SREの本領が発揮されるまでには多少時間が掛かるかもしれません。

では、「SRE」と「インフラエンジニア」の仕事は何が違うのでしょうか？

**SREとインフラエンジニアの違いは、SREの業務範囲や求められるスキル範囲の広さ**です。それを比較表にすると、以下の通りです。

    *職種*                      　*インフラエンジニア*　                                *SRE*

*▪業務範囲：*　　　　　　*インフラのみ*                 *インフラ+アプリケーション*

*▪求められるスキル：*　 *ITインフラ関連*              *インフラ+アプリケーション開発や経験*

*▪方法論：*                  *特に決まったものはない*　  　　　　*Google社の「※SRE」*　

*【参考】：[「Site Reliability Engineering」](https://sre.google/sre-book/table-of-contents/)*

※当資料は英文ですので、日本語でお読みになりたい方は、ブラウザの翻訳機能を利用するか、翻訳本などをご利用ください。
*【参考書籍】：[SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム](https://www.oreilly.co.jp/books/9784873117911/)*

インフラエンジニアはキツイのか？その仕事内容やスキル、将来性を解説！

SREの概要について紹介しましたが、中には最近話題のDevOpsとの違いが分からなくなった方も少なくないと思います。ここでは、この両者の違いを見ておきましょう。

DevOpsは、システム開発担当と運用担当が協力し合い、主にユーザーに対するより良いサービスの提供を目指すMind（意識）を指します。DevOpsの概念を実現するには、開発担当と運用担当が互いをリスペクトし合いながらコミュニケーションを図り、より良いサービスという共通目標の達成に向けて切磋琢磨し合うことです。

DevOpsはアジャイル開発の1つの手法としても知られ、ソフトウェアの早期開発やリリース、安定稼働によるユーザー満足度の向上に重きを置いています。

SREを生み出したGoogle社は、**DevOpsを思想とするなら、SREはその思想に基づく役割である**と捉えています。わかりやすく言うと、「DevOpsではチーム同士の連携を文化や哲学的な視点から捉え、SREはその実現に向け、ソフトウェアの活用という手法を用いたチーム体制や機能」を指します。

SRE（エンジニア）になると年収はどれくらいなのか気に掛かる方も少なくないでしょう。SREはインフラに関する知見と、アプリケーション開発に関する知見の両方が必要だということが分かったと思います。

つまり、*SREはインフラエンジニアとアプリケーションエンジニアの両方のスキルを有する「エンジニア」*であることが求められるのです。

年収については明らかにはなっていませんが、求人情報などから判断すると、**SREの年収の中間値は700～800万円前後と推定**され、エンジニアの中では高年収の部類に入ります。SREの求人情報に関しては以下を参照してみてください。

*【参考】：*[SE・システムエンジニア(IT／通信／インターネット) 求人一覧](https://mynavi-agent.jp/jobsearch/job1_01/kw_SRE/result.php?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv02)

インフラエンジニアの年収はいくら？年収をアップさせる方法も解説！

SREの概念は理解できたでしょうか？ここでは、**SREの具体的なアプローチの方法**について簡単に紹介します。大きくは以下の流れになります。

Google社ではSREチームの編成を行う際に、チームの50%から60%までは正規のソフトウェアエンジニアとし、残り40%から50%は他のスキルを持つエンジニアを充てています。つまり、**エンジニアの垣根を越えて、さまざまな知見を結集し、さまざまな視点からアプローチを行うことが求められる**のだと理解できます。

どんなサービスでも、信頼性は100%であることがベストですが、人命に関わるような仕組みはともかく、大半のサービスで100%の信頼性を確保するのは至難の技であり、現実的ではありません。

この目標値をSLO（Service Level Objective）と言います。よくデータセンターとの契約などで、SLA（Service Level Agreement）という言葉を耳にしますが、SLAは金銭的な補償を伴う「稼働率の保証」であり、SLOは補償を伴わない目標値です。

この**SLOの設定は、SLI（Service Level indicator）によって、提供するサービスの実際の計測量を把握することから始めます**。

SREと「インフラエンジニア」との最大の違いは、カバーする役割の範囲が異なる点でした。

**SREは運用する開発システムの増大に比例して、保守運用工数が増えることがないよう、自らアプリケーションに関与したり、自動化プログラムを書いたりして、主体的に自動化や省力化を行います**。

SREの'E'は言葉通り、まさに「エンジニアリング」なのです。

用語の記事（1ページ目）