AWS初心者が本を1冊やってみて学んだことメモ

AWSを使い始めて5日目。ググれどググれど大枠が見えないのでさっぱりわからない。
というわけで本を1冊ハンズオンでやってみました。
内容を忘れないようにメモしておきます。

やった本

『Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版』 日経BP社

アプリ開発は勉強したけど、インフラはさっぱりわからない…そんな自分にぴったりでした。
インフラエンジニアの間では常識なのだろうな(TCP/IPとかHTTPメソッドとか)…ということも丁寧に繰り返し説明してくれています。

学んだこと

IPアドレスとは

TCP/IP通信において、通信先を特定するのに使われるのがIPアドレス。ネットワーク上で互いに重複しない唯一無二の番号、いわゆる「住所」に相当する。

パブリックIPアドレス

インターネットに接続する際に用いるIPアドレスのこと。グローバルIPアドレスとも言う。重複を避けるためICANNと言う団体が一括管理している。

プライベートIPアドレス

インターネットで使われないIPアドレス。10.0.0.0 ~ 10.255.255.255など、範囲が決められている。誰にも申請することなく使える。社内LAN構築時や、自前でネットワークの実験をするときはこれを使う。

ホスト

コンピュータやルーターなどのネットワーク機器など、IPアドレスをもつ通信機器の総称。

VPC領域

VPC = Virtual Private Cloud
つまり、プライベートなネットワーク空間。
作成したユーザーが自由に扱うことができる空間で、他のユーザーからは全く見えない。
IPアドレスをCIDR表記する場合、その範囲は「CIDRブロック」と呼ばれる。
このCIDRブロックをさらに小さなCIDRブロックに細分化したものをサブネットと呼ぶ。

同書を元に作成した図。
image

パブリックサブネット:インターネットからアクセスできる
プライベートサブネット:インターネットからはアクセスできない
→セキュリティを高める時によく用いられるネットワーク構成

サブネットをインターネットに接続するには、「インターネットゲートウェイ(Internet Gateway)」を用いる。自分のネットワークにインターネット回線を引き込むイメージ。

ルートテーブル

宛先IPアドレスの値がいくつのときに、どのネットワークに流すべきか、と言う設定。

「宛先アドレス」 「流すべきネットワークの入り口となるルーター」

という書式で設定。
宛先アドレス=ディスティネーション(destination)
流すべきネットワーク先=ネクストホップ(next hop)、ターゲット(target)

TCP/IP

ポート(Port):他のコンピュータと、データを送受信するためのデータの出入り口

ポートには、以下の2種類がある。
TCP(Transmission Control Protocol):相手にデータが届いたことを保証する。
UDP(User Datagram Protocol):確認せずに送信する(その代わりに高速)

ファイアウォール

「通してよいデータだけを通して、それ以外を遮断する機能」の総称。
そのもっとも簡単な構造のものがパケットフィルタリング(Packet Filtering)。

パケットフィルタリング

流れるパケットをみて、通過の可否を決める仕組み。パケットには、「IPアドレス」のほか「ポート番号」も含まれている。パケットフィルタリングは、「IPアドレス」と「ポート番号」など、パケットに付随する各種情報を見て、通過の可否を決める。
AWSでは、インスタンスに対して構成する「セキュリティグループ」がこの機能を担当する。

インバウンドとアウトバウンド

インバウンド:外から、このインスタンスに接続する向き(例 誰かが接続しようとしているのを排除する)
アウトバウンド:このインスタンスから外に出て行く向き

NAT

NAT=Network Address Translation
「プライベートサブネット→インターネット」の向きの通信だけを許可する。

例えば、DBサーバーはインターネットからは接続されたくない。しかし、サーバーのアップデートやソフトウェアのインストールのために、DBサーバーからインターネットへは接続できるようにしたい。そういうときは、DBサーバー(プライベートサブネット)→インターネットの一方向の通信のみを許可できる。

curlコマンド

「HTTPやFTPで、ファイルをダウンロードしたりアップロードしたりするコマンド」。Amazon Linuxにはtelnetコマンドがインストールされていないため、代わりにcurlコマンドを使う。

続きを読む

AWS ソリューションアーキテクトプロフェッショナル 受けてきました&勉強法(2017/6版)

前書き

image.png

 前回 の続きです。ソリューションアーキテクトアソシエイト(SAA)に受かったので今度はプロフェッショナル(SAP)に挑戦しました。

AWS の資格試験はわかりにくい

ワークショップについて

 公式サイトから読み取れないので補足。以下のクラスがありますが、

レベル/分野 アーキテクト 開発 運用
アソシエイト取得済み Advanced Architecting on AWS DevOps Engineering on AWS 同左
アソシエイト未取得向け Architecting on AWS Developing on AWS Systems Operations on AWS
AWS 未経験者向け Amazon Web Services 実践入門 1 / 2 同左 同左

 前提事項は記載ありるものの、いきなり Advanced などを受けてもいいし、受けずに受験に挑んでも大丈夫です。アソシエイト未取得向けのを2つ受ける必要はなさそうなので、Architecting 受けてから Developing 受けたりするのは、けっこう内容の重複がある ので、お金がもったいない。
 その他のクラスは試験に出てくる頻度が低いので、興味があれば受ければいいやつです。

 ソリューションアーキテクトアソシエイト(SAA) だけは試験対策として半日のワークショップがありますので、時間とお金があれば受けるといいかと。

認定試験について

 おさらいですが。
image.png

 ワークショップと同じく、範囲がかぶっているので アソシエイト取れたらほかのアソシエイトもいけそう なので、資格の数を増やすにはよさそうです、プロフェッショナルはそう簡単にいかないですが。英語版の資格として Advanced Networking 、Big Dataが追加となっています。Security(Beta) もあった気がしますが、 Beta が取れていないのかな。いずれさらに上の階級にある Master が提供されるかもしれないという噂があったりします。

試験概要

 概要をざっくり記載します。アソシエイトの倍の時間でついでに受験料も倍です。合格ラインはやはり65%という噂です。1問あたり2分ちょっとで解き、3時間集中し続ける というなかなかヘビーな内容です。

TOPIC DATA
試験時間 170分間
問題数 80問
合格ライン 非公開
受験料 ¥32,400

出題範囲

 出題範囲を確認すると、アソシエイトでは高可用性がほとんどでしたが、Pro では求められるものが変わっていることがわかります。そのほか試験ガイドをざっと読みました。

TOPIC 出題率
高可用性および事業継続性 15%
原価計算 5%
デプロイメントマネージメント 10%
ネットワーク設計 10%
データストレージ 15%
セキュリティ 20%
拡張性と伸縮自在性 15%
クラウド移行およびハイブリッドなアーキテクチャ 10%

学習

セミナーを受講する

 前述の Advanced Architecting on AWS を受講しました。
 セミナーには AWS 社員の方や、AWS をすでに実務で利用されているかたが多くいて、私のような素人も半分くらいいる印象でした。私は実業務で AWS に触れたことが実はほとんどなく、本気の AWS 運用に必要な知識を持ち合わせていなかったので次のような観点が非常に勉強になりました。

  • ユーザ管理:IAM と ADやフェデレーションでの連携を考慮し、大規模運用を考える
  • コスト観点:一括請求やスポットインスタンスの選び方で、大幅なコスト削減を考える
  • 運用・監査:KMSを使用した暗号化、CloudLogs でのロギング、ClodWatch でのモニタリングで運用・監査への対応を考える
  • 可用性・セキュリティ:大規模&複数VPCのデザイン、MultiAZ、MultiRegion で可用性向上を実現する、DDoS からインフラを保護する

AWS 活用資料集(BalckBelt)、WhitePaper を読む

 アップデートもあるので、改めて時間を見つけて読みました。時間があるときは Webinar にも参加しました。 Webinar だと日々疑問に思っていることの質問を AWS の SA に直接質問できるので、すごくおトクです。

  • BlackBelt

    • Amazon EC2
    • Elastic Load Balancing
    • Auto Scaling
    • Amazon EC2 Container Service
    • AWS Elastic Beanstalk
    • AWS Lambda
    • Amazon EBS
    • Amazon S3
    • Amazon CloudFront
    • Amazon Glacier
    • AWS Storage Gateway
    • Amazon Elastic File System
    • AWS CloudTrail & AWS Config
    • AWS Support & Trusted Advisor
    • AWS Directory Service
  • WhitePaper

    • セキュリティのベストプラクティス
    • セキュリティプロセスの概要
    • リスクとコンプライアンス
    • AWS を用いた故障耐障害性の高いアプリケーションの構築
    • 新しいリージョンへの AWS リソースの移行
    • 災害対策目的での AWS の使用

本読む

 AWS 事例全集 といった AWS が配っている冊子もありますが数がひたすら多いので、勉強用としてこちらの本で一般的なアーキテクチャを学びました。

image
Amazon Web Services 定番業務システム12パターン 設計ガイド

試験に向けて

 以下、結果もあわせて書いていきます。

サンプル問題集にチャレンジ

ソリューションアーキテクト プロフェッショナル

 サンプル問題を解いた結果、微妙でした。アソシエイトは本試験とくらべて非常に簡単だったので、先が思いやられます。

結果

4/6問 正解

ソリューションアーキテクト以外もやってみる

 SysOpsアソシエイト、DevOpsアソシエイトのサンプル問題もやってみました。ソリューションアーキテクトとはちょっと毛色の違うサービス(CloudFormationとかSQSとか)が出てくるので復習になります。Pro は回答が書いていなかったのでやっていません。

SysOps結果

6/10問 正解

DevOps結果

6/9問 正解

模擬試験

 データ書いておきます。なお、アソシエイト合格者はバウチャーコードが利用できますので活用しましょう。問題文はコピーできます。

TOPIC DATA
試験時間 90分間
問題数 40問
合格ライン 明記なし
受験料 ¥4,320

結果

得点: 27%
結果: 不合格

 時間足りなさすぎました。結果を分析しますが全体的に悪すぎて手のうちようがない感じでした。。。

TOPIC 出題率 正解率(模擬結果) 模擬出題数(予測) 誤答数(予想)
高可用性および事業継続性 15% 33% 6 4
原価計算 5% 0% 2 2
デプロイメントマネージメント 10% 0% 4 4
ネットワーク設計 10% 50% 4 2
データストレージ 15% 50% 6 3
セキュリティ 20% 25% 8 6
拡張性と伸縮自在性 15% 16% 6 5
クラウド移行およびハイブリッドなアーキテクチャ 10% 25% 4 3

出題傾向を抑える

 ベストプラクティスが複数書いてあって、どれも正解だけどよりベストなものを選ぶという問題や、コスト/可用性/移行期間/既存システムとの連携 のどれが求められているのかといった、真の目的を把握しないと答えられない問題が多くありました。
 また、昔の AWS 構成を最新のサービスで置き換えるような問題もあるため、古くなった知識はアップデートが必要です。

模擬試験の復習と弱点克服

 CloudHSM とかの暗号化系、DirectConnect/StorageGateway などの低レイヤー系、TrustedAdvisor など課金系、STS/IAMロールなどの認証系、StepFunctions や SWF などフロー系、Redshift や Kinesis などのBigData系 は、アソシエイトでも踏み込んだ問題が出なかったので個人的に苦手でした。これらは BlackBeltで復習しました。
 また、コピーした模試の問題はを1つづつ調べ、答え合わせをしました。模擬試験については本試験でも出ることがあるので暗記するつもりで復習しました。英語で回答を解説しているサイトがあるので大いに活用しました。

本試験

結果

合格!

image.png

内訳

総合スコア: 66%

トピックレベルのスコア:
1.0 High Availability and Business Continuity: 91%
2.0 Costing: 75%
3.0 Deployment Management: 62%
4.0 Network Design: 37%
5.0 Data Storage: 91%
6.0 Security: 56%
7.0 Scalability & Elasticity: 69%
8.0 Cloud Migration & Hybrid Architecture: 28%

所感

 なんとかギリギリセーフでした。本試験、すごい疲れます。。。
 実務半年程度のペーペーなので試験勉強と実務知識が比例するわけじゃなく、試験としては問題数こなすのが一番という気がしました。本試験のほうが模試より簡単だったので絶望せずがんばりましょう。

 次は DevOps に挑戦したいです。

続きを読む

PHPでAWS SDKを使い、ファイルをアップロードしたら417 Expectation Failedが起きた時の対策

なかなか解決しなかった上、全体的に情報が少ない現象だったので、備忘録として現象と対策を残しておこうと思う。

まず、構成について、下記のような状態です
[EC2:PHPアプリサーバ]->[EC2:Squid3プロキシ]->[S3]

  • PHPアプリサーバ
    PHP 5.6.17
    Apache 2.2.27

  • Squid3プロキシ
    Squid 3.1.23

Kernel.sysctl.conf
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.panic = 5
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 10240    65535
fs.inotify.max_user_watches = 1677721
squid.conf
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access allow all
icp_access allow all
icp_port 0
http_access deny all
http_port 3128
http_port 3151 transparent
http_port 3152 intercept
coredump_dir /var/spool/squid
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|?) 0     0%      0
refresh_pattern .               0       20%     4320
visible_hostname unkown
forwarded_for off
request_header_access X-FORWARDED-FOR deny all
request_header_access Via deny all
request_header_access Cache-Control deny all
max_filedesc 262144

以上の設定で、[PHPアプリサーバ]から[Squid3プロキシ]を通して[S3]のバケットにデータをS3 Client::putObjectを実行した時、

AWS HTTP error: cURL error 56: Received HTTP code 417 from proxy after CONNECT (see
 http://curl.haxx.se/libcurl/c/libcurl-errors.html)  (client): 417 Expectation Failed

というエラーを出し、アップロードが失敗する現象が発生した。
問題なのは、ファイルによって出たり出なかったりする点、必ず出るなら対策しやすいと思うが、出る場合、出ない場合、ファイルサイズによっても挙動が変わったりと、現象が安定しない。
PHPやcURL、ライブラリの調整などいろいろ行ってみたが効果がなく、同様の現象を探したところ、

https://stackoverflow.com/questions/13670040/amazon-s3-putobject-not-working-php

I’ve had this issue behind a squid3 proxy and the problem was resolved by the following squid configuration directive:

ignore_expect_100 on

という情報を得ることが出来た、この設定はSquid Proxyの設定に対して設定するモノで、デフォルトはoff、ファイルの拡張リクエストを許可するかどうかというものらしい。S3ライブラリでは、一定のサイズになると、ヘッダーにexpect_100を追加して、ファイル情報の拡張を行うようなのだが、Squidを通してS3にコマンドが送られると、このヘッダーが理解されないので、応答が返らなくなってしまうというのが、417のエラーの正体のようだ。

そこで、squid.confに対して、”ignore_expect_100 on”を定義することで現象が解決することが確認できた。
修正したsquid.confは以下の通り

squid.conf
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access allow all
icp_access allow all
icp_port 0
http_access deny all
http_port 3128
http_port 3151 transparent
http_port 3152 intercept
coredump_dir /var/spool/squid
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|?) 0     0%      0
refresh_pattern .               0       20%     4320
visible_hostname unkown
forwarded_for off
ignore_expect_100 on
request_header_access X-FORWARDED-FOR deny all
request_header_access Via deny all
request_header_access Cache-Control deny all
max_filedesc 262144

設定後、./squid reloadを実施して、再度、S3 Client::putObjectを実行した結果、問題なくファイルがアップロードされた。
同じ問題に直面している人は少ないと思うが、ここに情報を残しておこうと思う。

誰かの助けになれば幸いだ。

続きを読む

AWSのGPUインスタンスでChainerMNを動かす環境構築

ChainerMNを試してみようと思い、AWS上に環境構築をしてみたので、その作業記録を残しておきます。

AWSのp2インスタンスはそれなりの値段がするので、環境構築は素早く終わらせたいですよね。

構成

  • AWS p2.8xlarge
  • Ubuntu Server 16.04 LTS (HVM), SSD Volume Type – ami-efd0428f
  • CUDA 8.0
  • cuDNN v5.1
  • Python 3.5.2
  • Chainer 1.24.0
  • ChainerMN 1.0.0b1

参考サイト

作業

前準備

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install linux-generic
$ sudo apt-get install build-essential
$ vi .bashrc # 以下の2行を追加
export LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH"
export CPATH="/usr/local/include"

NVIDIA DriverとCUDAのインストール

CUDA Toolkit Download にアクセスし、Linux、x86_64、Ubuntu、16.04、deb [network]と選択し、ダウンロードリンクを拾ってきて、以下の作業をする。

$ wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_8.0.61-1_amd64.deb
$ sudo dpkg -i cuda-repo-ubuntu1604_8.0.61-1_amd64.deb
$ sudo apt-get update
$ sudo apt-get install cuda nvidia-367
$ sudo reboot
$ sudo apt-get autoremove
$ rm cuda-repo-ubuntu1604_8.0.61-1_amd64.deb
$ vi .bashrc # 以下の4行を追加
export CUDA_HOME="/usr/local/cuda-8.0"
export PATH="$CUDA_HOME/bin:$PATH"
export LD_LIBRARY_PATH="$CUDA_HOME/lib64:$LD_LIBRARY_PATH"
export CPATH="$CUDA_HOME/include:$CPATH"

ログインし直す。

cuDNN 5.1のインストール

cuDNN DownloadでDownload cuDNN v5.1 (Jan 20, 2017), for CUDA 8.0、cuDNN v5.1 Library for LinuxをダウンロードしてAWS上に置いておく。

$ tar xzvf cudnn-8.0-linux-x64-v5.1.tgz
$ sudo cp -a cuda/lib64/* $CUDA_HOME/lib64/
$ sudo cp -a cuda/include/* $CUDA_HOME/include/
$ sudo ldconfig
$ rm -rf cuda cudnn-8.0-linux-x64-v5.1.tgz

LightDM を止める

$ sudo vi/etc/default/grub # 12行目を以下の用に編集
GRUB_CMDLINE_LINUX="systemd.unit=multi-user.target"
$ sudo update-grub
$ sudo reboot

Open MPIのインストール

Open MPI Open Source High Performance ComputingからOpen MPIのダウンロードリンクを拾ってきて、以下の作業をする。

$ wget https://www.open-mpi.org/software/ompi/v2.1/downloads/openmpi-2.1.1.tar.bz2
$ tar jxvf openmpi-2.1.1.tar.bz2
$ cd openmpi-2.1.1
$ ./configure --with-cuda
$ make -j4
$ sudo make install
$ cd
$ rm -rf openmpi-2.1.1 openmpi-2.1.1.tar.bz2

NVIDIA NCCLのインストール

$ git clone https://github.com/NVIDIA/nccl.git
$ cd nccl
$ make CUDA_HOME=/usr/local/cuda-8.0
$ sudo mkdir /usr/local/nccl
$ sudo make PREFIX=/usr/local/nccl install
$ cd
$ rm -rf nccl
$ vi .bashrc # 以下の4行を追加
export NCCL_ROOT="/usr/local/nccl"
export CPATH="$NCCL_ROOT/include:$CPATH"
export LD_LIBRARY_PATH="$NCCL_ROOT/lib/:$LD_LIBRARY_PATH"
export LIBRARY_PATH="$NCCL_ROOT/lib/:$LIBRARY_PATH"

ログインし直す。

Chainer, ChainerMNなどのインストール

$ sudo apt-get install python3-pip
$ sudo pip3 install --upgrade pip
$ pip3 install --user pillow h5py chainer
$ pip3 install --user cython
$ lspip3 install --user chainermn

詰まったところ

NVIDIAドライバーのインストール

  • 上の手順でやれば間違いないはず

ChainerMNのインストールがうまくいかない

  • 原因:CythonがLD_LIBRARY_PATHとCPATHを正しく見ていなかった

参考のChainer 1.5のインストールがうまくいかない人への非公式なTipsによると、Cythonインストール前にLD_LIBRARY_PATHとCPATHが設定されていないといけないらしい。
また、pipをsudoで行うと、環境変数がrootに引き継がれないので注意。–userでやろう。

続きを読む