AWS認定ソリューションアーキテクト-プロフェッショナルに合格するためにやったことまとめ

8月にアソシエイトに合格し、じゃあプロフェッショナルも取るかと思ったものの、日本語のソースだとプロフェッショナルに受かるためにどんなことをしたらいいかの情報が少なかったので、自分がやったことのまとめ。
※2017年10月時点での情報だと思ってください

よく問われるサービス

  • コンピューティング

    • EC2,Elastic Beanstalk
  • ストレージ
    • S3, EFS, Glacier, Storage Gateway
  • データベース
    • RDS, DynamoDB, ElastiCache, Amazon Redshift
  • ネットワーク&コンテンツ配信
    • VPC, CloudFront, Direct Connect, Route53
  • 管理者ツール
    • CloudWatch, CloudFormation, CloudTrail, OpsWorks
  • セキュリティ、アイデンティティ、コンプライアンス
    • IAM, Certificate Manager, Directory Service, CloudHSM
  • 分析
    • EMR, CloudSearch, Kinesis, Data Pipeline
  • モバイルサービス
    • Cognito
  • アプリケーションサービス
    • SWF, Elastic Transcoder
  • メッセージング
    • Simple Queue Service, Simple Notification Service, Simple Email Service

最低限読んでおく資料

まずはここを見て各サービスの概要を把握する。

概要をつかんだらこれを読んで細かいハマりポイントを理解する。

試験ガイドにあるようにホワイトペーパーも出題範囲。英語多め。各種ベストプラクティスくらいは読んでおく。

いわゆるCDP。典型的な設計パターンがまとめられている。

主要なサービスのドキュメントは一通り読む。

気を付けるポイント

  • 各種IDフェデレーション

AssumeRole, AssumeRoleWithWebIdentity, AssumeRoleWithSAML, GetFederationToken, GetSessionTokenがそれぞれどのようなケースで使うのが適当かを押さえる。

  • EC2のインスタンスタイプ
    「T2はバースト可能」「R4はメモリ最適化」といった用途を押さえる。回答の選択肢の中にさらっと出たりする。

  • VPN, DirectConnect, VPC peeringの特徴やユースケース
    オンプレミスとのハイブリッド環境でよく問われる。冗長化する(SPOFをなくす)方法も押さえておく。

  • EBSのIOPS
    最大値および最大値を超えるIOPSが必要な場合の設計方法を押さえる。

  • VPCにおいて予約されているIP

  • 各種サービスがどのレベルで提供されるのか(AZ、リージョン、グローバル)
    単一リージョンから複数リージョンへの移行や、グローバルレベルでの可用性・耐障害性に関する問題がよく出る。

  • CloudFormation, Elastic Beanstalk, OpsWorks
    それぞれの特徴や違い、作成(デプロイ)・変更・削除・中止方法を押さえる。

  • キャッシュエンジンの違い
    ElastiCacheにおけるmemcachedおよびRedisそれぞれの特徴を理解する。

  • 一括請求 (コンソリデーティッドビリング)
    請求を統合する方法および共有されるもの/されないものを押さえる。

有料学習サービス

  • Linux Academy

    • AWS SAプロ用のコースがあって、動画とハンズオンで学習できる。
    • 動画は英語のみで字幕もないが、活用資料集で概要を把握していれば十分理解できるレベル。
    • 登録後7日間は無料。その後は月額料金($29)が発生。無料期間だけで終わることもできる(ただし、ハンズオンは利用不可)。
    • 登録時にクレジットカードかpaypalの登録必須。
    • 独自の模擬試験もついていて、個人的にかなり良かった(無料期間だけで終わったけど…)

他にも海外のブログだとQwikLABSとかa Cloud Guruが評判が良かった(僕は使ってないです)

模擬試験について

公式の模擬試験は一度は受けた方がいい。問題形式や時間配分を体感できるのは重要。
アソシエイトに受かった時に模擬試験を無料で受験できるバウチャーがもらえるので、それを使うのが吉。
ただし、僕が受けた時は日本語がひどくて、日本語として何を言っているか分からない問題が多々あった(本番はまともだった)。もし模擬試験を受けてその日本語に恐怖を覚えても、本番ではそこまで怯える必要はないと思う。

本試験予約時の注意

  • 支払ページの請求先住所は英語で入力。全部入りきらなくても気にしない。

赤字で「英語で入力しろ」と注意書きもあるけど、英語で入力するとフォームの文字数制限で書ききれない。これじゃAWS困るだろと思って日本語で入力するとtemporary errorになる。このtemporary errorが日本語入力のせいだと気付かず、LiveChatで聞いたりして1週間以上待った…。
ちなみに英語で住所を入力して全部入りきらなくても郵便番号欄もあるので、中の人が補完してくれるとのこと。

  • 試験会場の住所が全部表示されない時は英語表示に切り替える

なぜか日本語表示だと郵便番号レベルの住所しか表示されず、とても不安な気持ちになるが、英語表示に切り替えるとちゃんと表示される。謎。

続きを読む

Amazon EMR 上の WebUI群 ( Hue や Zeppelin ) をSSHトンネルなしでブラウザ表示する方法

概要

EMR で構築したクラスタ上の WebUI をブラウザ表示するには SSH トンネリングを利用した接続が推奨されていますが、この方法は不便が多いため、より気軽な方法を模索しました

最終的に リバースプロキシ をおいて接続する方法 が良かったので共有します

構成

検証環境 : EMR-Release 5.2.1

SSH トンネリングによる構成

  • この図では master-public-dns-name に対してインターネット経由で SSH トンネルを作成しています
    (VPN 接続がある場合は、Local Netowark 内を通します)
  • EMR Master インスタンスのある SecurityGroup で SSH のポート(デフォルト22)を接続元指定で開け、各クライアントマシンと EMR Master インスタンス間で SSH トンネルを作成して、ポートフォワーディングによってブラウザで任意のWebUIと通信を行います

問題点

  • 各クライアント(各個人PC)マシン上で設定が必要になる(非エンジニアでは作業負荷が高い)
  • SSHで繋ぐため、クライアント(各個人PC)にEMR master への秘密鍵をばらまく必要がある(秘密鍵は隠したい)
  • 都度 SSHトンネル接続&Webブラウザアクセスの手順が面倒

Hue や Zeppelin などの分析ツールは大勢の非エンジニアが利用するケースもありえます
その場合各個人クライアントに鍵を配ったりターミナルでSSHトンネルを作成させたりする操作は煩雑でつらいものがあります

リバースプロキシをおく構成

  • プロキシサーバ に対してインターネット経由で接続します
    (SSHトンネルの例と同様、VPN 接続がある場合は Local Netowark 内を通します)
  • EMR Master とは別インスタンスでプロキシサーバを稼動させます
  • プロキシサーバまでは https、プロキシサーバから EMR master は private network 内を http で通信させます
    (個別のWebUIはSSL設定しなくて良い)
  • 各クライアント(各個人PC)マシンは追加設定不要
    (ブラウザアクセスするだけでOK)

EMRとは別にプロキシサーバを構築するため追加コストがかかりますが、個別クライアントは何の設定も要らず、ブラウザアクセスするだけで、Hue や Zeppelin などお好みの WebUI を参照できるようになります

構築手順

1. リバースプロキシを配置するサーバの Security Group 設定

外部から(またはLocalNetwork内)の https リクエストを許可します
ポートは、利用したい WebUI にあわせて必要な個数分開けます
後述 しますが、ドキュメントに載っていないポートが参照される場合があるので、適宜追加します)

タイプ    : カスタム TCP ルール 
プロトコル : TCP
ポート範囲 : 8888
ソース    : <アクセス元の Public IP (またはLocalNetwork内のアクセス元 Private IP )>

2. EMR Master の Security Group 設定

EMR Master の Security Group では、リバースプロキシ (private ip) からの http リクエストを許可します

タイプ    : すべてのトラフィック
プロトコル : すべて
ポート範囲 : すべて
ソース    : (Private Network のIP範囲) 

3. DNS設定

お好みのドメイン名を決め、そのドメインへのアクセスをプロキシサーバへ誘導するよう DNSレコード を設定します

ラベル : emr.your-site.com(管理下のお好みのドメイン名)
TTL   : 任意の時間 Time To Live
クラス : IN
タイプ : A
リソース : <リバースプロキシサーバの Public IP >

Route53などであれば次のような感じです(イメージ)

4. リバースプロキシの構築

プロキシサーバ上では、特定のドメイン/ポート指定でアクセスがきた場合に、EMR Master サーバの指定ポートへ代理アクセスするよう設定します
今回は EC2 で適当なインスタンスを確保し、Nginx を使ってプロキシさせます

Nginx インストール

リバースプロキシを配置するサーバにNginx をインストールします
(環境にあわせて、安定動作するものを選んでセットアップします)
https://www.nginx.com/resources/wiki/start/topics/tutorials/install/

SSL証明書の配置

SSL証明書を配置して、Nginx で https リクエストがきた場合に参照させます
(証明書は必要に応じて入手します)

ls /path/to/cert/*
/path/to/cert/your-site-ssl-certificate.crt
/path/to/cert/your-site-ssl-key.pem

Nginx 設定例(後でまとめて書きます)

ssl on;
ssl_certificate     /path/to/your-site-ssl-certificate.crt;
ssl_certificate_key /path/to/your-site-ssl-key.pem;

コンテンツ書き換え

WebUI群の中には、リンクを生成する際に 自身の名前 master-private-dns-name を使う場合があるため、ブラウザアクセスした場合に表示されるページ内のリンクが飛べない(名前解決できない)ケースが発生します
これを回避するために、Webサーバのコンテンツ書き換え機能を使って master-private-dns-name を名前解決できるドメイン(先ほどDNS登録した管理下のお好みのドメイン)に書き換える処理をはさんでおくとストレスなく使えるようになります

Nginx 設定例(後でまとめて書きます)

sub_filter '(master-private-dns-name)' 'emr.your-site.com(管理下のお好みのドメイン名)';
sub_filter_once off;

Nginx設定

利用したいWebUIのポートに対して、それぞれプロキシ設定を追加します
この際、上記で紹介したSSL設定とコンテンツ書き換えを加えて下記のように設定します

/path/to/nginx/nginx.conf

# hue wabapp
server {
    listen 8888 ssl;
    server_name emr.your-site.com;
    access_log /path/to/proxy-your-site.com.access.log main;

    ssl on;
    ssl_certificate     /path/to/your-site-ssl-certificate.crt;
    ssl_certificate_key /path/to/your-site-ssl-key.pem;

    location / {
        proxy_pass http://<master-private-ip>:8888/;
        sub_filter 'ip-xx-xx-xx-xx.region.compute.internal' 'emr.your-site.com';
        sub_filter_once off;
    }
}

# 
server {
    listen 8080 ssl;
..............(同様)
}

..............(必要なポート分設定)

この例では 共通のドメイン emr.your-site.com に対して ポートごとに振り分けさせていますが、もし個別のWebUIごとに別ドメインを割り当てるほうがお好みであれば、そのように設定することももちろん可能です
hue.your-site.com へのアクセスで <master-private-ip>:8888 へ誘導する など)
ただしURLの書き換えルールが複雑になってしまうので、そのあたり検討する必要がでてきます

対象となる WebUI 群

設定対象となる WebUI 群のリストは、Amazon EMR のドキュメント を参照します

なお利用するWebUIによってドキュメントに載っていないポートも参照されるため、状況に応じて必要なポートを登録します
(一応個人的に必要だったものを羅列します)

Web UI Name uri
Hue master-public-dns-name:8888/
Tez UI master-public-dns-name:8080/tez-ui/
Zeppelin master-public-dns-name:8890/
Yarn Web Proxy master-public-dns-name:20888/
YARN ResourceManager master-public-dns-name:8088/
Yarn ResourceManager? master-public-dns-name:8032/
Hadoop HDFS NameNode master-public-dns-name:50070/
Yarn timeline-service Webapp master-public-dns-name:8188/
Spark HistoryServer master-public-dns-name:18080/

設定を書き終えたら、Nginxのプロセスを起動させます

5. 動作確認

設定は以上です、実際にブラウザで 個別の WebUI を開いてみます

Hue
http:// emr.your-site.com :8888/

無事に個別のWebUIが開く & 表示されてるリンクへ正しく遷移できれば、設定完了です! :thumbsup:

まとめ

Amazon EMR 上の WebUI 群へのアクセスを リバースプロキシ経由 にすることで、以下の利点が得られます

  • WebUIへアクセスする チームメンバーの負担を大幅減できる
    (クライアントマシンの設定不要で、ブラウザアクセスですぐ使える)
    (SSHトンネル設定のように接続が切れることもない)
  • SSH秘密鍵をばらまかなくてよい
    (余計なリスクを負わなくてよい)
  • リバースプロキシで SSL設定をまとめて行うことができる
    (個別WebUIでSSL対応させなくてよく、設定を一元的に行える)
  • コンテンツ書き換え処理によって、 すべてのリンクをたどれるようにできる
    (単体の WebUI でなく、複数同時に公開可能)

ぜひおためしください!

参考資料

続きを読む

node-jt400を試してみた(on AWS_EC2)

環境

AWS EC2でnode-jt400が稼働するかテストしました。
マシンイメージ:Amazon Linux AMI
タイプ:t2.micro
node.js:6.9.1
npm:3.10.8
jdk:java:1.8.0_131

インストール

mkdir myfolder
cd myfolder
npm init -y
npm install node-jt400

問題無く、インストールできました。

参考までに、node-jt400でインストールされるモジュールです。

└─┬ node-jt400@1.4.1
  └─┬ java@0.8.0
    ├── async@2.0.1
    ├─┬ find-java-home@0.1.3
    │ └── which@1.0.9
    ├─┬ glob@7.1.1
    │ ├── fs.realpath@1.0.0
    │ ├─┬ inflight@1.0.6
    │ │ └── wrappy@1.0.2
    │ ├── inherits@2.0.3
    │ ├─┬ minimatch@3.0.4
    │ │ └─┬ brace-expansion@1.1.8
    │ │   ├── balanced-match@1.0.0
    │ │   └── concat-map@0.0.1
    │ ├── once@1.4.0
    │ └── path-is-absolute@1.0.1
    ├── lodash@4.16.4
    └── nan@2.4.0

EC2からIBMi(AS400)へのネットワーク接続

いろいろ方法はあるかと思いますが、今回はテストなのでSSHを使用しポート転送を行いました。転送したのは以下のポートです。
449・8470・8471・8473・8475・8476

私は以下のコマンドを実行しました。

ssh -C -N -f -L 449:ibmi:449 sshuser@sshhost
ssh -C -N -f -L 8470:ibmi:8470 sshuser@sshhost
:

EC2のポートを開ける

nodeの待ち受けは8888ポートを使用しているので、解放します。
VPN→セキュリティグループ→インバウンドのルール

接続先ホストの改修

以前のテストで使用したSQLquery.jsのhostパラメータを修正します。

var pool = jt400.pool({ host: '127.0.0.1', user: 'MYUSER', password: 'MYPASS' });

nodeの実行

node SQLquery.js

実行結果

nodejt29.png

続きを読む