【AWS】仮想ネットワークを作る

いよいよ仮想サーバ（EC2）を構築したいところですが、その前にやらなければならないのがVPC（Virtual Private Cloud）です。

これは仮想環境の中のネットワーク空間です。会社の中のLAN環境を思い浮かべるとまぁまぁあたってるかもしれません。

作成は結構手間なんですが、こんなものを作っていきます。

①VPCの名前とCIDR。
VPC内で使用できるアドレスを決めます。例えば 10.0.0.0/16 ですね。最後の/16というのは、IPアドレスを2進数であらわした時に左から16桁目までがアドレス固定、そこから右が自由に使えることを意味します。なので数字が低ければ低いほど多くのアドレスを割り振れます。

②サブネットグループ
これはVPC内をさらにエリア分割するために作ります。具体的には所属するVPCと、このサブネットが使えるCIDR、それにAZ（アベイラビリティゾーン）です。CIDRに割り振れるのは当然①で決定した範囲の中に限られます。例えばVPCで10.0.0.0/16としたら、サブネットは10.0.1.0/24 などです。
VPCの中でプライベートな空間とパブリックな空間を分けて作成するのは基本的なデザインパターンです。

③ルートテーブル
これはルーティングテーブルといった方がわかりやすい？かどうか知りませんが、所属する①と、このルートテーブルに関連付ける②を（場合によっては複数）選択します。例えば２つのAZにそれぞれパブリックなサブネットを作り、これらを同じルートテーブルに所属させます。

④インターネットゲートウェイ
③をこれに紐づけ、③の送信先をデフォルトゲートウェイ(0.0.0.0/0)に設定することにより③にひもづいた②の中のEC2はインターネットにアクセスできるようになります。

まぁややこしいかもしれないですが、機械的にこれらをやってようやく中のEC2を外にだせるようになります。

ちなみに④に紐づけないと外にでれませんが、③の設定でピア設定というのがあり、外にださない２つのサブネットを結びつけることで、インターネットにでることなく２つのサブネットが直接通信させることができます。

【AWS】アカウント管理の話

さて、今これを書いている現在、実はAWSで仮想マシン（EC2）を実際に構築して勉強してるわけなんですが、想像以上にややこしくて結構まいっています。

まぁ愚痴はさておいて、今回は基本でもあり超重要なファクターでもあるアカウントについて書きます。

◆思い出しながら取得の流れを書いてみる

AWSを利用する際の手順は以下の順番です。

①AWSのサイトで登録する。
　
　登録に必要な情報は

　・メールアドレス（これがユーザIDのかわりになる）
　・支払い情報（ようするにクレカです）
　・あと何か色々

②AWSから登録した電話番号に電話がかかってきます。自動音声案内なんですが、要するに本人確認みたいなものだと思います。

③残りの手続きを何かやって完了。登録したメアドにメールが飛んできます。

ここまでやったら早速サインインします。


ここで重要なお話になりますが、AWSで実際にクラウド環境の構築作業をするのは、この登録したアカウントでも可能ではあるんですが、基本的にはこのアカウントはAWSに直接やりとりしたいことがない限りは使いません。

そこでIdentity & Access Management （以下、IAM)からユーザアカウントを作ります。なんかAMIとスペルが似てるのでややこしいですね。


IAMとは一般的なPCのユーザと同義と考えて間違いないです。

で、アクセス権限なんですが、これはIAMユーザごとに設定するわけではなく、IAMポリシーという各種権限のセットから選んで紐づけます。

ポリシーは自作もできますが、すでに用意されているものからも選ぶことができます。

ただしすでに用意されているものはものすごい数があり、どれを選んでいいかわからないので、とりあえず色々やってみたいならAdministratorAccessというポリシーを選択しておけば間違いないです。

自作する場合ですが、JSON方式という聞きなれない記述方法で書かなければなりません。

ちなみに上にあげたAdministratorAccessのポリシーはJSON方式で

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}

となっています。フォントの色を変えたのは特に意味ないです。


ちなみにIAMユーザに直接ポリシーを紐づける方法とは別に、IAMグループを作成し、このIAMグループにポリシーを紐づけ、IAMユーザはIAMグループに所属させる形でポリシーを紐づけるやり方もあります。多数のユーザを管理するならこちらの方がやりやすいでしょう（たぶん）。


例えば管理者用のポリシーを紐づけたIAMグループを作ります。で、実際に権限を与えたいユーザが3人いるなら、その3人のIAMユーザを全部、このIAMグループに所属させます。なんかうまい説明したつもりなんですが上に説明したことと同じですね。

で、IAMユーザには当然パスワードも設定します。パスワードのルールも色々カスタマイズできるのですが、まぁセキュリティにうるさい企業なら、たいていは初回ログイン時にIAMユーザ自身にパスワードを変更させるオプションを選ぶんじゃないでしょうか。


さて、IAMユーザにはAWSコンソールアクセス用のURLが発行されます。


IAMユーザはそのURLからAWSにアクセスし、いろんな作業をやります。もちろん権限を与えられていない操作はできません。
ちなみにURLは https://"アカウントID".signin.aws.amazon.com/console となります。このアカウントIDはユニーク（一意）な数字です。ぶっちゃけIAMユーザはユーザ名、パスワードだけでなく、このアカウントIDも知っていないと使えないわけですな。

【AWS】前回書き忘れてた

前回、EC2とAMIについて触れようとしてたらAMIのこと何も書いてなかったですね。。。

◆AMIとスナップショットがバックアップに必須

AMIはAmazon Machine Emageの略です。

これはEC2インスタンスを作成するのに必要なOSの構成情報（OSの種類・バージョン、32bit or 64bit、使うボリュームの種類など）です。

いうなればOSの独自テンプレートみたいなもの（とミナミは思い込んでる）です。

なので後で触れるAuto Scaling(自動でインスタンスを増やす機能）も、AMIをもとにインスタンスを作成しています。

さて、もうひとつ忘れちゃいけないのがスナップショット。

名前だけでピンとくる人もいると思いますが、これは起動中のOSの中身というべきEBSボリュームのバックアップです。

AZやリージョンを超えて別にEC2インスタンスを起動させたい場合、このスナップショットとAMIを使うと簡単にできます。


ただ、スナップショットがOS（のボリューム）のバックアップだとすると、スナップショットを取得（＝保存）て時間かかるんじゃないの？それまでOSはどうなるの？停止？

という疑問がでると思いますが、優秀なことにスナップショットを取得中もOSは稼働させ続けることができます（さすがにパフォーマンスの影響は皆無じゃないと思いますが）

また、パッチ世代によってスナップショットも世代別に管理したい場合、

例えばAというパッチをあてた状態でスナップショットを取得し、そのあとBというパッチをあててスナップショットを取得すると、2回目のスナップショットは増分（つまりBの分）だけがスナップショットとして保管されます。

が、この後1回目のスナップショットを消してもちゃんと2回目に1回目の分もマージされます。


お金の話をするとAMIは無料です。スナップショットは1GBあたりいくらで従量課金されます。つまり保存し続けると毎月お金はかかります。



◆優秀っぽく見えるS3

さて、続いてストレージの話にうつります。

AWSを代表するストレージがAmazon Simple Storage Service(以下S3）です。

　　・・・わざわざ頭文字をSで統一しようとしたのか、たまたまそうなったのか誰もが疑問に思うのでは

名前はさておき、このストレージの代表的な売り文句は

・容量無制限（ただし保存サイズで課金額は増えていく）

・１ファイルあたりのサイズは5TB

・保存すると勝手に他のAZのストレージへコピーし、冗長化も心配ない

・暗号化もオプションで選択するだけ

あたりでしょうか。実は従来のストレージではこれらは結構コストのかかる話だったので（もちろんS3もお金はかかるが）、自前でストレージを購入せずにこれらが実現できるのは非常に楽ちんじゃないかと思いました。

デメリットも一応あります。それが結果整合性というポリシー。

これは「格納されたデータは時間はかかるがそのうち同期される」ということ。

例えば誰かが格納したデータに対して、別の誰かが参照しようとしても、必ずしも最新とは限らない、でも時間がたてば最新になってる、という曖昧なもの。

実はS3に格納したデータはブラウザからURLで直接アクセスできます。が、アクセスして得たものが必ずしも最新の状態のものではない、というトレードオフがあります。

ちなみに使い方は、まずS3の中にバケットというものを作ります。これはフォルダだと思えばOK。そこに格納されたファイルはオブジェクトと呼びます。

また、アクセス権限はバケット単位（これをバケットポリシーという）、オブジェクト単位（ACLという）などで設定できます。


そして、最初に書いたスナップショットはS3に保存されます。ただしスナップショットは他のオブジェクトと違ってURLからアクセスしてDLはできないです（たぶん）。


S3に格納したオブジェクトはバージョン管理もされており、勝手にバージョン別の差分を作ってくれます。


それに対して、というわけではないですが、利用料金がS3の3分の1のストレージがあります。それがGlacierです。Glacierは氷河という意味です。

これは安い代わりにアップロード、ダウンロードでそれぞれ課金されます。またダウンロードの速度も遅いです。なので滅多にアクセスしないアーカイブデータの保存に向いています。

【AWS】仮想サーバの基本を知る

◆EC2とAMIについて◆

クラウドのメインの使い道は仮想サーバでしょう（たぶん）

なので仮想サーバに関連する用語をまずは覚える。

その仮想サーバを”Amazon Elastic Compute Cloud”、通称EC2といいます。

・・・このネーミングなんでしょう。素直にVirtualとかServerとかいう単語を使ってくれないところになんかこじらせた感じがしてしまうのはミナミがひねくれているからでしょうか？

しかもややこしいことに、実際に起動させたサーバはインスタンスと呼びます。EC2インスタンスという言い方をする場合もあります。

このインスタンスは物理で例えるならサーバ本体を想像するとわかりやすいかもしれません。物理サーバであるならばCPU性能などハードスペックが気になるところですが、インスタンスにもスペック別の種類があり、詳細は下記参照で。

https://aws.amazon.com/jp/ec2/instance-types/

高スペックになるほど当然課金料金も高くなります。無料もあります。

インスタンスについてもう１つ。

AWSのインスタンスは必要な時に必要なだけ即使えるのが魅力ではありますが、用途別に以下の4タイプがあり、これらを組み合わせることでコストをおさえられます。

　・オンデマンド…一般的なインスタンス。使った分だけ課金されます。
　・スポット…入札価格で料金はかわるものの、払った分だけ使えるタイプ。オンデマンドに比べて安価です。
　・リザーブド…長期間の使用向け。予約することで料金をおさえられます。数年間使いっぱなしになる場合など。

さて、サーバといえば当然OSが乗ってるわけで、それはRedHat LinuxやWindowsなどいろいろありますが、Linux系が多いです。OSによっては無料だったり有料だったりします。

もちろんこれだけでインスタンスが成立するわけじゃありません。

ルートボリューム（WindowsでいうCドライブ）を格納するディスクは基本的にElastic Block Store(通称EBS)といいますが、これもタイプがあります。

　・汎用…特別な要件がない限りはこれを選択。ストレージの書き込みに対し課金がないです。
　・プロビジョンドIOPS…IOPSとは1秒間あたりのディスク書き込み速度（だったかな？）。超頻繁なディスクアクセスに対応したい場合これ。
　・マグネティック…磁気ディスク的な何か。割安なのでちょっとだけ使いたいときなど。ただし読み書きに課金があります。

EBSの使用料は従量課金制で、1GBあたりいくらで計算されます。

まだまだ全然序の口なんですが疲れたので続きは後日。

【AWS】AWSの勉強はじめました

突然ですがAmazon Web Services(以下AWS)の勉強をはじめました。

勉強したことを備忘録兼ねて書いていきます。

というより勉強してでてくる愚痴を書きまくりそうな予感。

何もわからないのでトンチンカンなことをかきまくるでしょう、、、


◆クラウドくらいはさすがに知ってる◆

”クラウド”という言葉がテレビのCMなどで当たり前に使われるようになって結構経った気がしますがどうでしょう。

ミナミは初めてその言葉を聞いたのは、会社の元後輩と７，８年前に会話した時でした。

後輩と川崎の焼き肉屋で食事してたとき、後輩が再就職先でクラウド関連の仕事をしてる、と聞いて「なにそれ？」と反応していました。

で、その後ネットでかじった知識で多少はわかった気がします。


その後、ここ1，2年くらい、自分の会社内の仕事にIaaSとかSaaSとかいう単語をよくみかけるようになったので、これもネットでかじりました。

クラウドとは要は、なんて語りだすとまた無知をさらすだけなので絶対書きませんが、ハードウェアやソフトウェアを自前で調達しなくてもどうにかしてくれるシステム（サービス）みたいですね。みたいですね、ってまだわかってないのかよ


AWSはそのクラウドをAmazonが提供しているサービスの名前で、必要なハード（ディスクやネット回線）やOS、ソフトウェアまわりを必要な分だけ即使えるのが大きな長所でしょうか、、、

これって企業にとっては大きな魅力なんですよね。よくAWSなどのクラウドのメリットで説明されるんですが、普通は企業がサーバや社員たちが使うPCを用意する場合、発注から届くまで時間かかるし、必要なソフトウェアをDVDなどのメディアやEXEファイルを配布して1台づつインストールしなきゃいけなかったり、ウィルス対策などのセキュリティにも1台ずつ目を光らせないといけないし（ちょっと前にランサムウェアで大騒ぎになったばかりだし）、ネットワーク速度で最低限欲しいパフォーマンスが得られなかったらその原因究明を一生懸命ベンダに調査させないといけなかったり、壊れたら部品交換したりしなかったり、、、もういろんなめんどくさいことがおきます。

それらのめんどくささから解放されるのが最大のメリット。

ただしなが～い期間で見るなら自前で用意した方が少なくとも金銭面では安上がりではありますが。

で、AWSの話に戻って、これは使った分だけ当然お金を払うのですが、その課金体系は結構めんどくさそう。とはいえ個人でちょっと遊びで構築するならともかく、企業が利用するならここは最重要な箇所なのでいずれ取り組んでみます。

あ、ちなみに使った分だけと書いたけど、必要なリソースを事前に予約することで安くすることもできます。

例えば1年365日ずっと稼働しっぱなしのシステムなら、時間課金よりは、年間契約的な契約の方が安上がり。

でも平日9時～17時しか使わないのなら年間契約より時間課金の方が安価、と結構頭使います。そりゃそうだ



◆用語を覚える◆

もうこんな時間なので、ちょっとだけ。

絶対最初に覚えないといけない単語を２つ


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

リージョンって聞いて何を思い浮かべますかね？　私はバージョンの親戚みたいな印象があるんですが、まったく関係ないｗ

AWSはリソースを貸し出すサービスと言い換えられるかもしれませんが、当然物理的なマシンがどっかにデータセンタとして存在してるわけです。

具体的な場所は非公開になってますが、世界中にデータセンタ群ともいうべきものがあるそうです。このデータセンタ群をリージョンと呼称しています。

なんでもっとイメージしやすい名称にしてくれなかったんだろうと個人的には思うわけです。


で、東京もその１つ。東京というやや広い？エリアがAWSのリージョンの１つなわけです。


なので東京に複数のデータセンタがあるそうなんですが、ひとつ一つのデータセンタをアベイラビリティゾーン（以下AZ)と呼称します。


そのうち書くと思うんですが、基本的には複数のAZに同じサーバをたてて、冗長化（1つぶっ壊れても代替機があるから大丈夫な状態）な状態にしておくのがまぁ企業が持つ重要なサーバの基本なわけです。

災害に備えて複数個所にサーバをたてるのは大企業なら珍しい話ではないと思いますが、これって管理が面倒なんですよね。ふつうはマシンがぶっ壊れたら現地にいって修理しなきゃいけない。調査するためのログも遠隔操作で取得できるように設計されてるならいいけど、そうじゃないとログとったり何か操作するためにいくケースもあったりします。

AWSのAZは場所が非公開で、もし現地で必要な作業があればAmazon側が全部やる、というより現地に行かないとできないハードの交換・メンテなどハードに依存した作業はすべてAmazon側の責任とい明確になってます。ネットワーク機器へパッチあてたりとかハードのファームウェア更新とかもそうです。

逆に利用者側の責任は遠隔でできること（まぁざっくりソフトウェアレベルの話）全部といってもいいかも。例えばOSやアプリのセキュリティ対策などです。


ちなみにサーバをたてる時、リージョン、AZを選択します。東京で選べるAZは今現在2か所です。他のリージョンでもだいたい２，３箇所らしいです。