あきのの勉強ノート

書くところに困ったネタの集まり

AWS Developer Associate 勉強メモ その2

前回の続きです。

akkino-d-en.hatenablog.com

 

さっくり低カロリーに進めていきます。

今回はELBとEBSやEFSに関してです。

www.udemy.com

セクション4

  • Scalability & High Availability
  • Elastic load balancing(ELB)
  • Load Balancer Stickiness
  • Cross Zone Load Balancing
  • SSL Certificates
  • Server Name Indication
  • Connection Draining
  • Auto Scaring
  • ASG Brain Dump
  • Scaring Policy

セクション 5

  • EBS
  • GP2, IO1, ST1, SC1
  • Instance Store
  • EFS
  • EBS vs EFS

知らなかったこと

Server Name Indication

一台のELBで複数のSSL/TLS証明書をサーバ名ごとに設定するための方法。

ALBとNLBのみ対応している。

マルチドメイン証明書とは異なり、ドメインごとに個別に追加削除が可能。

dev.classmethod.jp

EFS

EFSの具体的なセットアップ方法や使い方(EC2インスタンスとして使用する)を知らなかった。

また複数インスタンスで共通化でき、AZをまたいで100個のインスタンスに紐づけることが可能。

ただしEBSよりも価格が三倍ほど高いので注意。

使用する場合はamazon-efs-utilsをマウントするインスタンスに導入し、紐づける。

business.ntt-east.co.jp

 

 まとめ

今回はAWS SAAの時とほとんど同じで知っていることばかりでした。

ただEFSは概要しか知らなかったので、実際のハンズオンでEFSがどのように動作しているか確認でき、とても勉強になりました。(Security Group設定しないといけないのとか絶対忘れそう) 

 

 

AWS Developer Associate 勉強メモ その1

前回(半年前)までAWS SAAの資格勉強をしていたのですが無事合格できましたので、今回からはAWS DeveloperとSysOpsの勉強をしていきます。

note.com

 

使用する教材はこちらです。

Ultimate AWS Certified Developer Associate 2020 - NEW!

www.udemy.com

 

ちなみに全部英語なのでDeepLは欠かせまん。

www.deepl.com

 

セクション1&2

セクション 1は講座の概要と請求アラートの設定方法のレクチャーです。

セクション 2は講座で使用するスライドやコードなどの資料のダウンロードページへの案内です。

特にこのスライド一覧がとても便利で、そのセクションの動画が始まる前にさっと全文コピペしてDeepLに突っ込むだけで英語字幕onlyでも簡単に追えるようになります。

セクション 3

IAMとEC2の章になります。

  • AWS Regions and AZs
  • IAM
  • EC2
  • EC2 Instance Connect(ブラウザからssh接続する)
  • セキュリティグループ
  • Elastic IP
  • EC2 User Data
  • EC2 instances Launch Types
  • Elastic Network Interfaces(ENI)
  • EC2 Pricing
  • AMI
  • Burstable Instances(T2)
  • T2 Unlimited 

知らなかったこと

EC2 Instance Connect

AWSコンソールの画面からブラウザでEC2内のCLIにアクセスできる。

ただしポート22でインバウンドのSSHトラフィック(0.0.0.0/0)を許可していないとタイムアウトになる。

docs.aws.amazon.com

Elastic Network Interfaces(ENI)

NICの役割を果たし、インスタンスに自由にアタッチ/デタッチできる。

インスタンスにはデフォルトでプライマリネットワークインターフェイス(eth0)がアタッチされており、これをデタッチすることはできない。

用途としては管理用のネットワークを作成したり、ネットワークインターフェース自体の助長化があげられる。

docs.aws.amazon.com

T2 Unlimited

T2 Unlimitedができる前まではT2インスタンスは予期せぬ負荷がかかると一気に性能がベースラインまで落ち込む問題があった。

これを解決するために通常消費されるCPUCreditBalance以外に実質的に一日分のCPUSurplusCredisBalanceが前借りして利用できるようになった。

さらにそれを超過する負荷が発生した場合には追加料金を払うことでバーストを継続できるようになった。

dev.classmethod.jp

 

最後に

英語も割と簡単で読みやすく、DeepLのパワーもあり特に苦もなく学習することができました。

また個人的には講師の方のしゃべりが上手で聞いていてストレスを感じないのも非常に良いです。

この調子で継続して学習していこうと思います。

AWS ソリューションアーキテクト勉強メモ 第3章

引き続き前回の続きから初めていきます。

今回はCloudFrontやRoute53の話になります。

第3章 ネットワーキングとコンテンツ配信

CloudFront

CloudFrontはHTMLやCSS、画像などの静的コンテンツをキャッシュしオリジンサーバーの代わりに配信するCDN(Contents Delivery Network)サービスです。

利点

  • AWSには世界中に120を超えるエッジロケーションが存在し、CloudFrontを使用することで利用者から最も近いエッジロケーションからコンテンツを高速に配信することができる。
  • CloudFrontを使用することにより画像や動画などのファイルサイズが大きなコンテンツへアクセスする場合でも、オリジンサーバが処理する場合よりサーバの負荷下げながら安定したサービス提供をすることができる。
1. CloudFrontのバックエンド
  • CloudFrontはCDNのため、元となるコンテンツを保持するためのバックエンドサーバ(オリジンサーバ)が必要になる。
  • オリジンサーバにはELB、EC2、S3の静的ホスティングを利用することができる。
  • またオンプレミスのサーバを指定することも可能なため、現在のシステム構成を変更することなく一時的なアクセス増加に対応することも可能。
  • URLのパスに応じて異なるオリジンサーバを指定することで、一つのドメインで複数のサービスを提供できるため、ドメイン名の統一など企業のWebガバナンス戦略にも役立つ。

f:id:ddd-endow:20200104225727p:plain

2. ディストリビューション

ダウンロードディストリビューション

  • HTTPやHTTPSを使用してHTMLやCSS、画像などのデータを配信する際に使用する。

ストリーミングディストリビューション

  • RTMP(Real Time Messaging Protocol)を使用して動画のストリーミング配信をする際に使用する。
3. キャッシュルール
  • 拡張子やURL毎にキャッシュ期間を指定することができる。
  • 動画サイトのURLパスはキャッシュを無効化することでCloudFrontをネットワーク経路としてだけ利用することも可能。

Route 53

Route 53はドメイン管理機能と権威DNS機能を持つサービスです。

ネットワークトラフィックのルーティングや接続先のシステム状況に応じた接続先の変更などのオプション機能も存在し、うまく使用することで可用性やレスポンスを高めることができます。

1. ドメイン管理
  • 新規ドメインの取得や更新などの手続き、ゾーン情報の設定ができる。
  • ドメインの年間利用料は通常のAWS利用料に含まれるため、別途支払いの手続きは不要。
  • 自動更新機能があるため、ドメインの更新漏れと言ったリスクも回避できる。
2. 権威DNS

DNS

権威DNS

キャッシュDNS

  • 変換情報を保持していないDNS

・ホストゾーンとレコード情報

ホストゾーン

  • レコード情報の管理単位を表す。(通常はドメイン
  • example.com」のレコード情報を管理する場合のホストゾーンは「example.com

レコード情報

  • ドメイン名とIPアドレスを変換するための情報。
  • 「www.example.comIPアドレスは192.168.0.100」といったようなもの。
  • Aレコード、MXレコード、CNAMEレコードといった種類がある。
  • Route 53で特徴的なものはAliasレコード

Aliasレコード

  • レコード情報に登録する値としてCloudFrontやELB、S3などのAWSリソースFQDNを指定できる。
  • CNAMEでも同じようなことができるが、Zone Apexにも登録できる違いがある。

Zone Apex

  • 最上位ドメイン(Route 53の場合はホストゾーン名)のこと。
  • example.com」をS3のWebサイトホスティングサービスにアクセスする独自ドメインとして利用したい場合、Route 53であればAliasレコードを使用することで登録できる。
3. トラフィックルーティング

Route 53にゾーン情報を登録する際に、名前解決の問い合わせに対してどのように応答するかを決める7種類のルーティングポリシーが存在する。

 

シンプルルーティングポリシー

  • 標準的な1対1のルーティング

フェイルオーバールーティングポリシー

  • アクティブ/スタンバイ方式でアクティブ側のシステムへのヘルスチェックが失敗したときに、スタンバイ側のシステムへルーティングするポリシー。
  • 本番システム障害時にSorryサーバのIPアドレスセカンダリレコードとして登録することで、自動的にSorryコンテンツを表示させることができる。

位置情報ルーティングポリシー

  • ユーザの位置情報に基づいてトラフィックをルーティングする際に使用する。
  • 日本からのアクセスは日本語のコンテンツが配置されたWebサーバに接続する、などの制御が行える。

地理的近接性ルーティングポリシー

  • リソースの場所に基づいてトラフィックをルーティングする。
  • 必要に応じてトラフィックをある場所から別の場所のリソースに移動する際に使用する。

レイテンシールーティングポリシー

  • 複数箇所にサーバが分散されて配置されている場合に、遅延が最も少ないサーバにリクエストをルーティングする。

複数値回答ルーティングポリシー

  • 一つのレコードに異なるIPアドレスを複数登録して、ランダムに返却されたIPアドレスに接続する。
  • ヘルスチェックがNGになったIPアドレスは返却されたないため、正常にどうしているサーバに対してのみアクセスを分散させることができる。

加重ルーティングポリシー

  • 指定した比率で複数のリソースにトラフィックをルーティングする際に使用する。
  • 拠点をまたがってリソースの異なるサーバが配置されている場合にリクエスト比率を調整する、といったことができる。
  • ABテストのために新サービスをリリースしたサーバに一定割合のユーザを誘導したい、などもできる。
4. トラフィックフロー

ルーティングポリシーを組み合わせて様々なルーティング環境を構築s流ことができるが、各レコード間の設定が複雑になることがある。

トラフィックフローはそれらの組み合わせをビジュアル的にわかりやすく組み合わせるためのツールを使って定義できる。

5. DNSフェイルオーバー

フォールトトレラントアーキテクチャ

  • システムに異常が発生した場合でも被害を最小限に抑えるための仕組みのこと。
  • 例:
    稼働中のシステムに障害が発生してWebサイトの閲覧ができなくなったとき、一時的に接続先をSorryサーバに切り替えることができる。

最後に

正直CloudFrontなどは今まで「いい感じに接続先を調整するやつ」としか理解してなかったので、とても勉強になりました。

Route 53に関してはドメイン管理やDNSとしての機能しか知らなかったので、トラフィックルーティングがあることすら知りませんでした…

ボリュームとしては少なめでしたが、今まで環境で疑問だったことが次々と解消されてとても楽しい章でした。

 

 

AWS ソリューションアーキテクト勉強メモ 第2章

前回の続きから初めていきましょう。

今回はリージョンやアベイラビリティゾーン、VPCなどのネットワーク基盤の話になります。

第2章 グローバルインフラストラクチャとネットワーク

リージョンとアベイラビリティゾーン

1. リージョンとアベイラビリティゾーン

リージョン

  • AWSがサービスを提供している拠点(国と地域)。
  • リージョン同士はそれぞれ地理的に離れた場所に配置されている。
  • リージョン内には複数のアベイラビリティゾーン(AZ)が含まれる。

アベイラビリティゾーン

  • 一つのAZは複数のデータセンターから構成されている。
  • 複数のAZが集まったものがリージョンとなる。

aws.amazon.com

2. AZの地理的・電源的独立による信頼性の向上

それぞれのAZは地理的・電源的に独立した場所に配置されているため、ある地域に対しての自然災害による局所的な障害に対して他のAZに影響を与えないようになっています。

AZのデータセンターの位置は公開されていませんが、数十km程度離されて配置されているようです。

しかし各AZ間は高速なネットワーク回線で接続されているため、ネットワーク遅延(レイテンシ)は2ミリ秒以下で安定していることが多いです。

また電源の系統を分離することで一箇所の停電によりAZ内の全てのデータセンターが一斉にダウンすることがないように設計されています。

こうして地理的・電源的に独立していることによって、リージョン全体で見たときに障害への耐久性が高くなり信頼性が高いと言えます。

3. マルチAZによる可用性の向上

AZの障害への信頼性は高いですが、単一のAZのみでシステムを構築した場合、単体のデータセンターでシステムを構築した場合と耐障害性はそれほど変わりません。

なので耐障害性と可用性を高めるためにはマルチAZを構築する必要があります。

f:id:ddd-endow:20200102155607p:plain

このようにロードバランサーからAZの異なる2台の仮想サーバに負荷分散することで、片方のAZがダウンした場合でもサービスを維持できる構成にすることにより可用性を高めることができます。

VPC

Amazon Virtual Private Cloud(VPC)はAWSのサービスの中心で、ユーザ毎のプライベートなネットワークをAWS内に作成します。

VPCはインターネットゲートウェイ(IGW)や仮想プライベートゲートウェイ(VGW)を出口としてインターネットやオンプレミスなどと接続することができます。

1. IPアドレス

VPCは自由なIPアドレス(/16~/28の範囲のCIDRブロック)を設定することができます。

この時IPアドレス不足になった場合、後から拡張するのは困難なのでネットワーク空間は可能な限り大きなサイズ(/16)で作成しましょう。

2. サブネット

EC2インスタンスなどを起動するためにVPC内部に作るアドレスレンジのことをサブネットと呼ぶ。

個々のサブネットには一つの仮想ルータがあり、それぞれがルートテーブルとネットワークACLの設定を持っていて、サブネット内のEC2インスタンスデフォルトゲートウェイとなっている。

  • 一つのVPCに作れるサブネットの数は200個(リクエストによって拡張できる)
  • サブネットの最初の4つ及び最後の一つのアドレスは予約されていて使用できない。(24ビットマスクの場合0, 1, 2, 3, 255)
  • 必要以上にサブネットを分割することはアドレスの浪費につながる。(28ビットの場合16個中11個しか利用できない)
  • サービスの中にはIPアドレスの確保が必要なサービスがある(ELBの場合8個)
3. サブネットとAZ

・サブネット作成時のポイント

同一の役割を持ったサブネットを複数のAZに作る。

そうすることによりEC2やRDS作成の際にAZ障害に強い設計にすることができる。

マルチAZ

f:id:ddd-endow:20200102203946p:plain

・パブリックサブネット、プライベートサブネット

上記の二つはサブネットの機能として存在するのではなく、インターネットゲートウェイやルートテーブルなどを利用して、そのような役割を持たせることになります。(詳しくは後々)

4. ルートテーブル
  • 各サブネットに1つずつ設定する。
  • 一つのルートテーブルに対し複数のサブネットで共有は可能。逆は不可。
  • 宛先アドレスとターゲットとなるゲートウェイネクストホップ)を指定する。
  • VPCにはメインルートテーブルが存在し、サブネット作成時に指定しない場合のデフォルトとなる。
5. セキュリティグループとネットワークACL

セキュリティグループ

  • EC2やELBなどインスタンス単位の通信制御に利用する。
  • インスタンスには少なくとも一つのセキュリティグループをアタッチする必要がある。
  • インバウンドとアウトバウンドの両方の制御が可能。
  • 制御項目にはプロトコルTCPUDPなど)、ポート範囲、送受信先のCIDRかセキュリティグループを指定する。
  • ホワイトリスト形式(デフォルトでアクセス拒否。設定された項目のみアクセスを許可する)

ネットワークACL(アクセスコントロールリスト)

  • サブネットごとの通信制御に利用する。
  • セキュリティグループと同じく、インバウンド&アウトバウンド共に制御が可能。
  • 送受信先のCIDRとポートを指定できるが、セキュリティグループでの指定はできない。
  • ブラックリスト形式(デフォルトで全ての通信を許可)

セキュリティグループとネットワークACLの違い

  • 状態(ステート)を保持するかどうか。
  • セキュリティグループはステートフルで、応答トラフィックはルールに関係なく通信が許可されている。
  • ネットワークACLはステートレスで、応答トラフィックであろうと明示的に許可設定しないと通信遮断する。
6. ゲートウェイ

 ゲートウェイVPCの内部と外部との通信をやり取りする出入り口で、インターネットと接続するインターネットゲートウェイ(IGW)とVPNやDirect Connectを経由してオンプレミスネットワーク基盤と接続する仮想プライベートゲートウェイ(VGW)が存在する。

f:id:ddd-endow:20200102215907p:plain

インターネットゲートウェイ

  • VPCに一つだけアタッチすることができる。
  • 論理的には一つしか見えないが、AWSによるマネージドなサービスのため冗長化や障害児の復旧が自動的になされるため、単一障害点になることはない。
  • ルートテーブルでIGWを指定すると、その宛先アドレスとの通信はインターネットに向けられる。(多くの場合デフォルトルート「0.0.0.0/0」を指定することになる)
  • パブリックサブネットの条件の一つはルーティングでIGWを向いていること。
    →逆にプライベートサブネットは直接IGWに向いていないこと。
  • EC2インスタンスがインターネットと通信するためにはパブリックIPを持つか、NATゲートウェイを経由してインターネットと通信する必要がある。
    →NATゲートウェイはネットワークアドレス変換機能を持ち、プライベートIPをNATゲートウェイが持つグローバルIPに変換し、外部と通信を行う。

仮想プライベートゲートウェイ

  • VPCVPNやDirect Connectと接続するためのゲートウェイ
  • VPCに1つだけアタッチすることができ、複数のVPNやDirect Connectと接続することができる。
  • ルートテーブルでVGWを指定すると、その宛先アドレスとの通信はVGWからVPNやDirect Connectを通してオンプレミスネットワーク基盤に向けられる。
  • 宛先についてはルートテーブルに静的に記載する方法と、ルート伝播(プロパゲーション)機能で動的に反映する方法の二種類がある。
 7. VPCエンドポイント
  • VPC内からインターネット上のAWSサービスに接続する方法として、インターネットゲートウェイを利用する方法とVPCエンドポイントを利用する方法の二種類が存在する。
  • VPCエンドポイントにはS3やDynamoDBと接続する際に利用するゲートウェイと、それ以外の大多数のサービスで利用するインターフェイスエンドポイント(AWS PrivateLink)がある。
  • ゲートウェイエンドポイントはルーティングを利用したサービスで、エンドポイントを作成しサブネットと関連付けると、そのサブネットからS3やDynamoDBへの通信はエンドポイントを通じて行われる。

f:id:ddd-endow:20200102221838p:plain

8. ピアリング接続
  • 二つのVPC間でプライベートな接続をするための機能。
  • 同一のAWSアカウントのVPC間だけでなく、アカウントをまたがっての接続も可能。
  • VPCピアリングでの通信相手はVPC内のEC2インスタンスなどで、IGWやVGWなどにトランジット(接続すること)はできない。
  • 相手のVPCがピアリングしている別のVPCに推移的に接続することもできない。
9. VPCフローログ
  • VPC内の通信の解析に利用する。
  • 仮想ネットワークインターフェイスカードであるENI(Elastic Network Interface)単位で記録される。
  • 記録内容は送信元・送信先アドレスとポート、プロトコル番号、データ量と許可/拒否の区別。

最後に

今回はAWSサービスの基盤となるリージョンやAZ、VPCの話でした。

ここら辺は何をするにしても必ず触る箇所なので、割と覚えていました。

ただこうして書いてて気がついたのが、ルートテーブルやセキュリティグループ、ネットワークACLのあたりは若干あやふやな部分があったので、あとでホワイトペーパーなどを見て復習します。

 

 

AWS ソリューションアーキテクト勉強メモ 第1章

はじめに

現在ゆめみでサーバーサイドエンジニアとして働いていますが、業務上AWSに触れることが多く、その度に自分の知識不足を痛感していました。

なのでAWSの勉強も兼ねてソリューションアーキテクト:アソシエイト(以後SAA)の資格を取得することにしました。

 

しかしただ勉強するだけではなかなか続きませんし、何より本当に知識が身についているのか実感が湧きません。

そこでブログをノート代わりにしてアウトプットすることで少しでも学んだことを定着させることにしました。

 (はてなブログを選んだのはnoteやQiitaなら警察が飛んできてなんかいろいろ言われそうだけど、ブログなら何書いたって平気だろとか思ったからです。)

 

というわけで早速初めていきたいと思います。

 

何やるの?

一時期UdemyのSAA対策講座を受けていたのですが、基礎知識がないのにいきなりハンズオンをやったため、あまり効率良く勉強することができませんでした。

なので今回はいわゆる試験対策本を一から進めていきます。

 

  

第1章

学習教材 

1. 公式ドキュメント

AWSの仕様の一次情報は公式ドキュメント

しかし日本語化されるまで時間がかかるので、可能な限り英語版を確認すること。

 2. オンラインセミナー(AWS Black Belt)

サービス/機能ごとにスライドを利用してオンラインで解説するセミナー。

新しいサービスを学ぶ際はBlack Beltの資料で概要を理解し、その上で公式ドキュメントを見て詳細を確認するのが効果的。

AWS クラウドサービス活用資料集 

AWS トレーニングの概要 

3. ホワイトペーパー

AWSアーキテクチャの考え方とベストプラクティスを解説している。

特にAWS Well-Architected フレームワークは必読!

AWS ホワイトペーパー

AWS Well-Architectedフレームワーク

クラウドコンピューティングのための アーキテクチャ・ベストプラクティス

4. 講座

公式トレーニングが充実している。

が、料金と時間の関係で今回は独学でやることを目標にする。

AWS 公式トレーニング

5. ハンズオン

AWSチュートリアルが充実しており、それをやるのがおすすめ。(基礎的な範囲ならUdemyの講座でも可)

10分間チュートリアル

セルフスペースラボ

何に重きをおいて学習すべきか

まずは様々なシーン・アーキテクチャで登場するサービス(コアサービス)を理解することで設計の幅が広がり、それ以外のサービスを学ぶのも効率的になる。

 重点学習ポイント

各サービスの特徴だけを理解するのではなく、求められるアーキテクト像からそれらをどのように使用するかを考える必要がある。

  • 可用性の高い設計ができること
  • スケーラビリティとパフォーマンスを意識した設計ができること
  • コスト効率を意識した設計ができること
  • セキュリティを担保した設計ができること

最後に

第1章ということもありほぼほぼ導入やどのように学習するかの説明が中心でした。

次回から学習が本格的に始まるので、このメモ帳もちゃんとした内容になる…と思います。