AWS VPCについて（初心者向け）

私はcloudpackというクラウドインテグレータをサービスしている会社で働いています。
その中でMSP（運用）を行うセクションを管理してたりします。

MSPではこれからクラウドをやりたいです！というメンバーから、どんな依頼（相談）も障害も
ささっと解決してしまう熟練メンバーもいたりと幅広いです。
お客様もシステム（インフラ）に関して熟知されている方、cloudpackにお任せします！
という方とさまざまです。

という事で、MSP管理者である私はちょっとわかりにくい（と感じている）ものを簡単に思える
ようにしていかなければと考えました！

今回はAmazon VPC（Amazon Virtual Private Cloud）について軽く説明してみます。


■そもそもVPCって何？
VPCは簡単にいいますと、AWS上に作るプライベートなネットワーク環境です。
一般のネットワーク環境を作る場合と同じで、下記を元に構築します。

一応ざっくりとネットワークを設計する上で必要なものを説明しておきます。
・ネットワークレンジ
→そのネットワーク環境でどのくらいノード数があるかを踏まえて、どれくらいの大きさが
必要かを考えます。
・サブネット
→ノードの役割によってインターネットに出ても良い、お互いに通信させても良いか悪いかなど
のルールを元にグループ分けするものです。また物理的な場所が分かれている場合なども
考慮しておくと良いです。そのルールの数分作成します。

ネットワークをがっつりやっている方が見たら怒られそうなくらい、ざっくりした説明ですね。

VPCについて詳しくは下記を参照して下さい。
http://aws.amazon.com/jp/vpc/


■ネットワーク良くわからないのだけど
はい。ご安心下さい。現在のAWSではVPCは必須ですが、実は勝手に用意してくれます。
正式名かわかりませんがDefault VPCと呼ばれる直ぐに使えるVPCがあります。
但し、このVPCは本当に必要最小限の設計がされているものとなります。

・ネットワークレンジ
→255.255.0.0（/16）で切られています。
・サブネット
→255.255.255.0（/24）で二つ切られています。これは東京リージョンの話で、現在有効な
アベイラビリティゾーン（AZ）が二つだからです。
＊どちらのサブネットもインターネットに出られる設定となっています。

Default VPCについて詳しくは下記を参照して下さい。
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/default-vpc.html


■VPCってどんなものを設定ができるの？
はい。ざっくり言うと下記のものが設定でき、各々の設定を組み合わせます。
・サブネット
・ルーティング（ルートテーブル）
・インターネットゲートウェイ（IGW）
・DHCP
・ネットワークアクセスコントロール（NACL）

ではDefaultVPCを元に画面を交えて説明しましょう。

・Your VPCs
VPCを作成する画面です。
ここで全体のレンジを決めます。

・Subnets
サブネットを作成する画面です。
ここでサブネットで使用するレンジと、どのAZで使うかを決めます。

・Route Tables
ルーティング（ルートテーブル）を作成する画面です。
ここでVPC内及びインターネット（IGW）の通信経路を決めます。
Default VPCではVPC全体で管理していますがサブネット単位などで決める事もできます。

・Internet Gateways
インターネットに出るための設定を作成する画面です。
論理的な話としてAWSで作成してくれます。

・DHCP Options Sets
DHCPの設定を作成する画面です。
独自のDHCPが必要な場合は別ですが、基本はAWSが用意するものを使用します。

・Network ACLs
ネットワーク単位でIPアドレス（レンジ）単位で通信の制御をします。
Inboud（外→VPC）とOutbound（VPC→外）の通信に対してプロトコル・ポート・IPアドレスを
入れて許可する、許可しないを決めます。

VPCをきっちり覚えて、独自で設計・構築をする場合はネットワーク設計の知識が必要です。
AWSではSecurity Groupsと呼ばれるファイアウォールやインスタンス単位でPublic Accessを
許可する、許可しないなど出来ますが、間違って設定しても大本（VPC）で、そもそも通信が
コントロールされていればセキュリティも安心です。

AWSでは専門知識が無い一般ユーザでも使えるように設計されていますが、専門知識を
持って設計されたネットワーク構成を具現化する設定ができるようになっています。
幅広いユーザのニーズに応える工夫が素晴らしいと思いました！

AWS 認定プログラム DevOpsの対策

久々にブログ書きます！

まずAWSには現在アソシエイトレベルで3つ、プロフェッショナルで2つの認定があります。
でもってタイトルのDevOpsはプロフェッショナルの方になります。

詳しくはここ
http://aws.amazon.com/jp/certification/

ウチの会社はAWSのプレミアコンサルティングパートナーを頂いておりまして、仕事の殆どが
AWSの設計・構築・運用となってます。という事で毎日AWSばっかりさわってます。

ただ最近はお客様先に訪問したり、社内組織作り的なお仕事が多くなってきてしまいまして
自分の技術力がめっきり落ちているのでは？最近入って来たエンジニアにはアイツ偉そうに
してるけど、実は何も分かってないんじゃね？と思われていると勝手に思い込んでます（笑）

と、いう事で技術力の再チェックと、エンジニアである証明（みんなにアピール）をするために、
6月の「AWS Summit Tokyo」から日本語版が出たDevOpsを受けてきました。

結果は！

合格！！！！！！

詳細な正解率は内緒です（笑）

ちなみにSA プロフェッショナルも持ってます！


という事で、傾向と対策を自分なりの意見で書いてみます。

■傾向
CloudFormation、AutoScaling、Elastic Beanstalk、OpsWorks関連が8割くらいです。
もちろんEC2、RDS、S3の基本サービスからELB、Route53、IAM、Kinesis、DynamoDB、
SWFも出て来ますが、おまけみたいな感じです。

ただ、設定をどうするかなどではなく、概念的なものが多いです。
なので、設計が出来ないと厳しいです。SAプロフェッショナルの時も思いましたが、
設問に対する選択肢はどれも実現できるというものが殆どです。
そもそもそのような設定は出来ないという選択肢がアソシエイトではあり、実際に構築を
行う事が出来れば回答できますが、プロフェッショナルはより良い回答を選ぶというものが
多い感じです。要は設問の意図を考えどれがその内容に対して一番正しいかを選択する
という事になるので設計をする能力を試されます。

またデプロイの知識も必要です。デプロイをする知識というよりは、デプロイをするための
基盤設計の知識です。つまりはインフラ観点でソフトウェア（プログラム）をシステムとして
いかに安全に運用するかを設計するという事になります。

■対策
CloudFormation、AutoScaling、Elastic Beanstalk、OpsWorksは各AWSサービスをいかに
効率よく運用するかを補うサービスです。何となく似ているようなものですが、当然各々に
特徴があります。
そのため、各々がどのようなものなのかを知っていれば、何を採用するか設計できます。
正直、私もElastic Beanstalk、OpsWorksに関しては、ほぼさわった事がありません。
ですが、どのようなものなのかは知っていますので、設問に対して何を選択して、どう利用
するのかは答える事が出来ます。
この辺りは極論ですが、WebサイトにあるAWSの各サービスの紹介を見るだけでも十分
知識としては足ります。
→もちろん細かい機能や設定に関する内容も出ますので、まったくさわった事も無いよりは
一通りの設定や操作は覚えておく方が良いです

そこで大事になってくるのが、下記になります。
・負荷対策を自動化するには？
・費用対効果を考えてどうすればコストを抑えられるのか？
・必ず守らなければならないシステム性能を担保するには？
・問題が発生した場合にすぐに戻せるようにするには？
・セキュリティを考えて安全な方法は？

もうこの辺りになりますと、AWS云々ではなくシステム管理の知識になります。
なのでアソシエイトは合格したけれどプロフェッショナルが難しいと思う人は、システム管理
という知識をつける事から始めると良いかもしれません。

おまけ的な話ですが、170分で80問。つまり1問当たりの時間が2分少々という時間との闘いも
あります。なので設問はまずは流し読みして、選択肢を見てから、再度設問にあるキーワード
を拾うのがポイントかと思います。
しかし、経営層に問題を解決するように言われて、2,3分後に回答しないといけないと言う
血を吐きそうな状況です。

■まとめ
・CloudFormation、AutoScaling、Elastic Beanstalk、OpsWorksの特徴を覚える
→出来れば一通りさわってみる
・システム管理としての設計の知識を覚える
→それプラスでデプロイ
・設問はざっくり読んで、まずは選択肢の内容をチェックする
→ポイントなるキーワードを探す（費用を抑える、セキュリティなど）

尚、あくまでも上記の内容は私が受けてみての感想なので、個人差もあるかと思います。
なるほど、そういう観点の考え方もあるのか程度で参考にして頂ければ幸いです。

RDSのReadReplicaをマスター昇格

AWSではとってもお手軽にRDBが使えるRDSというサービスがある。LAMP環境を使う
事が多いので、これは非常に便利！特にReadReplica機能（以下RR）で簡単にリソース
増強できるのでDBへの参照（select）が多い場合は使わないともったいなーい。
このRRをマスター昇格（Promote）できるのでちょっとやってみましょう^^

・事前確認
一応、MasterとRRがどのようになっているかを実際にdbに入ってみてみます。
今回はMySQLのRDSです。以下Master操作は赤、RR操作は緑で表記します。

Master：test
RR：test-rep

■ログイン
[test ~]# mysql -h test.cabhwlkhzqy6.ap-northeast-1.rds.amazonaws.com -u dbowner -p

Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 20
Server version: 5.5.27-log Source distribution

Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.


[test-rep ~]# mysql -h test-rep.cabhwlkhzqy6.ap-northeast-1.rds.amazonaws.com -u dbowner -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 5.5.27 Source distribution

Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

■テーブル内容確認

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

+------+------------+

1 row in set (0.00 sec)

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

+------+------------+

1 row in set (0.00 sec)

同じ状態である事がわかります。

■データ書き込み（レプリケーション確認）

mysql> insert into test_tbl values(2, 'test_user2');

Query OK, 1 row affected (0.02 sec)

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

|    2 | test_user2 |

+------+------------+

2 rows in set (0.00 sec)

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

|    2 | test_user2 |

+------+------------+

2 rows in set (0.00 sec)

Masterに書き込んだ内容がRRにも書き込まれていることが確認できました。

■データ削除（レプリケーション確認）

mysql> delete from test_tbl where name = 'test_user2';

Query OK, 1 row affected (0.02 sec)

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

+------+------------+

1 row in set (0.00 sec)

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

+------+------------+

1 row in set (0.00 sec)

Masterで削除した内容がRRでも削除されていることが確認できました。

■RR書き込み不可確認

mysql> insert into test_tbl values(2, 'test_user2');

ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement

RRはReadOnlyで書き込み出来ない事も確認できました。

・RRのMaster昇格（Promote）

では実際にやってみましょう。作業はManagementConsoleから行います。

１．RDSメニューで対象のインスタンスにチェックを入れた状態で「Instance Action」

→「Promote Read Replica」を選択します。

２．設定画面がでます。RRではバックアップが取られない（当たり前ですが）ため、

自動バックアップを行うための設定を行います。

◎Enable Automated Backups　自動バックアップを行うかのを設定できます

◎Backup Retention Period　バックアップ保存世代数を設定できます

◎Backup Windows　「Select Windows」を選択すると取得する時間を設定できます

設定したら「Continue」をクリックします。

３．注意書き画面がでます。要約すると下記の内容が書かれています。

【レプリケーションが完全にされている事】

【レプリカに戻す事はできません】

問題なければ「Yes, Promote Read Replica」をクリックするとPromote処理が実行されます。

非常に簡単です。処理自体はディスクサイズにより差がでると思いますが、10GBで

15分程度でした。

・事後確認

本当に元RRがMasterとして機能されているか実際にdbに入ってみてみます。

■ログイン

[test ~]# mysql -h test.cabhwlkhzqy6.ap-northeast-1.rds.amazonaws.com -u dbowner -p

Enter password:

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 20

Server version: 5.5.27-log Source distribution

Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

[test-rep ~]# mysql -h test-rep.cabhwlkhzqy6.ap-northeast-1.rds.amazonaws.com -u dbowner -p

Enter password:

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 8

Server version: 5.5.27 Source distribution

Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

■テーブル内容確認

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

+------+------------+

1 row in set (0.00 sec)

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

+------+------------+

1 row in set (0.00 sec)

同じ状態である事がわかります。

■データ書き込み（非レプリケーション確認）

mysql> insert into test_tbl values(2, 'test_user2');

Query OK, 1 row affected (0.02 sec)

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

|    2 | test_user2 |

+------+------------+

2 rows in set (0.00 sec)

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

+------+------------+

1 row in set (0.00 sec)

Masterに書き込んだ内容が元RRには書き込まれていないが確認できました。

■元RRへのデータ書き込み

mysql> insert into test_tbl values(3, 'test_user3');

Query OK, 1 row affected (0.02 sec)

mysql> select * from test_tbl;

+------+------------+

| no   | name       |

+------+------------+

|    1 | test_user1 |

|    3 | test_user3 |

+------+------------+

2 rows in set (0.00 sec)

元RRに書き込みできる事が確認できました。

ちなみに現在ではRDSの名前をModifyから変更する事もできるので、repなどの

Replicaであることの識別子を付与していても、変えれば大丈夫です。

・感想

簡単で便利な機能ではありますが、RDSにはSnapshot（バックアップ）から新規で

インスタンスを起動する事ができます。同じ状態のDBを作成したい場合はSnapshot

からの起動の方が利便性が良いような気がします。強いて言えば完全にレプリカ

されている状態のものとして作成できる事ですが、Masterを静的にしてSnaspshotを

とってからインスタンス起動させれば、その問題もありません。

可能性としてはRDSのMulti-AZ機能を使わずにRRを別ゾーンに作成して、ゾーン

障害がおきてMasterが使えなくなった場合に使う事でしょうか。

CloudWatchのコマンドラインツールでDynamoDBの統計情報作成

前回のブログでDynamoDBの話をしたけど、インフラエンジニアの私は実際のテーブル設計
よりは、運用後のリソース管理が気になるところ。DynamoDBの良いところはスループットが
保障される事。とは言えこれは設定した値が保障されると言う事で、その値が適切でない
場合は結局「なんかレスポンス悪くね？」と言う残念な結果になってしまう事に。。。
それを恐れるがあまり、値を大きくしてしまうと請求の時に「高っ！」とびっくりする事に。
スループットの値は変更が聞くので、今回はDynamoDBの稼動統計を行うために情報取得を
してみましょ！


・情報取得方法
AWSでは稼動情報をみる事ができるCloudWatchという機能があります。こちらはEC2や
RDSなどAWSで扱っているサービスの情報が全て取得できます。何か動きがおかしいと
思った時には、ManagementConsoleからグラフ化されたものを見る事ができます。
ですが稼動統計を行う場合は、定期的に情報を取得しておく必要があります。
そこでコマンドラインツールを使用する事でデータを取得する事とします。

・準備
AWSの下記リンクから「Amazon CloudWatch Command Line Tool」をDownloadします。
http://aws.amazon.com/developertools/2534
今回はLinux（CentOS）を使用するため、DownloadしたzipファイルをEC2に格納します。
格納先は/usr/localとします。

/usr/local以下でzipファイルを解凍します。
# cd /usr/local
# unzip CloudWatch-2010-08-01.zip
# rm -f CloudWatch-2010-08-01.zip
使いやすいようにバージョン情報が入ったディレクトリ名を変更します。
# mv CloudWatch-1.0.13.4 CloudWatch
AWSにアクセスするためのアクセスキー用ファイルをコピーします。
# cp -p CloudWatch/credential-file-path.template ~/credential.txt
→コピー後にファイルを編集します。アクセスキー及びシークレットアクセスキーは事前に
　ManagementConsoleなどで確認しておきましょう。ファイルの中身は下記の通りです。

AWSAccessKeyId=<Write your AWS access ID> AWSSecretKey=<Write your AWS secret key>

中身を他人に見られないようにパーミッションを変更します。
# chmod 600 ~/credential.txt
環境変数の設定です。（これらは.bashrcに記載しておくと良いでしょう）

export AWS_CLOUDWATCH_HOME=/usr/local/CloudWatch
export PATH=$PATH:$AWS_CLOUDWATCH_HOME/bin
export AWS_CREDENTIAL_FILE=~/credential.txt
export AWS_CLOUDWATCH_URL=https://monitoring.ap-northeast-1.amazonaws.com


これで準備は完了です。

・情報取得
今回用意したツールでは情報取得以外にもアラームの設定なども出来ます。今回は
統計情報を取得する事が目的のため、二種類のコマンドの紹介です。

○mon-get-stats
実際に情報を取得するコマンドです。
○mon-list-metrics
どのようなMetricがあるのかを確認（一覧表示）するコマンドです。

では実際に情報取得です。まずはmon-list-metricsで一覧を取得します。
# mon-list-metrics
結果は長いので省略ですが、今回はDynamoDBのRequestLatencyを取得するため一覧
から下記のものを対象とする事とします。

SuccessfulRequestLatency               AWS/DynamoDB     {Operation=GetItem,TableName=test_table} SuccessfulRequestLatency               AWS/DynamoDB     {Operation=PutItem,TableName=test_table} SuccessfulRequestLatency               AWS/DynamoDB     {Operation=UpdateItem,TableName=test_table}

mon-get-statsを使用して情報取得です。取り込み易いようにカンマ区切りにします。
# mon-get-stats SuccessfulRequestLatency \
   --statistics "Average,Sum,Minimum,Maximum" \
   --namespace "AWS/DynamoDB" \
   --dimensions "Operation=PutItem,TableName=test_table" \
   awk '{print $1 "," $2 "," $3 "," $4 "," $5 "," $6}' \
   >> ~/PutItem_test_table.cvs

ファイルの中身は下記のようになります。（時間はUTCのため注意）

2012-12-16,14:55:00,5.25654654646,196.23000000000002,3.265,6.013 2012-12-16,15:00:00,4.95656856565636,188.082,3.258,6.189 2012-12-16,15:05:00,3.565959565332,121.566,3.315,6.396 2012-12-16,15:10:00,4.4421333333333335,133.264,3.345,6.261 2012-12-16,15:15:00,4.2650526315795,165.88600000000002,3.279,6.124 2012-12-16,15:20:00,4.507655172413792,130.761999999998,3.392,6.659 2012-12-16,15:25:00,4.53334375,145.067,3.309,6.538 2012-12-16,15:30:00,4.254555555555555,123.87299999999,3.286,7.649 2012-12-16,15:35:00,4.309178571428572,120.65700000000001,3.251,6.151 2012-12-16,15:40:00,4.5852150000000001,93.043,3.343,5.876 2012-12-16,15:45:00,4.04362,101.138,3.284,5.2546

コマンドの最初の引数はMetricNameです。後の引数は下記になります。
--statistics 集計方法の指定
--namespace サービス名（DynamoDB、EC2など）の指定
--dimensions 集計情報のうちのどの情報かの指定
＊ここがポイントで前述のmon-list-metricsの3カラム目の値となります。

上記のコマンドをcronなどで自動的に取得すれば良いということになります。
少々分からないのが5分おきの直近1時間のデータが取得されるはずなのですが、
11個（55分）しか取得できませんでした。ですので、データの抜けが内容に取得する
間隔を調整して重複するデータはuniqなどで排除する必要がありそうです。
（何か方法があるのかも知れませんが。。。）


大事なのは情報を取得する事ではなく、ここからいかに適切なリソース状態を導き
出すかです。（今後の課題ですね。。。）

DynamoDBをIAMでアクセス制限

DynamoDBは便利。AWSのManagementConsoleのウィザードでちょちょいとテーブル
作成が簡単にできる。検証でさくっと作ってぱぱっとテストも出来てしまう。テーブル
削除もぽちっとすれば、はい消えた！となるのでお手軽。テーブルはあるだけでお金
がかかるので、不要となったら小まめに消さなきゃね。
と、調子にのっているとミスって肝心の本番用テーブルを消してしまいがちなものですね。

そこで、IAMアカウントで本番用と開発用と分けてアクセス制限してしまいましょう^^


・制御内容
ネーミングルール（少なくとも本番用）が必要となります。今回は下記のようにします。
■本番用はテーブル名の頭にprd_がついている
■開発用はそれ以外

・アカウント
アカウントは二つ作成します。
■本番用アカウント　prd_dynamo
■開発用アカウント　dev_dynamo

・グループ
DynamoDBではアラート設定が出来るため、cloudwatchの権限を付与します。
テーブル自体は個々のアカウントでアクセス制御しますので、cloudwatchの権限はgroupで
管理します。Policy Generatorで簡単に作れますが、一応JSON載せておきます。

{   "Statement": [     {       "Sid": "Stmt1354899265648",       "Action": [       "cloudwatch:*"       ],       "Effect": "Allow",       "Resource": [         "*"       ]     }   ] }

では実際にアカウントへのpolicy設定です。 まずはprd_dynamoです。 {   "Statement": [     {       "Sid": "Stmt1330073911360",       "Action": [         "dynamodb:DescribeTable",         "dynamodb:ListTables"       ],       "Effect": "Allow",       "Resource": [         "*"       ]     },     {       "Sid": "Stmt1330073911361",       "Action": [         "dynamodb:*"       ],       "Effect": "Allow",       "Resource": [       "arn:aws:dynamodb:ap-northeast-1:<アカウントID>:table/prd_*"       ]     }   ] } キーとなるのは、次の二点です。 ■最初のAllowでDescribeTableとListTablesを入れる事 →これで全体のテーブルリストを表示する事ができます。全体を表示できるように 　設定しておかないと、自身のテーブルも表示出来ません。この設定でテーブル 　リストの表示のみ出来るようになります。 ■次のAllowのリソースでtable/prd_*と記載する事 →これでprd_*で始まるテーブルを全て制御できるようになります。 次にdev_dynamoです。 {   "Statement": [     {       "Sid": "Stmt1330073911370",       "Action": [         "dynamodb:BatchGetItem",         "dynamodb:CreateTable",         "dynamodb:DeleteItem",         "dynamodb:DeleteTable",         "dynamodb:DescribeTable",         "dynamodb:GetItem",         "dynamodb:ListTables",         "dynamodb:PutItem",         "dynamodb:Query",         "dynamodb:Scan",         "dynamodb:UpdateItem",         "dynamodb:UpdateTable"       ],       "Effect": "Allow",       "Resource": [         "*"       ]     },     {       "Sid": "Stmt1330073911371",       "Action": [         "dynamodb:BatchGetItem",         "dynamodb:CreateTable",         "dynamodb:DeleteItem",         "dynamodb:DeleteTable",         "dynamodb:GetItem",         "dynamodb:PutItem",         "dynamodb:Query",         "dynamodb:Scan",         "dynamodb:UpdateItem",         "dynamodb:UpdateTable" ],       "Effect": "Deny",       "Resource": [       "arn:aws:dynamodb:ap-northeast-1:<アカウントID>:table/prd_*"       ]     }   ] } キーとなるのは、次の二点です。 ■最初のAllowでDynamoDBの全ての権限を記載する事 →これで全てのテーブルの制御ができるようになります。ほんとは*でも良いかと 　思うのですが、ちょっと上手く動かなかったので個別に記載しています。 ■次のDneyでtable/prd_*を記載する事 →これでprd_*で始まるテーブルを全て制御出来なくなります。但し、ここの記載 　にListTablesとDescribeTableは記載してはいけません。テーブルリスト表示が 　出来なくなるため、全体のテーブルリストも表示できなくなります。 さて、アクセス制御出来ているか確認してみましょう。 まずはprd_dynamoです。 テーブルリストが確認できます。 prd_testにアクセスできます。 testにアクセスできません。 次にdev_dynamoです。 テーブルリストが確認できます。 prd_testにアクセスできません。 testにアクセスできます。 最初はActionは*でResourceをprd_*のAllowとDenyで逆にすれば簡単に制御できる かと思いましたが、テーブルリスト表示などの細かい部分で*で制御出来ない感じ でした。

CentOSでRAID0

前回のブログでawsのEC2インスタンスでエフェメラルディスクを使う方法を記載した。
EC2インスタンスサイズによっては複数のディスクを使用する事ができる。
という事で折角なのでCentOSでRAID0を組んでみたので、設定方をを記載してみる。
ちなみにCentOSは6.3を使用。


・最初に
CentOSでソフトウェアRAIDを組む場合はmdadmを使用します。パッケージが組み込まれて
いない場合はyumでインストールできます。
# yum -y install mdadm

・デバイスの確認
エフェメラルディスクがOS上でどのように認識されているか確認します。
# ls -l /dev |grep xvd
→基本的にはEC2インスタンス作成時に割り当てたデバイス名とリンクしています。
　sdbで指定した場合は/dev/xvdbとなります。

今回はディスクを/dev/xvdi、/dev/xvdjの二つ使用する事とします。

・ディスクの初期化
fdiskを使用してディスクを初期化します。
# fdisk /dev/xvdi
→対話型となるため下記の流れで応答します。
　n　新たに領域を作成する
　p　基本領域 (1-4)
　1　一番目
　　　空Enter（開始シリンダを一番最初）
　　　空Enter（終了シリンダを一番最後）
　w　書き込み終了

同様に/dev/xvdjも初期化します。

・デバイスの作成
新規でRAID用デバイスを作成します。
# mknod /dev/md1 b 210 1
→オプション説明
　/dev/md1　デバイスファイル名。mdXとするため今回は/dev/md1を指定
　b　デバイス種別。ブロックデバイスのためbを指定
　210　メジャー番号。空いている番号であれば良いため今回は210を指定
　1　マイナー番号。メジャー番号の中で空いている番号であれば良いため1を指定

・RAIDの作成
mdadmを使用してRAIDを作成します。
# mdadm --create --verbose /dev/md1 --level=0 --raid-devices=2 /dev/xvdi /dev/xvdj
→オプション説明
　--create　作成
　--verbose　画面表示
　/dev/md1　RAIDを作成するデバイス名
　--level=　RAIDのレベル。今回はRAID0のため0を指定。
　--raid-devices=　RAIDに組み込むディスク数。今回は二つのため2を指定。
　/dev/XX　組み込むディスクデバイス名。今回は/dev/xvdi、/dev/xvdjを指定

・RAID構成の確認
指定した内容で作成されているか確認します。
# cat /proc/mdstat

・ファイルシステムの作成
作成したRAIDデバイスを使用してファイルシステムを作成します。今回はex4とします。
# mkfs.ext4 /dev/md1

・mdadm.confの作成
再起動後も使用できるようにmdadm.confファイルを作成します。
# vi /etc/mdadm.conf
→下記の内容を記載します。

DEVICE /dev/xvd[a-z]*
ARRAY /dev/md1 devices=/dev/xvdi,/dev/xvdj


・fatabへの登録
自動起動するようにfstabに追記します。今回は/mnt/1にマウントします。
# vi /etc/fstab
→下記の内容を記載します。
/dev/md1  /mnt/1 ext4 defaults 0 0

・マウントの実施
マウントを実施します。
# mount /mnt/1

・容量の確認
マウントされたボリュームが期待する容量となっている事を確認します。
# df -h /mnt/1

今回の手順はEC2のエフェメラルディスクを使用している事による特別な内容は無く
普通にRAIDを組む場合と同じになります。但し、エフェメラルディスクはEC2インスタンス
のstopで設定などが消えてしまうため、上記手順の一部を再度行う必要があります。
・RAIDの作成
・ファイルシステムの作成
・マウントの実施

私が確認したところ、rebootではRAID構成情報もデータも残っていましたので、stopを
した場合のみ再作成となる様子です。

awsのエフェメラルディスクを使う

久々となってしまったが技術情報を書こうと思う。
今回はawsのEC2インスタンスでエフェメラルディスクを簡単に使う方法を記載する。


・最初に
EC2インスタンスを作成する場合に最近はEBSを使用するのが通常の方法です。
しかしEC2インスタンスにはエフェメラルディスクと呼ばれるテンポラリ的なディスクが
ついています。エフェメラルディスクはEC2インスタンスをstopするとデータが消えて
しまうため、bootディスクやデータファイルのように消えてしまうと問題となる場合には
使用が厳しい事となります。しかし、ファイル転送やデータをダンプして別のディスク
（S3など）へ転送するなどの一時領域としては有効な領域となります。

・使用方法
元々、EC2インスタンスを作成した場合にエフェメラルディスクは自動で付与されて
います。EC2 APIなどを使いEC2インスタンスを起動する際に指定する方法がある
のですが、今回はEC2インスタンスを作成する時に最初からディスク割り当てする
方法を記載します。
１．AWS Management Consoleより新規でEC2インスタンスをlaunch
　　（作成済みAMIからでもOKです）
２．ウィザードの「Storage Device Configuration」にて「Instance Store Volumes」タブ
　　を選択します。
３．ここでエフェメラルディスクを追加します。注意としては0～3と四つ選択する事が
　　できますが、インスタンスサイズにより使用可能なディスクの数や容量に違いが
　　あります。（下記はaws Documentationより抜粋（2012/9現在））

Type	Name	Instance Store Volumes
Micro	t1.micro	None (use Amazon EBS volumes)
Small	m1.small	1 x 150 GiB
Medium	m1.medium	1 x 400 GiB
Large	m1.large	2 x 420 GiB (840 GiB)
Extra Large	m1.xlarge	4 x 420 GiB (1680 GiB)
High-CPU Medium	c1.medium	1 x 340 GiB
High CPU Extra Large	c1.xlarge	4 x 420 GiB (1680 GiB)
High-Memory Extra Large	m2.xlarge	1 x 410 GiB
High-Memory Double Extra Large	m2.2xlarge	1 x 840 GiB
High-Memory Quadruple Extra Large	m2.4xlarge	2 x 840 GiB (1680 GiB)
High I/O	hi1.4xlarge	2 x 1 TiB SSD (2 TiB)
Cluster Compute Quadruple Extra Large	cc1.4xlarge	2 x 840 GiB (1680 GiB)
Cluster Compute Eight Extra Large	cc2.8xlarge	4 x 840 GiB (3360 GiB)
Cluster GPU Quadruple Extra Large	cg1.4xlarge	2 x 840 GiB (1680 GiB)

要は通常のEC2インスタンス作成をする際のディスク設定で指定するだけで、EC2 API
などを使用して起動しなくてもエフェメラルディスクが使用できるようになります。