はじめに
AWS初挑戦の記録です。
ほんの一握りの知識ですがまとめました。
インフラの学習はコードを書くわけでもなく、目に見えた変化も感じにくいので大変ですね。。。
この記事を見て、一人でも参考になる方がいれば幸いです。
専門用語
■ローンチ
新しい商品やサービスの提供を(開始)すること
■オーバーヘッド
コンピュータが何か処理を行った時に発生する付加的な処理(負荷になる)
(実行したい処理に関わることだけど必要ない処理)
■ファイアウォール
不正な通信がネットワークに侵入することを遮断し、保護するセキュリティ対策機能
■ストレージ
データをしまっておく箱
電気が流れていなくてもデータを保存しておくことができるがCPUとやりとりはできない
(CPUとやりとりするのはメモリの役割)
■I/O
input/outputの略。日本語訳「入出力」
情報を入力し(input)、結果を出力する(output)という処理の総称
■メタデータ
主となるデータの付帯情報が書いてあるデータ(補足、説明書き)
■しきい値
条件分岐の境目となる値
■レイテンシ(latency)
データ転送における指標の一つ
データ転送の要求を出してから結果が帰ってくるまでにかかる時間
レイテンシが低い = 処理速度が早い
■スループット
一定期間にどれほどの処理を行うことができるかを表す指標
■ホスティングサービス
自分らが設置したサーバーをネットワーク越しに他者へ使わせてあげること(レンタルサーバー)
■API
外部のプログラムからその機能を使わせてあげるための窓口に関する使い方などの決まりごと
■トラッキング
訪問者の行動などを記録して分析すること
■オンプレミス
クラウドを使わず、コンピュータやシステムを自ら設置して自ら運用する方法(自社運用)
■DNS
インターネット上でドメイン名を管理・運用するために開発されたシステム
■ポート
ネットワークとPCの間にあるドアのこと(たくさんある)
通信においてデータの送受信を行う際、データの種類によって使うドアが決まっている
そのドアには各々番号が割り振られており、その番号を「ポート番号」という
VPCについて
リージョン上に構築する仮想ネットワーク
サーバーなどをAWSで使うために必要な仮想ネットワークを構築するサービス
仮想ネットワークを構築するには、
そのネットワークが持つIPアドレスの範囲を定義しなければならない
↓
IPアドレスの範囲を定義する方法として「CIDR」というものがある
CIDR(サイダー)とは
ネットワークを構成する際に必要なIPアドレスの範囲を決める方法
IPアドレスの範囲は世界共通ルール(下記参照)
サブネットとは
VPCのIPアドレスの範囲内で、さらに小さな仮想ネットワークを作成するAWSのサービス
耐障害性を考慮して、異なるアベイラビリティーゾーンにネットワークを作成できる
(＝１つのリージョン内の異なるアベイラビリティーゾーンにネットワークを分散できる)
このサブネットは公開・非公開が設定できる
＝個人情報などを扱うデータベースは非公開、Webサーバーは公開のように設定可能
※公開＝public , 非公開＝private
サブネットもVPC同様、IPアドレスの範囲を設定しなければならない
サブネットのIPアドレスの範囲はVPCで決めた範囲内でしか指定できない
サブネットは複数作成可能だが、IPアドレスの範囲は重複して作成できない
プライベートサブネット：インターネットに接続できないサブネット
パブリックサブネット：インターネットに接続できるサブネット
ルートテーブルとは
インターネットからVPCに接続した時、どこに通信しにいくのか(どのサブネットにいくのか)をルール決めをしたもの
サブネットの公開の設定を行う
→ルートテーブルは作成時デフォルトで非公開(private)になっている。
１：ルートテーブルにインターネットゲートウェイを設定すると公開(public)になる
２：そのルートテーブルにサブネットを関連付けることで、サブネットも公開(public)になる
インターネットゲートウェイとは
AWSリソース(EC2インスタンスなど)とインターネット間を通信できるようにするもの(窓口)
主な役割
１：ルートテーブルにインターネットへのルートを追加する
２：EC2インスタンスのプライベートIPアドレスをパブリックIPアドレスに変換する
IPアドレスについて
IPアドレスはネットワークに接続された機器がもっている番号
＝インターネット上の住所
IPアドレスは「ICANN」という組織が管理をしている
IPアドレスの種類
１：パブリックIPアドレス(グローバルIPアドレスともいう)
２：プライベートIPアドレス
パブリックIPアドレス
→インターネットに接続される機器にそれぞれ個別に割り振られる番号。番号は一意
プライベートIPアドレス
→インターネットに直接接続されていないネットワーク機器で利用されるIPアドレス
一意である必要はない
プライベートIPアドレスは範囲が限定的
- 10.0.0.0 ～ 10.255.255.255
- 172.16.0.0 ～ 172.31.255.255
- 192.168.0.0 ～ 192.168.255.255
EC2について
EC2とは
AWSのクラウドにて、仮想化基盤上にサーバーを実行するサービス(EC2 = サーバー)
仮想化とは
単一の物理サーバー上で、複数の仮想サーバーを実行すること
この、仮想化基盤上にある(作った)サーバーをEC2インスタンスorインスタンスと呼ぶ
EC2インスタンス
これはあくまで仮想サーバーであるため、実際の処理はAWSデータセンター内にある物理サーバー上で実行される
AWSデータセンターは指定したAZ内(アベイラビリティーゾーン)に存在する
ENI
EC2インスタンスに付与される仮想ネットワークインターフェース
インスタンスのへ通信はすべてENIを経由して行われる
セキュリティグループ
EC2インスタンスにアクセスできる通信を制限する
(許可する通信を指定し、それ以外の通信を全て遮断する)
(不正な通信がネットワークに侵入することを遮断し、保護するセキュリティ対策機能)
インスタンスにアタッチされているENIに関連付けられ、最大5つまで関連付けが可能
インバウンドトラフィック(インスタンスに入ってくる通信)＝インバウンドルール
と
アウトバウンドトラフィック(インスタンスから出ていく通信)＝アウトバウンドルール
を
別々に設定できる
ネットワークACL
サブネットに属する全てのインスタンスに対して適用されるファイアウォール
(セキュリティーグループはインスタンスごとに設定するがこっちはサブネットごとに適用できる)
→大枠はネットワークACLで設定し、細かいところをセキュリティグループで設定するといった使い方をする
ライフサイクル
EC2インスタンスを起動してから終了するまでの状態遷移のことを意味する
Amazon EBSについて
Amazon EBSとは
EC2インスタンスで最もよく使われるストレージ
※AWSでは、CPUやメモリをもつEC2インスタンスと、HDD(ハードディスクドライブ)としてのストレージに分かれている
CloudWatchについて
CloudWatchとは
サービス(EC2インスタンスなど)の状態を監視するシステム
利用者がサービスを使える状態であるかや、利用者の増加によってシステムに負荷が増えていないかなどを監視できる
３つの機能がある
１：モニタリング(監視)
２：可視化(監視結果をグラフで表示)
３：通知機能(設定した条件に合う時、メールで通知を送る)
自動化ツールについて
AWSで利用できる自動化ツールは様々だが、一部抜粋(3つ)
１：UserData
２：InstanceMetadata
３：Launch Template
１：UserData
EC2を起動した後(作成した後)に行う処理を自動化できる
(例：ngnixをインストールする、Rubyをインストールするなど)
EC2起動時、インスタンスの詳細設定の一番下、高度な詳細の中にユーザーデータというフォームがある。
そのフォームにインストールなどで実行するコマンドを記載すると、インスタンス作成後にそのコマンドを実行してくれる
２：InstanceMetadata
実行中のEC2インスタンスに関する情報を取得することができる
EC2インスタンスにSSH接続後、コマンド入力
ec2-metadata --help
→コマンドのオプション一覧が出力される
そのオプションを参照し、ec2-metadata オプションとコマンド入力することで情報取得が可能になる
３：Launch Template
EC2インスタンスを起動(作成)するための設定をテンプレートとして保存できるサービス
EC2サイドバーの「 テンプレートの起動」から設定が可能
※起動テンプレートは設定に不具合があってもインスタンスを作成してしまう
→インスタンス起動時にエラーが表示される。
踏み台サーバーとバッチサーバー
踏み台サーバー(Bastion)とは
インターネットに直接接続されていないサーバーにアクセスするためのサーバー
(privateサブネット内のサーバーにアクセスするためのpublicサブネット内のサーバー)
バッチサーバーとは
あるタイミングでまとめて処理を実行することを目的としたサーバー
バッチサーバーへアクセスするには
踏み台サーバーにssh接続後、そこからバッチサーバーにssh接続する(＝鍵が２つ必要)
秘密鍵の送り方
踏み台サーバーにssh接続した状態で、バッチサーバーの秘密鍵をドラック＆ドロップしても使えない
↓
下記手順で対応する
１：ローカル環境時に踏み台サーバー用と、バッチーサーバー用の２つの鍵を置く(ドラック＆ドロップ)
２：ローカル環境から踏み台サーバーへ、バッチサーバー用の鍵を送る(scpコマンド)
コマンド形式
scp -i 踏み台サーバー用秘密鍵へのpath バッチサーバー用秘密鍵のpath ユーザー名@踏み台サーバーのpublicIPアドレス：鍵保存場所のpath
イメージ例
scp -i A B C：D
CにAを使って接続し、DにBを保存する
AWS責任共有モデル
AWS責任共有モデルとは
AWS側と利用者側で役割分担を行い、全体のセキュリティを担保しようという考え方
IAM
AWSにログインできるユーザー追加し、
そのユーザーのアクセス権限を管理できるサービス
イメージ
ユーザー名「○○」でログインしていいよ！(IAMユーザーの作成・追加)
でも、EC2インスタンス見ることしかできないからね！(アクセス権限の設定)
MFA
AWSを２段階認証できるサービス
CloudTrail
ユーザーやAWSサービスが実行したアクションを「イベント」として記録するサービス
90日感保存でき、活動を可視化することにより、不正利用などを監査することができる
90日より多く保存したい場合は有料(「証跡」を作成してS3に保存)
Amazon S3
Amazon Simple Strage Serviceの略
クラウド上にデータやファイルを保存できるサービス
Amazon S3の特徴
１：容量無制限
保存できるデータ容量とオブジェクト数は無制限。※オブジェクトサイズは最大5TBまで
２：高度な耐久性
３：拡張性のある複数のストレージクラス
どんなときに使うのがおすすめか
大規模なデータ配信を行うアプリケーションやサービス
↓
他のストレージとファイルを転送する際の性能は差がないが、同時に複数ファイルを転送する際に他のストレージより性能が落ちにくいため
S3に保存するデータは最低３つのアベイラビリティゾーンに自動的に保存される。
→高度な耐久性を維持することができる。
そのため、データの更新や削除は反映に時間がかかってしまう。
(＝あるユーザーの更新内容を別のユーザーがすぐに反映しなければならないアプリには不向き)
Application Load Balancer(ALB)
ディザスタリカバリ(Disaster Recovery)(DR)とは
自然災害やサイバー攻撃などでデータセンターやシステムの稼働に門外が発生した場合、
損害の軽減や機能の維持、回復や復旧のための対策を講じること
DR環境 ＝ メインのデータセンターとは離れた場所にある別のデータセンターにコピー環境を構築しておく
Application Load Balancerとは
アプリケーションへの(サーバーへの)アクセスを分散させるサービス
アプリケーションへの(サーバーへの)アクセスを分散させることで、アクセス集中による負荷を軽減し、処理速度の工場や、高い可用性の維持を行うことができる
※ロードバランサーは使用した分のみ料金が発生する
(アクセスがない場合でも固定時間料金がかかるため、1ヶ月で18ドルは最低でもランニングコストがかかる)
スティッキーセッションとは
サーバーが複数ある場合、初回リクエストで保存したSessionIDで持った状態で別のWebサーバーにアクセスしてしまう可能性がある。(別のWebサーバーから見れば初回リクエストである為、Sessionを維持することができない)
この問題を解消するために
「セッションが有効ない間は同じサーバーにリクエストする」という設定を行う必要がある。
その設定が「スティッキーセッション」である
CookieとSession
(前提)
HTTP通信はステートレス
ステートレス：状態を保持することができない(例：ログイン状態をページ遷移時に保持できない)
Cookieとは
Webサーバーが発効し、ブラウザで保持されるテキストデータのこと
このCookieをクライアント側(ユーザー側)で保存することにより、
次回訪問時に、状態を保持した状態で表示することができる
Cookieの処理順序
初回訪問時
１：ブラウザにアクセスした時、WebサーバーからCookieが発行される
２：ブラウザ(クライアント)がCookieを保存する
次回訪問時
３：ブラウザでアクセスするときにCookieも一緒に持っていく
４：WebサーバーはCookieを参照し、初回訪問時の状態を踏まえてレスポンスを返す
Sessionとは
Webサーバーで保持されるクライアントWebサーバーの通信状態を表すデータ
・ポイント
Cookieはクライアント側で保持
Sessionはサーバー側で保持
Sessionの処理順序
初回訪問時
１：ブラウザにアクセスしたクライアントの「Email」と「Password」を元に「SessionID」を発行する
２：SessionIDをCookieに渡す(Webサーバー側でもSessionIDを管理)
次回訪問時
３：Cookie内のSessionIDをWebサーバー上で保持しているSessionIDと照らし合わせる
４：整合性が取れたら、初回訪問時の状態を踏まえてページを表示する
※なぜSessionが必要なのか
Cookieのみの場合、Cookieはクライアント側管理であるため、改竄が可能であり不正アクセスなどの恐れがある。
SessionはWebサーバー上で保持しているSessionIDとの整合性を確かめる為、改竄ができない。
・おまけ
Cookieは検証ツールのApplication→Storge→Cookieから確認することができる