AWS認定ソリューションアーキテクト アソシエイト試験に合格してきたので学習内容について

aws SA ソリューションアーキテクト

タイトルの試験に合格してきたので記録！

aws.amazon.com

きっかけとか動機とか

以前から興味があったのですが、 re:ineventに行けそうなロードマップも見えてきたので「認定者ラウンジ入りたいなー」という不純な動機で始めました。 あとは「なんとなく周りで取得してる人増えてるなー」というちょっとしたコンプレックスもあったりして「エイや」で受験してきました。 割と他の人のブログも参考にしたのでこれも何かの参考になればなーと思い書いてみました。

学習開始時のスペック

  • AWS歴4,5年
  • 自社サービス向けのインフラ
  • 基本的に独学
  • 公式ドキュメントはあまり読まない（ダメすぎる）。クラスメソットのブログ読んでばかり。

学習期間と内容のサマリー

  • 大体1ヶ月くらい
  • 下段に書いていある参考書をひたすらやる
    • 下段で書きますが特に黒本は良かった気がする
  • 模試を受けた
    • 合格ライン取得
  • 模試後1週間後くらいに受験

試験内容の印象

  • 受験料高い
  • 模擬試験も受験料も半額ぐらいがいいなー。。。
  • いわゆる教科書とノートみたいな勉強スタイルから遠ざかっている体を「机に向かって勉強する」という状態に持って行くのにそれなりに時間かかった
    • 人によると思うのですが参考書を読んでるだけでは頭に入ってこなかった

結局試験である以上は受験勉強

当たり前の話なんですが、試験である以上やっぱり試験対策する必要があるなーと思いました。 当たり前ですが実務には時間制限とかそんなに無いですしドキュメントゆっくり読めばいいんですが。 試験である以上は時間内に正解を選ぶという試験ならではの事をしなくてはいけないので（それが良いとか悪いとかは別）。 それに応じた対策は必要ですねーという感じ。

あと普段自分があまり業務で関わってない機能をどれくらい補完できるかがポイントかなーという気がしました。 他のブログでもある通り結構広く浅く出てきます。cognitoとか全く使ってなかったので面食らった。

ソリューションアーキテクトという名前からやはりちょっとSIっぽい立ち位置の問題なのかなーという気がしました。

例えば私だと

私はそこそこサービスが大きくなってる自社開発向けのAWS使ってるエンジニアです。 そのためプロダクトのコード読んでる時間が多かったり。サードパーティツールの仕様調べてたりすること多いんですよね。そういう人結構多いんじゃ無いかなーと思ってます。

例えばVPCの設定とか最初にやっちゃったら中々変更することないから内容あまり覚えてないんですよね。

一例として試験の重要項目としてネットワークACLとセキュリテイグループの違いとかあるんですが、 ネットワークACLとか一度設定したら変更した事とか記憶になかったんです。セキュリティグループは変更多いですが。 といった事が色々。

勉強して良かった事とそうでもなかった事

  • EBSとかS3あたりは「まあなんとなくこんな感じで動くでしょ」って感じでやってた事がはっきりして良かった
  • EFS,ストレージゲートウェイとかオンプレ環境からのマイグレーションサービス系は単純に面白かった
  • RDSのスケールアウトとかロードバランサー置いてsslオフロードしてオートスケール してとか。その辺web三段構成のスケーラビリティ確保みたいなところは実運用に慣れてれば大した問題は出てこないと思います

という事で以下は勉強の記録です

参考書情報

通称黒本

これが一番役に立ったなーという印象。 主要機能の試験に出やすいところがしっかりまとまってます。 ストレージ周りとVPC周りはほぼ暗記するつもりでいていい気がします。

一番新しい参考書

受験1週間前くらいに出てちょっと面食らいました。

で、内容としては AWSの雰囲気を掴むには凄くいいのだけど内容が流石に薄いという印象です。

どの本もそうですが、 但し書きとして「公式ドキュメントをよく読んでください」とありますが。 流石にこれは端折り過ぎかなーという印象です。一方で「これは一応機能としてあるけど、実際はあんま使いませんよ」のような内容は結構良かったです。

試験対策する人が書いたというよりは、 割と実務的な人が書いたなーという印象です。

流石に内容が古いから買わなくていいかなと思います

black belt情報

とりあえずこんな感じで検索して出てきたslideを読む。

www.google.com

各機能の細かいところをどこら辺まで追う必要があるのかが難しいのですが、 少なくとも知らない機能をノートにまとめて行く。くらいはした方がいいと思います。 DynamoDBのグローバルテーブルとかDAXとかなんとなく知ってるけど使ってない。みたいな事が多かったです。

私が主に読んだのは

  • EBS
  • S3
  • EFS
  • VPC
  • RDS
  • Redshift
  • ElastiCache

あたりかなーと。ストレージ周りは結構しっかりおさらいしました。 基本的な使い方は知ってましたが、知らない機能を保管する意味で良かったです。

その他

最低限の学習環境はとりあえず用意した方がいいかなーと思います。 そこらへんに転がってるノート使ってもいいですが、 私はこれくらい揃えてちょうど良かったなと。

ルーズリーフを用意します

これに参考書の問題をひたすらやります

見出しを用意します

VPC, EBS, S3みたいな感じで分けておいて知らない機能を書いていきます

紙は多めに用意します

ボールペンでぐちゃぐちゃと汚く書くので多めに必要だと思います

多色ボールペンを用意して参考書に線を引きまくる（って事でリセールは気にしない）丸付けにも便利です

意味があるのかわからないけどなんとなく線を引きました、 そのため中古で売ることは出来ないです。

移動中も勉強するならペンを細いペンケースに入れておくと便利です

結果一発で合格しました

良かった良かった。

とにかく範囲が広いのがしんどいなーと思いました。 あとはテクニックとして消去法が重要だと思いました。 DynamoDBとRDSどっちでもできるような回答に対して「まあその用件ならこっちはあまり向いてないかな（一応オプションで出来る）」という判断が求められるのも結構あるので、 そこは自然な実装に寄せる考え方が必要かなーと思います（あまり深読みしない）。

という事で何かの参考になればと思います！

次はプロフェッショナル目指してみようかなと思ってます！

s3にhive形式で送信したい時の設定

fluentd td-agent

aggregator nodeとかでs3でhive形式にしたい（athenaで使いたい時）時の最後のメモ

   <store>
      @type s3
      @id s3_nginx_json
      s3_bucket 私のバケット
      s3_region ap-northeast-1
      path nginx/${tag_parts[n]}/dt=%Y-%m-%d-%H/
      s3_object_key_format %{path}%{time_slice}_%{index}.%{file_extension}
      buffer_path /var/log/td-agent/buffer/s3/nginx/${tag_parts[n]}/
      buffer_chunk_limit 128m
      output_tag false
      output_time false
      flush_interval 10m
      time_slice_format %M
    </store>

fluentdのパラメーターとプラグインメモ

WIP fluentd td-agent

パラメータ

@id

kakakakakku.hatenablog.com

qiita.com

plugin_idに名前をつけられる。mackerelとかにメトリック送りたい時にオブジェクトidだと不便なので名前つけとくといい。

プラグイン

forestプラグイン

Fluentd v0.14 では fluent-plugin-forest が不要な話 - Usual Software Engineer

s3に送る時とかにプレースホルダで動的にパスを変えたかったりする場合に使うもの。 0.14からはcoreに入って不要なプラグインとして記述する必要は無い様子

EC2のインスタンスプロファイルとIAMロールの実務上の違い

aws ec2 iam 備忘録

毎度おなじみのクラスメソットさんがわかりやすい dev.classmethod.jp

インスタンスプロファイルってなに？

インスタンスプロファイルは IAM ロールのコンテナであり、
インスタンスの起動時に EC2 インスタンスにロール情報を渡すために使用できます。

参考URL http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html

書いてある通り、IAMRoleを納めるための容器であり、EC2にアタッチする時に必要なコネクターの役割をします。

引用元に書いてある通りなんですが、 インスタンスプロファイルとiamロールが

  • 1対Nになってる
  • EC2に紐づけられるのはIAMロールそのものじゃなくてインスタンスプロファイル

サンプルで記載されているCloudformationのEC2立ち上げの設定を読んでみると

IamInstanceProfile: !Ref myInstanceProfile

iamロールを付与してるわけじゃなくてインスタンスプロファイルを指定してる

実務上意識することってどういうことなのかと勝手に解釈

該当記事を読んだ感じだとaws cliやcloudformationでインスタンスを立ち上げる時に理解していないとハマるってことかと思う。 コンソールから立ち上げるとIAMロールをそのままアタッチしてるように見えるけどそうではない。

繰り返しになるが EC2にアタッチするのはIAMロールではなくて「IAMロールを付与したインスタンスプロファイルである」ってことかと。

ansible-playbookコマンドでsshがタイムアウトするからとりあえずtimeout時間を伸ばしたい

ansible 
--timeout=300

オプションつけるだでとりあえずタイムアウト時間は伸ばせる

ansible-playbook  -i development-hosts site.yml --timeout=300

こんな感じ