初めに ついに1次情報を見つけました。嬉しい！やってみよう！ やってみた Linux/macOS編です。7ページから8ページにかけてやってみます。 yum パッケージをアップデートする $ sudo yum update -y git コマンドをインストールする $ sudo yum install git -y OpenVPN Inc の easy-rsa リポジトリをクローンする $ git clone https://github.com/OpenVPN/easy-rsa.git easy-rsa ディレクトリに移動する $ cd easy-rsa/easyrsa3 PKI環境を構築する PKI は、Public Key Infrastructure の略であり、「公開鍵基盤」と訳されます。これは、「公開鍵」による「基盤（インフラ）」を表しています。「公開鍵」とは「公開鍵暗号方式」という特殊な暗号技術を指します。この技術を用いることで、暗号化、デジタル署名、認証といった様々なセキュリティ対策が実現できます 以下リンクより抜粋。 $ ./easyrsa init-pki 認証局を立てる 信頼できる第三者機関 (TTP： Trusted Third Party)に公開鍵の所有者を保証してもらう方法です。TTP は、公開鍵の所有者の本人性をなんらかの方法で確認し、公開鍵とその所有者を保証する証明書(Certificate)を発行します。証明書には、公開鍵とその所有者を証明する情報が記載され、改ざんを防ぐために TTP の署名が付与されます。証明書を発行する TTP のことを、認証局 (CA： Certification Authority)といいます。 以下リンクより抜粋。 $ ./easyrsa build-ca nopass Common Name は適当に入力します。 Common Name (eg: your user, host, or server name) [Easy-RSA CA]:testname サーバ証明書と秘密鍵を生成する $ ./easyrsa build-server-full server nopass クライアント証明書と秘密鍵を生成する $ ./easyrsa build-client-full client1.domain.tld nopass ACMにキー・証明書をアップロードするためのディレクトリを作成する mkdir ~/custom_folder 作成したキー・証明書を作成したディレクトリに移動する $ cp pki/issued/server.crt ~/custom_folder $ cp pki/private/server.key ~/custom_folder $ cp pki/issued/client1.domain.tld.crt ~/custom_folder $ cp pki/private/client1.domain.tld.key ~/custom_folder 作成したディレクトリに移動する $ cd ~/custom_folder/ ACMにサーバ証明書・サーバの秘密鍵・中間証明書をアップロードする $ aws acm import-certificate --region ap-northeast-1 --certificate \ fileb://server.crt --private-key fileb://server.key --certificate-chain fileb://ca.crt アップロードできました！ 接続失敗 以下の記述があるのですが、うまくいきません。 --- 引用ここから --- 任意のテキストエディタを使用してクライアント VPN エンドポイント設定ファイルを開き、 タグ間にクライアント証明書の内容を追加し、 タグ間にプライベートキーの内容を追加します。 <cert> Contents of client certificate (.crt) file </cert> <key> Contents of private key (.key) file </key> --- 引用ここまで --- こうしないとダメみたいですね。 key client1.domain.tld.key cert client1.domain.tld.crt 参考記事 1.3 PKI で実現できること 3 認証局と電子証明書

本シリーズのゴール：AWSアカウントの作り方 & IAMの基本のキ 動画1：本シリーズの説明　5min ハンヅオン用のAWSアカウントを作ってもらう IAMの基本 IAMポリシー・IAMユーザー・IAMグループ・IAMロールについて学ぶ IAMリソースを作成できるようになる 動画2：AWSアカウントの作り方　7min 既に存在しているので省略 動画3：ルートユーザーと IAM ユーザーについて学ぶ　5min ルートユーザー Eメールアドレス+パスワードでログイン 全AWSサービスリソースに対して完全なアクセス権限　←権限が強すぎる 日常タスクでは使わない IAMユーザー アカウントID + IAMパスワードでログイン 紐づいているIAMポリシー権限で認められた操作のみ可能 利用者ごとにIAMユーザーを作成し、利用者はIAMユーザーでログインして作業する 今後のウェビナーにおいて、IAMユーザーが指定した権限を行使できるか、または権限を限定できているかを確認する 例えば...AWS EC2を取り扱う場合 インフラ担当　Administratorポリシー インスタンス表示　○ インスタンス作成　○ アプリ担当　EC2ReadOnlyポリシー インスタンス表示　◯ インスタンス作成　× AWSのサービスそれぞれにおいて、権限を許可・限定を行うことができる ちなみ今後のハンヅオンで登場するサービスは... Amazon EC2 数分で起動し、従量課金型の仮想サーバサービス インスタンスタイプを需要に合わせて選択可能 必要な時に必要な分だけリソースを起動できる Amazon S3 99.999999999%の耐久性を持つストレージサービス 容量無制限な安価なストレージ 静的Webホスティングサービス 様々なAWSサービスと連携 動画4：IAM ユーザーを作成する　12min 実際にIAMユーザーを複数作成し、ログインし、権限を確認する作業を行う。 この辺りから、自分がこれまで指示通り手を動かしていただけの作業の意味が理解できるようになってきた。強い。 具体的には、IAMユーザーを3つ作成する 全ての権限を与えられている(多分) S3のReadOnly 何も権限を持たない これらを作成し、S3の画面へ遷移し、IAMの実力を確認する。 前半まとめ 自分がこれまで指示通り行ってきた作業の意味が少しずつ理解できてきた。 学ぶ順番が正しいかどうか少し不安ではあるが、とても分かりやすく、理解に繋がっていることから、もう少し続けてみようと思う。 この記事に目を通してくださった皆様、おすすめのAWS学習手順・学習教材などございましたらコメント頂けますと幸いです。最後まで読んでいただきありがとうございました！

Amazon Lightsaiは、月額３５０円くらいからワードプレスを一瞬で立ち上げることが出来る機能があります。 面倒臭い契約とか管理画面とか一切なしで、インスタンスも不必要になったら速攻消せるので契約とかもありません。 非常に便利で安いので複数のワードプレスメディアを立ち上げるのに結構使っていました。 でも、長らく使っているとAmazon Lightsailでワードプレスを運営するのはサーバーが壊れるリスクを気をつけないとヤヴァイなって思っています。 特に、プラグインをやたらめったら入れ替えまくると結構簡単にバグると思います。 それで、サイトにアクセス出来なくなります、それで、数回はインスタンスを再起動してれば治るんだけども、 何回も何回もインスタンスを再起動しまくってると、いよいよインスタンスが壊れて起動しなくなります。 そうすると、SSH接続すら出来なくなってオワコンです。 私は、これまでロリポップとXサーバーしか使ってこなかったんで、他のサーバーのことをよく知らないが、 ロリポップは安いが重い、Xサーバーは高性能だが高いという利点欠点がありました。 でも、両者サーバーは死んで壊れてデータが消える欠点はなかったので、こういうサーバー破損のリスクを軽んじていました。 それで、過去に一個Lightsailでサイトをダメにしています、私。 結局、Amazon Lightsailは安いし軽いし、立ち上げが楽ちんだし、もう慣れてしまって他のサービス行くいのも億劫なので、 普通に使っててそんなに壊れまくらなければ、今後も使い続けるような気がする（分からないけど）のだが、 プラグインの入れ替えの時はマジで気をつけるし、定期的にバックアップは必ず取った方がいいです、Lightsailでワードプレス運営してる人。 サーバー壊れてインスタンス立ち上がらなくなったらおわりなので。

Well-Architectedの勉強会でやったことをまとめてみる 昨年会社の有志で、Well-Architected framework(以下W/A)の勉強会を開きました。 そして勉強のやり方自体を試行錯誤するうちに、テーマを決めて実際の設計をレビューするという形式に辿り着きました。 単にペーパーを読んでディスカッションしているうちは気づかなかった観点や、実践的な設計指針が見える様になりとてもためになったので共有します。 対象読者 AWSには馴染んできたけど、まだW/Aを読んだことない、読んだけど設計に活かしきれないという方が対象です。私自身まだ道半ばです。 私がこの記事を書いたのは、お馴染みAWS最強メディアのDevelopersIOさんで『【初心者向け】AWS Well-Architected ドキュメントの歩き方』という記事が公開されたことで、ふと勉強会のことを思い出したのがきっかけです。 AWSが公開しているW/Aの資料は読んでみると、初心者でも「ふーんなるほどね」と納得はできるのですが、腹落ちして設計に活かすのはちょっと難しいです。私も初心者のときに読みましたが、理解したようで頭の中を横滑りする感覚でした。 DevelopersIOさんの記事もよくまとまっていて感動しますが、初心者が読むと同じような気持ちになるのではないかと思います。 この記事では具体的な勉強法を紹介することで、理解を深めていただければ嬉しいです。 AWSの公式ドキュメントが教科書、DevelopersIOさんの記事が副読本という位置づけで勉強していくのが今のおすすめです。 勉強会の進め方　：　実際の設計をレビューしてディスカッションする 我々は毎週1回輪読で1人が発表して、内容について参加者でディスカッションする形式で進めました。 題材はAWS Well-Architected フレームワークの概要の資料です。 各回の内容は以下の通りです。 W/Aの5本の柱のうち1つを選んで、考え方を要約して発表する。 参加者はその章を読んでくる。 発表者は簡単に重要だと思うポイントを要約する。 実際の設計を、選んだ柱の観点からレビューする。 「付録：質問とベストプラクティス」と比較しながらレビューして、3つのポイントを抽出する。 W/Aのベストプラクティス通りに設計できている点 W/Aのベストプラクティスの観点から改善できる点 判断できない設計、ベストプラクティス自体の意味わからない点 設計書全体を余すことなくやる必要はなく、それぞれ２〜３箇所ぐらいを指摘する。 発表者が選んだ点について、参加者全員でディスカッションする。 設計の改善方法を出し合う。 W/Aに近づくためのサービスを紹介しあう。 ドキュメントの意図や、実装方法をディスカッションする、など。 それぞれ詳細を書いていきます。 具体的な3Step Step1 5本の柱のうち1つを選んで、考え方を要約して発表する。 ここはごく簡単で良いと思います。 参加者は毎回読んでくるのが前提となるため、特にフォーカスしたいポイントがなければドキュメント等も作成しなくて良いと思います。 Step2 実際に過去作成した設計書を、選んだ柱の観点からレビューする。 勉強会で最も理解が深まるのがこの活動です。 ここでは実際の設計をW/Aの観点からレビューしていきます。ベストプラクティスと比較したときにどのような設計になっているかがポイントです。 AWS Well-Architected フレームワークの資料には、付録として質問とベストプラクティスがありますのでこれを活用しました。 この項目ではW/Aの各観点について、質問＋回答＋ベストプラクティスがセットになっています。参考にリンクを貼っておきます。 付録:質問とベストプラクティス > パフォーマンス効率 > 選択 リンク先の引用 一つ引用してみます。 質問 PERF 1 どのように最良パフォーマンスのアーキテクチャを選択するのですか? 回答 多くの場合、ワークロード全体での最適なパフォーマンスのためには、複数のアプローチが必要になります。Well-Architected なシステムでは、パフォーマンスを向上させるために複数のソリューションと機能が使用されています。 ベストプラクティス 利用可能なサービスやリソースを理解する: クラウドで利用できる幅広いサービスやリソースに関する情報を取得し、その内容を理解します。お客様のワークロードに関連するサービスや設定の選択肢を認識した上で、最適なパフォーマンスを実現する方法を理解してください。 これらを読み込んで下記の観点でレビューしていきます。レビュー対象の設計書と見比べながら進めます。 W/Aのベストプラクティス通りに設計できている点 W/Aのベストプラクティスの観点から改善できる点 判断できない設計、ベストプラクティス自体の意味わからない点 発表資料のサンプルも載せておきます。大体マークダウンかスライド形式で書くことが多かったです。（好みの世界だと思います。） 「パフォーマンス効率」の発表資料のサンプル ベストプラクティス通りにできてている点 選択 利用可能な設定オプションを評価する: さまざまな特性や設定オプションと、それらがストレージにどのように関連するかを評価します。ワークロードのためのストレージ容量とパフォーマンスを最適化するために、プロビジョンド IOPS、SSD、磁気ストレージ、オブジェクトストレージ、アーカイブストレージ、またはエフェメラルストレージをどこでどのように使用するかを理解してください。 設計書のXXの箇所で、サーバーの選定において必要な条件が整理されている。 YYという観点からt3のサーバーが選ばれているため、W/Aに設計できていると言える。 改善できる点 モニタリング ワークロードのパフォーマンスを測定するための主要業績評価指標 (KPI) を確立する: ワークロードが意図したとおりに動作しているかどうかを示す KPI を特定します。たとえば、API ベースのワークロードでは、全体的なレスポンスレイテンシーを全体的なパフォーマンスの指標として使用でき、e コマースサイトでは、購入数を KPI として使用できます。 この設計書の中ではKPIが明確に定義されておらず、モニタリング対象のパフォーマンス指標がなぜXXになったのかがよくわからない。 システムの性質を考えると、YYの指標の方が望ましいのではないか？ よく分からなかった点 トレードオフ トレードオフが顧客と効率性にどのように影響するかを明らかにする: パフォーマンス関連の向上を評価する場合、どの選択肢が顧客とワークロードの効率性に影響するかを特定します。たとえば、key-value データストアの使用がシステムパフォーマンスを向上させる場合、その結果整合性の性質がお客様に与える影響を評価することが大切です。 パフォーマンスとトレードオフの関係となる具体的な要素がよく分からなかった。結果整合性以外の例を知りたい。 Step3 ディスカッションする 発表資料を題材にディスカッションをすることが大事です。 他のプロジェクトでも応用できなそう点を探す、改善方法を具体的に議論する、よく分からなかった点を補い合う、等のディスカッションができれば、勉強会が有意義になります。 大体各テーマごとに２回発表を回して、5本の柱×2回＝10回勉強会を開きました。 その他のTips 勉強会の人数とメンバー 人数：５人前後 心理的安全性を確保する。 Step2/3が知見を貯めて成長する良い機会となるため、ディスカッションできるようにメンバーを決めるのが良いです。 大体５人ぐらいが限度かと思うのと、お互いディスカッションができるぐらいの心理的安全性を確保するのもポイントになると思います。 発言をまんべんなく促す、スキルが低いものに対して理解度を尋ねて質問の機会を作る、といった工夫があると良いかもしれないです。 開催頻度とテーマ選び 毎週１回開催 各テーマごとに２名で担当する 各テーマ（柱）を深堀りして理解度を深めようと思うと、それなりに各テーマを２回は扱った方が良いです。 １回につき１テーマととなると、隔週で開催すると２０週＝５ヶ月かかってだれてしまいます。なので毎週１回ぐらいをおすすめします。 また１テーマ1人にすると、何らかの理由で発表ができずに会自体がスキップされたりします。 ディスカッションの種があれば結構持つので、各会２人をアサインして最低１人は発表できるようにすると良いでしょう。（発表回数増えるの大変ですが…） 参考 AWS公式ドキュメント AWS Well-Architected Well-Architected 概要(html) Developers IO(いつもお世話になってます） 『【初心者向け】AWS Well-Architected ドキュメントの歩き方』

AWS SDK を使用してエラーが発生した場合、デフォルトでリトライがおこなわれます。AWS SDK for PHP によるリトライを簡単に整理しました。 基本的な戦略 参考) AWS でのエラーの再試行とエクスポネンシャルバックオフ サーバーエラー(5xx)またはスロットリングエラー、または接続失敗やタイムアウトなどのネットワークエラーといった、リトライにより問題が解消する可能性があるものは、リトライする。 クライアントエラー(4xx)などのリクエスト内容自体に問題があるものは、直ちにエラーとする。 AWS SDK for PHP のリトライ 参考) AWS SDK for PHP リトライ・タイムアウト関連の設定 Client 生成時のパラメーターまたは環境変数で指定します。 クライアント設定 環境変数 説明 デフォルト値 retries.mode AWS_RETRY_MODE リトライモード legacy retries.max_attempts AWS_MAX_ATTEMPTS リトライ回数 3 http.connect_timeout 接続タイムアウト時間 (秒) 0 (無期限) http.timeout タイムアウト時間 (秒) 0 (無期限) 指定例) $s3 = new Aws\S3\S3Client([ 'region' => 'ap-northeast-1', 'version' => 'latest', 'retries' => [ 'mode' => 'standard', 'max_attempts' => 3, ], 'http' => [ 'connect_timeout' => 10, 'timeout' => 60, ], ]); connnect_timeout は TCP 接続に対するタイムアウト時間、timeout は TCP 接続を含む全体のタイムアウト時間になります。ネットワークの問題でレスポンスが受信できない場合、デフォルトでは無期限で待ち続けるためリトライ自体も発生せず、その後に通信が回復したとしても永遠にブロックしてしまうこともあるので注意が必要です。 ただ TCP 接続ができない場合は、タイムアウト未指定でも 7 分弱でタイムアウトエラーになりました。このあたりは OS や SDK の実装に依存してくるかもしれませんし、期待すべき動作ではないと思います。 このあたりはおそらく Guzzle の話だと思いますが、timeout は必ず指定しましょう! リトライモード AWS SDK for PHP のリトライ処理には、以下のモードが用意されています。 legacy (デフォルト) standard : 成功する可能性の低い再試行を防ぐために、再試行のクォータシステムを追加 adaptive : standard + クライアント側のレートリミッターを追加 (experimental) adaptive はまだ実験的機能とのこと。legacy は RetryMiddleware、standard および adaptive は RetryMiddlewareV2 で実装されています。 以下のようなリトライ要因が発生した場合にリトライし、最後に発生したエラーを例外として返します。 接続タイムアウト (connect_timeout 設定) タイムアウト (timeout 設定) サーバーエラー受信 (500, 502, 503, 504 のみ) スロットリング関連のエラー受信 (RequestLimitExceeded, Throttling など) 例外 エラー発生時の例外は AWSException をベースとした例外が throw されます。 通信上のエラー(接続失敗やタイムアウト)がありレスポンスの受信ができなかった場合、AWSException->isConnectionError() が true となり、AWSException->getAwsErrorCode() は空になります。AWSException->getPrevios() で Guzzle の例外を取得してエラー要因を知ることができます。 エラーレスポンスを受信した場合、AWSException->isConnectionError() は false、AWSException->getAwsErrorCode() でエラー要因(文字列)が返されます。AWSException->getPrevios() で Guzzle の例外を取得して HTTP のエラー要因を知ることもできます。 Guzzle の例外についての詳細はこちら。 Case isConnectionError() getAwsErrorCode() getPrevios() 通信エラー true - GuzzleHttp\Exception\ConnectException エラーレスポンス受信 false エラーコード(文字列) GuzzleHttp\Exception\RequestException

アプリの監視について、調査する機会があったので備忘録としてまとめます。 コンテナアプリの監視について 例えば、ECS上で稼働するアプリケーションの場合、監視用エージェントをサイドカーで同梱して、 外部サービスにログ・メトリクスを連携することが多いと思います。 サイドカーパターンを採用する理由としては以下などがあるかと思います。 ・メインコンテナに優先的にリソースを割り当て、低レイテンシで応答させることができる ・ログのルーティング設定を変更する際にアプリに手を加える必要がなくなる この時、同梱した監視用エージェントが頻繁に外部サービスにログ・メトリクスを送信していると、 リソースを食いつぶしてしまって、メインの機能に影響が出る可能性があります。 そのため、多くの場合、アプリコンテナから送信されたログ・メトリクスをエージェントが バッファリングしてまとめて外部サービスに送信するといった手法をとります。 例えば、Datadogを使用する場合は、Datadogが提供するコンテナイメージを利用することで 手軽にコンテナ監視を実現することができます。 Lambdaの監視について Lambdaの場合はECSのように、実行環境に好きなコンテナを同梱することができません。Lambdaの場合、 Lambda Extensionsを用いるのがよいと考えられます。Lambda Extensionsを用いることで 関数とは別のプロセスとしてモニタリング用エージェントなどの配置などが可能になります。 Lambda Extensionsについてはこちらの記事が非常に分かりやすく参考になりました。 例えば、Datadogの場合、Datadog Lambda 拡張機能というものが提供されています。 これをアプリが動くLambdaに対して、Lambdaレイヤーとして追加することで 関数実行中のカスタムメトリクスおよびログの同期的送信が可能になります。 なおもう一つ似たものとしてDatadog Lambdaライブラリがありますが、 こちらはライブラリとしてプログラムの中にインポートすることで、カスタムメトリクスの送信を 可能にするもので、ログの送信には対応していないようです。 現状、ログの送信に対応しているDatadog Lambda 拡張機能の方が使い勝手が良さそうですね。

OpenVPN クライアントでのTLSバージョンの確認 ログのパスは以下の通り。 OpenVPN/log/downloaded-client-config.log ログにはTLSv1.2と記載されている。 2021-06-05 08:13:56 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA AWS VPN クライアントでのTLSバージョンの確認 ログのパスは以下の通り。 Amazon/AWS VPN Client/WinServiceLogs/username/win_service_aws_client_vpn_connect_20210605.log ログにはTLSv1.2と記載されている。 2021-06-05 06:22:37.903 +09:00 [DBG] [TI=11] [4900] Sat Jun 05 06:22:37 2021 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 参考記事

背景 新卒でとあるDX関連のベンチャーに入社してから、2ヶ月が経ちました。 最初は一般的な新入社員研修だったので、開発業務を始めてからは約3週間くらいです。 新機能の設計からやってようやく実装に入る段階まできました。(もちろん先輩方の力を借りながら) そこで、設計の中で学んだことをアウトプットしようと思いこの記事を書いています。 DynamoDBとは Amazon DynamoDB は、規模に関係なく数ミリ秒台のパフォーマンスを実現する、key-value およびドキュメントデータベースです。これはフルマネージド型でマルチリージョン、マルチアクティブで耐久性があるデータベースであり、セキュリティ、バックアップと復元、インターネット規模のアプリケーション用のインメモリキャッシュが組み込まれています。DynamoDB は、1 日に 10 兆件以上のリクエストを処理することができ、毎秒 2,000 万件を超えるリクエストをサポートします。 (公式ドキュメントより) 私にとって初NoSQLです。 メリット 1. 早い NoSQLなので、RDSやAuroraなどのRDBよりもデータの取り出しが高速です。 キャッシュは瞬時に呼び出したいケースも多いかと思いますので、大きなメリットです。 2. 安い AWSの料金体系は複雑で一概には言えませんが、ある程度のアクセス数になるとRDBやAuroraと比べて料金が安いです。 3. データの保存期間を設定できる これがキャッシュを扱う際に一番のメリットだと思います。 TTL(Time to Live)という機能を使い、設定した期間に達したデータを削除することができます。 キャッシュは期間を決めて一時的に保存するケースが大半かと思いますので、ありがたい機能ですね。 (公式ドキュメント)

エラー 以下の Dockerfile をもとにビルドする FROM public.ecr.aws/lambda/python:3.8 COPY . ${LAMBDA_TASK_ROOT} RUN pip install -r requirements.txt CMD ["app.handler"] すると以下のようにエラーが出た アクセス権がない様子 $ docker build -t iconow-lambda . [+] Building 1.1s (3/3) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 31B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => ERROR [internal] load metadata for public.ecr.aws/lambda/python:3.8 0.9s ------ > [internal] load metadata for public.ecr.aws/lambda/python:3.8: ------ failed to solve with frontend dockerfile.v0: failed to create LLB definition: unexpected status code [manifests 3.8]: 403 Forbidden 解決策 以下を叩いて認証を得る aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws

概要 AWSにおけるDNSサービス。 DNS(Domain Name System)とは名前解決のためのシステムで要はURLにおけるドメイン(www.sample.co.jpみたいなやつ)をIPアドレスとして機械が読み取れるように変換してくれるもの。 AWSではルーティングやリージョンやVPCに対してELB・フェイルオーバーのような使い方をしている印象を受けた。 DNSには権威DNSサーバー(名前解決機能がある)と一時期的にキャッシュとしてDNSを保持しておくためのキャッシュDNSサーバーがある。 Route53はAWSが提供する権威DNSサーバーでポート53で動作するのでRoute53と呼ばれているらしい。 特徴 マネージド型サービス 主たる機能はドメイン登録/DNSルーティング/ヘルスチェックの3つ ポリシーでルーティングを設定する トラフィックルーティング/フェイルオーバー/トラフィックフロー等様々な条件でルーティングを設定できる AWS側で100％の可用性が保証されているSLA(Service Level Agreement)、なぜなら落ちたらルーティングが止まるから。 利用フローは以下の通り。 ドメインを登録 ドメイン名と同じホストゾーンと呼ばれるものが自動生成される ホストゾーンにルーティング方法となるDNSレコードを作成する トラフィックルーティングを設定する ホストゾーン ドメインとサブドメインのトラフィックをルーティングする方法についての情報を保持するコンテナ。 タイプとしては以下の2パターンある。 パブリックホストゾーン インターネット上に公開されたDNSドメインレコードを管理するコンテナ インターネットのDNSドメインに対するトラフィックのルーティング方法を定義する プライベートホストゾーン VPCに閉じたプライベートネットワーク内のDNSドメインのレコードを管理するコンテナ VPC内のDNSドメインに対してどのようにトラフィックをルーティングするかを定義する 1つのプライベートホストゾーンで複数VPCに対応できる VPCが相互アクセス可能であれば複数リージョンのVPCでも、同じホストゾーンを利用できる DNSレコード ルーティング方法を設定するためにDNSレコードを作成し、各種レコードを設定する。 レコードの種類には以下の4つがある。 それ以外はこちらを参照。 SOA → ドメインのDNSサーバー/ドメイン管理者のメールアドレス/シリアル番号などを保持する。 保持した情報でゾーン転送時に情報が更新されているかどうか判断してくれる。 A → ホスト名とIPアドレスの関連付けを定義するためのレコード。 MX → メールの配送先(メールサーバー)のホスト名を定義するレコード。 CNAME → 正規ホスト名に対する別名を定義するレコード。 特定のホスト名を別のドメインに転送するときに利用する。 ドメインを他社から購入してAWSサービスのドメインとして使いたい場合はこちらのレコードを定義する。 ALIASレコード Route53固有の仮想リソースレコード。 特徴としては以下の通り。 DNSクエリにAWSサービスのエンドポイントのIPアドレスを返答する 静的Webサイトとして設定されたS3バケット、CloudFront、ELB、ホストゾーン内のリソースレコードセットに対して設定できる DNSクエリに対するレスポンスが高速である CNAMEにマッピングできないZoneApex(ドメイン名そのもの)を設定可能 ALIASレコードに対するクエリが無料であり、Route53と連携したDNSLookupを高速化する CloudFrontでのクエリ回数を削減する ルーティングパターン 主に以下の4つのルーティング方式を用いる。 シンプルルーティング → レコードセットで事前に設定された値のみに基づいてDNSクエリに応答する。 性的なマッピングによりルーティングを決定。 要は一番普通のやつ、このドメインはこのIPアドレス(実際はそれが割当されているEC2インスタンス等)へ通してくださいってやるやつ。 加重ルーティング → 複数エンドポイント毎に重み付けをしてそれに従ってDNSクエリを応答させる。 重み付けの高いエンドポイントに多くルーティングするようになる。 フェイルオーバールーティング → Route53の大きな特徴の一つでもある。 RDSでのフェイルオーバーはAZ間だったが、こちらは例えば同じVPC構成を別リージョン等に作ってこちらを設定するとヘルスチェックの結果に基づいて、 プライマリなVPC構成があるリージョンからセカンダリなVPC構成へとフェイルオーバーしてくれる。 利用可能なリソースのみにルーティングされる。 マルチバリュールーティング(複数値回答ルーティング) → ランダムに選ばれた最大8つの別々のレコードを使用してIPアドレスを設定することで、複数の値を返答する。 IPアドレス単位(つまりリソース及びそれが存在するリージョンごとに)でRoute53でヘルスチェックを作成し実行することで、正常なリソースの値を返す。 フェイルオーバーとは違い、設定したIPアドレスの分だけヘルスチェックが行われ通過したリソースのIPアドレスがすべて返ってくるので、 返ってきたIPアドレスのうち最も適切なところへルーティングすることでDNSを使用したアベイラビリティ及びロードバランシングを実現しているとも言える(ELBに似た役割) またそれ以外に地理的な条件でルーティングする方法として以下の3つのルーティングが存在する。 レイテンシールーティング → リージョンの遅延でDNSクエリをルーティングする、つまりリージョン間の遅延が少ない方へルーティングされる。 よって、基本的にはユーザーの最寄りのリージョンへとルーティングされる。 位置情報ルーティング → ユーザーのIPアドレスにより位置情報を特定して地域ごとに異なるレコードを返す。 ネットワーク構成に依拠しない、精度の高いレコードの区分けが可能。 地理的近接性ルーティング → ユーザーとリソースの場所に基づいて地理的近接性ルールを作成して、トラフィックをルーティングする。 例えばAWSリソースを使用している場合はリソースを作成したAWSリージョンに、AWS以外のリソースを使用している場合はリソースの緯度と経度に従ってルーティングされる。 必要に応じてバイアスを設定して特定のリソースにルーティングするトラフィックの量を変更できるが、トラフィックフローを利用する必要がある。 トラフィックフロー → ルーティングパターンではないが、地理的近接性ルーティングを利用する際に設定しないといけないもの。 フロー図でルーティングのパターンを設定できる。 ハンズオン 今回のハンズオンでは前述の通りドメインがないと話にならないのでどこかで用意しないといけない。 AWSで購入することもできるがいいお値段がするので、Freenomのような様々な制約等があるが無料で利用できるドメインを使ってハンズオンすることになる。 なお今回はマルチAZ及びマルチリージョンでのフェイルオーバーをやるということが前提なので、リソースのコピーをやることになる。 EC2のコピーはAMIを作成してそれをリージョンを指定してコピーすることで、RDSはスナップショットを作成して同じようにリージョンを指定してコピーすることを復習として書いておく。 VPC等は改めて作る。 ホストゾーン 例によってウィザードを使って設定していく。 ホストゾーンを作ると以下のように設定される。 Aレコードは自分で作成しないと出てこないがNS、SQAはホストゾーン作成と同時に作られる。 この2つを削除するにはこれ以外のレコードは削除しないといけない。 また、AWSから購入したドメインであるならばこれであとはルーティングに応じてレコードを作成すればいいのだが、それ以外のドメインの場合は先程作られたNSレコードのルーティング先にある値を購入したドメインサイト等の設定で当該ドメインと結びつける設定をしないといけない。 シンプルルーティング ルーティングポリシーは以下のように選択できる。 あとはIPアドレスを設定すれば先程のようにAレコードができる。 フェイルオーバールーティング レコードタイプはA、ルーティング先をELBのエイリアスに設定するとリージョン及びそこに属するELBが選択できるので設定して、プライマリかセカンダリを選択する。 もちろんフェイルオーバー先の環境は用意しておく(今回はマルチAZかつマルチリージョンという要件だったので別リージョンへ作る) セカンダリも同じように設定。 試しにプライマリのApacheを停止してみる。 するとindex.htmlが以下の通りだったのが こちらへとフェイルオーバーしているのが確認できる。 加重ルーティング リソース毎にレコードをつける。 例えば2つのリソースへ重み付けを行う場合は2つのレコードを作成する。 以下のように設定して、2つ目も重量の項目だけ任意の数に設定する。 すると以下のようになる。 レイテンシールーティング 例によってリソースのIPアドレスと今回はリージョンも設定する。 複数ある場合は同じように設定する。 設定すると以下の通りになる。 位置情報ルーティング リソースのIPアドレスの他に今度はリージョンではなく、地域を設定する。 例えば東京リージョンのリソースならアジアに、ロンドンリージョンなら欧州を選択するのが適切。 設定すると以下の通りになる。 マルチバリュールーティングとヘルスチェック まずはリソースごとにヘルスチェックを作成する。 2つ作ると以下の通りになる。 ステータスでリソースの状態が確認できる(不明はリソースが存在しない状態、今回は試しに削除済みのリソースのIPアドレスで作っただけなのでこうなる) あとはレコードを作る。 リソースごとにレコードを作るので2つなら2つレコードを作成する。 作成すると以下の通りとなる。