AWS

24時間でAWS認定ソリューションアーキテクト(アソシエイト)に合格するためのプロセス

以下の記事で、AWS認定ソリューションアーキテクト(アソシエイト)について試験概要を調べてみました。

AWS認定ソリューションアーキテクト(アソシエイト)を取得するメリットAWS を使い始めて約 7 年。 AWS の存在を知ったのは 10 年ほど前ですが、その頃は日本で「クラウド」という言葉が少しずつ...

早速、受験のために勉強を始めてみましたが、せっかくなので試験までの過程をまとめておきたいと思います。

使用する参考書は「AWS認定資格試験テキスト」の 1 冊のみとし、練習問題が足りないようでしたら別の方法も検討したいと思います。

この本についても何度か読み直すことを想定していて、今のところ以下のような利用方法を考えています。

1回目

全体の文章を読み進める
章末の練習問題を解く

2回目

各章のポイント欄を再度チェックする
章末の練習問題を解く

3回目

本の最後にある模擬試験を繰り返し行う

では早速、1 回目のスタートです。

勉強時間は、この記事を書くことも含めて 1 日 1 時間以内を目標にしています。試験勉強は省エネで、普段の仕事で培った知識をベースに試験に挑めたらと思います。

試験勉強(1日目)

試験の概要を一通り読んだら、次の章で早速「VPC」の設計の話が出てきました。

なるほど、これはいきなり大きなテーマですね。

VPCの設計

個人で運用している AWS アカウントもそうですが、AWS を触り始めて最初の 5 年間くらいはサブネットの設計はしていませんでした。

EC2 や RDS など、セキュリティグループだけでアクセス制御をしても問題ないと思うのですが、以前 AWS で以下のような構成図を見かけた記憶があります。
(AWS公式の資料があったハズなんだけど見つからない)

外部からアクセスの必要のないリソースは、なるべくプライベートな領域で管理するというセキュアな構成ですが、1 つコスト面でのデメリットもあるのですよね。

それはプライベートな領域の EC2 インスタンスの外部へのアクセスです。

OS が AmazonLinux なら yum でパッケージの更新をするでしょうし、外部へ出ていけないのは何かと不便です。

そこで NAT Gateway や NAT インスタンスの出番なのですが、どちらも少なからず別費用が掛かってきます。

セキュリティグループとサブネット間のアクセスを制御する「ネットワークACL」の大きな違いは、応答トラフィックを無条件で許可するか(ステートフル)、許可しないか(ステートレス)です。

当然、後者の方が明示的に許可するパケットを定義しないといけないのでセキュアです。

試験問題がどうかわかりませんが、コストとセキュリティを天秤に掛けると、やはりセキュリティ重視なのは間違いないでしょう。

でも、コストをなるべく抑えたいという企業に説明して納得してもらうのは意外に面倒なんですよね。個人で運営している AWS もなるべく費用は掛けたくないですし。

踏み台サーバや NAT インスタンスは、EC2 を t2.nano で構築すれば費用を最小限に抑えられますが、それでも月に 1500 円程度は発生しちゃいますからね。

どちらにしても、試験勉強のために VPC の設計は柔軟にできるようになっておきたいですね。

試験勉強(2日目)

VPC の次の章は「CloudFront」と「Route53」がテーマです。

ここはサラっといけそうなので、この日の内に次の「EC2」「ELB」「ECS」くらいまでは読んでおきたいところ。

最後の「Lambda」はあまり経験がないので、ちょっと時間を掛けたいと思います。

CloudFront

CloudFront は画像や css などの静的ファイルに対して CDN として使ったことがありますが、動画のストリーミングで利用したことはないです。

また、CloudFront の裏側は S3 や ELB を設定する機会が大半だったのですが、オンプレも指定できるのは知りませんでした。

まあ、用途としては一緒なので、CloudFront については使用経験があれば大丈夫そうです。

キャッシュクリアが面倒だった記憶があるのですが、最近は運用もしやすくなってるのかな?

Route53

Route53 は仕事ではそんなに頻繁に利用するサービスではないのですが、個人サイトは 1 つの t2.micro で 10 個くらい運用しているのでお世話になっているサービスです。

A レコードでは転送先に ELB や CloudFront を指定する機会が多いと思いますが、個人サイトで Let’s Encrypt を使っている都合上、EIP を直接しているのは内緒で・・・。まあ、意図して設定している分には問題ないでしょう。

あと、Route53 の機能でアクセス元によって挙動を制御できるのですが、過去に海外からのアクセスが邪魔で弾いたところ、GoogleBot も弾いてしまうというミスをした苦い思い出があります。仕事だったらむやみにやらないでしょうが、ともかく個人サイトで良かった。

Route53のルーティングポリシーでGooglebotを弾いてしまいましたあるサイトの A レコードを編集していたのですが、海外からの邪魔なアクセスが多いサイトだったこともあり、何か楽に弾く方法はないかなっと調...

業務で使うとしたらフェイルオーバールーティングポリシーが多いかなと思っていましたが、加重ルーティングポリシーがあるのは初めて知りました。

AB テストも AWS を使うと楽になりますね。

EC2

EC2 もこれまでに単体では多く利用してきました。

ただ、スポットインスタンスは知らなかったので覚えておく必要がありそうです。

書籍では、「1 時間で 0.129USD の m4.large インスタンスに対して、0.95USD でスポット入札に成功すると」というような説明がありましたが、これだと高額になってしまうので、0.095USD でしょうか?

書籍ページの正誤情報に記載がなかったので、読み直す時にまた考えたいと思います。

ここまで、書籍に掲載されている練習問題はパーフェクト正解なので、このまま順調に進めていきたいですね。

ELB

ELB は最近でこそ ALB を使っていますが、それまでは CLB を使う場面が多くありました。

というのも、通常の Web サイトであれば ALB を使う必要性がそれほどなかったからです。

しかし、API やマイクロサービスの需要が高まってくると、URL パスでサーバを振り分けたいケースが出てきます。

また、料金は意識していませんでしたが、ALB の方がコストが安いようですね。

ちなみに NLB の存在は知っていて、実際に使用したことがあります。

どうしても IP アドレスでアクセスしたいという外部からの要望があり、一旦 NLB で受けることにしたことがありました。

EC2 の EIP で受けてもいいですが、冗長化は重要ですし、プライベートな環境に Web サーバを置いている場合は ELB を経由させないといけないですしね。

あまり NLB を使う機会はないですが、そういった機会に恵まれたのはラッキーでしょうか。

試験問題としては、練習問題にあったように ELB の種類ごとの特徴もありますが、どちらかというと Auto Scaling を活用したスケールアウトの方が重要になってくるかもしれませんね。

ECS

ECS は実際に使ったことがない人にはピンとこないサービスかもしれません。

私も、Docker を初めて使用したのがちょうど 1 年くらい前と、わりと最近のことです。

しかしこの 1 年で、ローカル開発環境は docker-compose で各種コンテナを管理し、AWS 上では ECS(Fargate)のサービスを利用してきました。

実際に ECS を使って本番運用をしていますから、重要なポイントは抑えれていると思っています。

コンテナイメージも ECR で管理していましたし、これから勉強する EKS を除けば大体の役割は把握できているハズです。

といいつつ、実はこの章の練習問題で初めてミスを犯しました・・・。

選択肢の中に誤った回答が見つからないなっと思い、消去法で答えを探していたのですが、「クラスター用に EC2 インスタンスが必要になる」という選択肢を誤りだと最終決定しちゃったのです。

それは、Fargate の場合は EC2 はいらないでしょっと思ったからで、これ以外の選択肢は全部間違ってないよねって認識でした。

まあ、ECS は EC2 か Fargate を選択できることから、Fargate まで含めた問題であれば EC2 は必須ではないと思うのですが(実際に書籍に解説もありますし)、それよりも明らかに間違った選択肢が存在していたのです・・・。

それは、「クラスタ上で稼働するタスクの定義は、Cluster Definition で定義する」というものです。

実際には「Task Definition」で定義するのですが、選択肢をサラっと読んでしまい間違いに気付けていなかったのです。

この先、問題や選択肢は気を引き締めて読み進めていかないといけないなっと思わせてくれました。早いタイミングで、ケアレスミスをして良かったかもしれません。

Lambda

書籍を読んでみた感じ、イメージはほぼほぼ一致していたので、Lambda の役割としては問題なさそうです。

ただ、まともに触ったことがないので、書籍で書かれていた以下のケースは実際に試しておきたいところです。

・S3 へのファイルアップロードをトリガーにしたプログラム実行
・https アクセスをトリガーにしたプログラム実行

Lambda Runtime API を利用すれば PHP でも定義できるようですが、試すだけなら Python とか Node.js の方が早そうですね。

ちなみに Lambda は、一定時間プログラムの実行がないと次回アクセス時に再度プログラムを起動する必要があるので、Java など起動に時間が掛かるプログラムを運用する場合は、即座にレスポンスが返せないなど問題も出てきます。

これは実際に聞いたことがあるノウハウですが、書籍にも同じことが書かれていたので、間違ってはいなかったということですね。

試験勉強(3日目)

ここまで、試験勉強は毎日 1 時間程度。

書籍を読みながら練習問題を問いて、気になったことや自分の経験をこの記事に書きだす。

今後もこの流れで進めていけるなら、それほど時間を掛けずに書籍を完読できそうです。

今回は運用のお話。

「CloudWatch」と「CloudTrail」がメインのようですが、CloudWatch はちょっとした監視にしか使ったことがありません。

また、CloudTrail は聞いたことはあるけど使ったことはない。

特にログ監視は CloudWatch では限界があるので、Mackerel(マカレル)や DataDog(データドッグ)に転送することが多いですよね。

CloudWatch

CloudWatch で使用したことがあるのは、EC2 や RDS などのメトリクスをグラフ化して視覚的にわかりやすくすること。

そしてリソースの管理と監視です。

CPU 使用率が 80% を超えたら担当者にメールをするとかが多かったでしょうか。

ただ EC2 のリソースについては、デフォルトで用意されているメトリクスだと物足りなく、痒いところに手が届かないサービスでもあります。

なので以前、以下のように独自のカスタムメトリクスを作ったこともあります。

RDSやElastiCache(Redis)の死活監視をCloudWatchで管理AWS の監視系サービスである CloudWatch には、残念ながら RDS(MySQL)や ElastiCache(Redis)の死...

CloudWatch Event は cron のように時間をトリガーにした操作を管理することができますし、AWS のリソースの状態を検知してイベントトリガーでも何かの作業を行うことができます。

といっても、それほど多用したことはないので、事例などをチェックしておきたいですね。

CloudWatch Logs は自分でエージェントを設定したことがないので、Nginx のアクセスログや Web アプリのアプリケーションログを CloudWatch に流すように試しておこうと思います。

CloudWatch までのログ転送なら料金を気にしなくても大丈夫かな?って、コスト管理も重要そうなので覚えておきたいですね。

CloudTrail

冒頭でも書いた通り使ったことのないサービスですので、どのようなログが取得できるか確認してみます。

・管理イベント
・データイベント

管理イベントは、「マネジメントコンソールへのログイン」や「EC2インスタンスの作成」などサービスの操作、データイベントは「S3のバケット上のデータ操作」など各サービスのデータの操作となるようです。

エンジニアだとあまり意識するサービスではないですが、プロジェクト担当者やインフラ・セキュリティ担当者の人は意識する機会が多いでしょうか。

どちらにしても大きな問題が起こった後では遅いので、デフォルトではログの取得がオフになっているデータイベントもログ取得できるようにしておくといいかもしれませんね。

試験勉強(4日目)

書籍の目次を見直したら、8 章、そして 10 章以降は未知の領域のようでペースが落ちそうな気がしてきました。

モチベーションどうたらと言ってられないので、とにかく毎日少しずつやるのみです。

今回はストレージのお話。

「EBS」「S3」は馴染みがあり、「Glacier」はどんなものか知っている程度。

逆に「EFS」「Storage Gateway」は初耳です。

EFS は Elastic File System って感じで、NFS の AWS サービスなのかな?っと想像はできますが。

EBS

普段から当たり前のように使っている EBS ですが、ブロックストレージという概念を意識したことはありませんでした。

最初の頃は、EC2 にアタッチして利用するというイメージがわきにくく、EC2 のハードディスクという位置付けで勝手に解釈していました。

そっちの方が正しくないとしてもイメージはしやすいですよね。

また、1 秒間に処理できる I/O の単位で IOPS というものがあるのも初めて知りました。

Input Output Per Second でしょうか?

普段はデフォルトの「汎用SSD」で十分ですが、用途によっては「プロビジョンドIOPS SSD」など他のボリュームタイプもあります。

I/O がネックなサービスの場合は「プロビジョンドIOPS SSD」を試してみる価値はありそうですね。

あと、ディスク容量の拡張についても触れられていましたが、AWS のコンソールで容量の拡張はできるものの、Amazon Linux に反映するには Linux 側でファイルシステムのコマンドを実行する必要があります。

昔、8GB で設定してしまった EBS を 30GB にしたくて試行錯誤した記憶があります。

まあ、mkfs とかすればいいだけの話なのですが、滅多にやらないと忘れちゃいますよね。

EFS

実際に EFS は使ったことがないですが、イメージは NFS と同じです。

ただ、各 AZ からどのようにアクセスが最適化されているか、I/O やスループットを意識した設定があるなど、いくつか覚えておくべきポイントがあります。

実運用で使用する機会があればいいですが、そうでない場合は試験勉強と割り切って以下を覚えておくのがいいですね。

パフォーマンスモード

・汎用パフォーマンスモード
・最大I/Oパフォーマンスモード

スループットモード

・バーストスループットモード
・プロビジョニングスループットモード

パフォーマンスモードのポイントは以下の通り。

CloudWatch の NFS のメトリクスで「PercentIOLimit」を確認して、長時間 80~100% で推移しているなら「最大I/Oパフォーマンスモード」に切り替えた方がいい

スループットモードのポイントは以下の通り。

CloudWatch の NFS のメトリクスで「BurstCreditBalance」を確認して、クレジットバランスが枯渇している場合は「プロビジョニングスループットモード」に切り替えた方がいい

あとは模擬試験などでカバーしていくしかないですね。

試験勉強(5日目)

ストレージに対して意欲がわかなくて、昨日は途中までで断念。

今日は残りの「S3」と「Glacier」をササっと済ませてしまいます。

S3

私の経験上、S3 は静的ファイルの置き場所としての用途が多く、Web アプリからの操作や aws cli などコマンドラインからも扱いやすいことから、ファイルアップロードが絡むアプリでは重宝していました。

しかし、同じサーバ上にファイルがあるかのように使えないかと考える人はいるもので、実際に S3 のバケットが Linux などの OS にマウントできる S3FS が話題となっていたのが懐かしいですね。

ただ 3SFS はちょっと不安定なところもあり、Goofys の方が安定して使えます。

AWSのEC2にgoofysを入れてS3をマウントする過去に携わったプロジェクトで、S3FS の通信状態が悪い時があるので、アプリ側のプログラムを AWS SDK を使ったものに置き換えてい...

フロントエンドが絡む画面のある Web アプリではそれほど気にすることないですが、頻繁にアップロードを受け付けないようなアプリの場合は、署名付き URL(Pre Signed URL)を使うとサーバの負荷も軽減できていいですね。

S3 にファイルがアップロードされたら、CloudWatch Event などで別の処理を行うというイメージです。

URL の有効期限も一時的に限定できるのでセキュアでもあります。

Glacier は S3 のページでも紹介されていたので、Storage Gateway と合わせてサラっと読み進めます。

この章も練習問題は全問正解ですが、やはりポイント部分は後から復習が必要だなっと感じています。

試験勉強(6日目)

ストレージの次はデータベースです。

データベースというと RDB のイメージですが、NoSQL 系のものも含めて章立てがされています。

AWS で RDS を利用する前までは自前で MySQL サーバを構築していましたが、RDS の便利さに慣れるとやめられませんね。

また、MemCache 系の用途で Redis も長年使ってきました。memcached よりも運用がしやすくコマンドライン操作が素敵です。

ただ、AWS ではそれ以外のデータベースサービスがあって、実は Redshift も DynamoDB も使ったことがありません。

名前はよく聞くのですが、無理に使うこともないと思ってどんなものか調べもしませんでしたので、今回はよい機会かなと思います。

RDS

RDS は前回調べたストレージの中で EBS を使用します。デフォルトでは SSD になります。

実際に使っていて便利なのはリードレプリカが簡単に増やせることと、フェイルオーバーが楽にできることですね。

ただ、実運用で障害が発生することは稀なので、リリース前テストでしかフェイルオーバーも試さないことは多いですよね。

いざデータベースで障害が起こっても焦らないように慣れておきたいところです。

また最近は、Aurora も運用ノウハウが確立されてきて利用率も上がってきました。

マスタの障害児にリードレプリカが自動でマスタに昇格してくれるのはうれしいですね。

Redshift

RDS と同じ RDB でも、用途が集計処理に特化しているデータベースです。

Aurora のようにクラスタ構成になっていて、以下のノードの集合が大きな特徴です。

・リーダーノード(単一)
・コンピュートノード(複数)

リーダーノードはクエリを受け付けて、クエリの解析や実行プランを作成する役割、コンピュートノードは実行クエリを処理するノードとなっています。

複数のコンピュートノードをまたがずに処理を完結するような分散構成を作れるかがポイントということですが、この文章だけではさっぱりイメージがわきません。

実際にサービスを使ってみて、1 回くらいクエリを投げておく必要があるかもしれませんね。

ちょうど、「AWS再入門ブログリレー Amazon Redshift編」が投稿されていたので、こちらも読んでおきます。

試験勉強(7日目)

Redshift のイメージがなかなかつかめなくて、データベースは合計で 2 日(2時間)の勉強となってしまいました。

知らない機能は文章だけ読んでも理解できないと思うので、実際に触れてみるのがいいのでしょうが、模擬試験の内容を確認してから検討してみます。

DynamoDB

名前はよく聞く「DynamoDB」、ただどのような機能を持ったサービスか全く知りませんでした。

私が良く使う Redis(ElastiCache)のように、Key-Value 型のデータベースということですが、何が違うのでしょうか。

そこを理解していきますが、書籍の内容だけではイメージがわきませんでした。

スループットキャパシティがある(読み取りと書き込みに使用する)
データパーティショニング
プライマリーキーとインデックス(複合キーも可能)

唯一イメージできたのは、プライマリーキーがパーティションキー単独やパーティションキーとソートキーを合わせた複合で設定できること。

結局、実際に使ってみないとわからないですね。

久しぶりに書籍の練習問題も間違えました・・・。

ElasctiCache

ElasctiCache が Redis に対応するまでは、独自に Redis サーバを使っていたので、Redis の基本は分かっているつもりです。

逆に Memcached はコマンドラインから telnet などを活用しないと扱いにくかったため、バッチ処理がしやすい Redis は感動モノでした。

AmazonLinuxにRedisクライアントをインストールするAWS で ElastiCache(Redis)を使おうと思って、そこへ接続するために Redis クライアントをインストールしました。...

あまり Memcached について調べたくはないのですが、ElastiCache でできることとできないことくらいは知っておくといいですね。

Redis については、クラスタ化する場合としない場合の違いを押さえておくといいかもしれません。

書籍に機能の比較表があるのでチェックしておきましょう。

試験勉強(8日目)

集中力が上がってきた時に限って、猫が甘えてきて邪魔されます。

猫に悪気はないので難しいですね。

さて、今回はセキュリティとアイデンティティがテーマ。

サイトの SSL のサーバ証明書を作成する ACM(Amazon Certificate Manager)や KMS はシンプルですが、IAM(Identity and Access Management)は奥が深そうです。

特に個人で管理している AWS では IAM の設定をまともにしていないので、これを機会に組織で使う場合のケースについて意識を高めたいと思います。

まあ、AWS アカウントを使うにしても、MFA(Multi-Factor Authentication)で二段階認証を設定しておくことは必須ですけどね。

あの 2 箇所のコード入力の説明がわかりにくくて最初は何度も「アクセス権限がありません」で登録できなかったですが・・・。

IAM

IAM ユーザは AWS を利用するユーザ向けに発行するアカウントのこと。

企業では共通アカウントではなく、個別にアカウントを発行してもらって認証するケースが多いと思います。

よって、AWS の各サービスの中で、設定できる権限と設定できない権限があると思います。

中途半端に権限を絞られてるのに、全部設定しておいてって感じで作業を振られて何度も苦労したことがありますので、IAM を設定する人は責任を持って権限管理して欲しいですね。

逆に、IAM を勉強する以上、自分も詳しくならないといけないですが。

IAM ポリシーは「どのサービス(Action)」の「どういった機能や範囲(Resource)」を「許可・拒否(Effect)」するという、3 つの大きなルールに基づいて権限設定する。

ポリシーは AWS で用意されているものがあるので、基本的にはその中から選択して IAM ユーザやグループに割り当て、どうしても細かく付与したい権限をカスタマー管理ポリシーを使うのが一般的なようです。

また、IAM ユーザは複数のグループに所属できるので、権限は IAM グループに設定して、IAM ユーザに直接権限を振るのではなく、必要なグループに所属させるのがポイントです。

EC2 の場合、IAM ロールは付与できるタイミングが限定されるので、最初の設計が崩れると面倒になりそうです。

ロールによって、アクセスキーやアクセスシークレットを利用しなくてもよくなるのはセキュアでいいですね。

ACM

ACM は無料で SSL のサーバ証明書が発行できるサービスです。

ただ、証明書は ELB や CloudFront など設定できるサービスが限定されていて、EC2 に設定することはできません。

よって、ELB を通さない場合は Let’s Encrypt などで証明書を取得して、EC2 で https(443)のプロトコルを許可しないといけないです。

まあ、そんなケースは稀かもしれませんが、Web サーバ側でクライアント証明書も利用したい場合など、必ずしも ACM で ELB までの経路を暗号化して、EC2 までは http というわけにもいかないですね。

あとは、EC2 で複数のサイトを運営している場合、ELB を通していると 443 番ポートに ACM の証明書を紐付けることができるのは 1 サイトのみとなってしまいます。

実際のビジネスの中でそのようなケースは少ないと思いますが、個人であれこれしていると融通が利かない部分があります。

試験勉強(9日目)

昨日は試験勉強をサボったため、1 日空いての続きとなります。

今回は「アプリケーションサービス」、AWS の SaaS サービスです。

ここでは「SQS」「SNS」「SES」「SWF」「Step Functions」が対象となります。

SNS, SQS はマイクロサービスでは常連ですね。SES もメールやプッシュ通知などで使われます。

ただ、SWF や Step Functions は初めて聞きました。どんなサービスなのでしょうか。

SQS

SQS には以下のキューがありますが、順序保証されている FIFO キューの方が今は一般的。

FIFOキュー
Standardキュー

ただ、1 秒間に捌けるトランザクションキューの数が、前者は 300 なのに対し後者は 3000 となっています。

これは FIFO(First in First out)が順序保証をしているため、処理的な負荷が大きいからです。

ただ、順序保証されていることと、重複メッセージをほぼ避けられることから、現在は FIFO がデフォルトとなっています。

あとは、ポーリングの種類、可視性タイムアウト、デッドレターキューを覚えておけばいいでしょうか。

また、メッセージの最大サイズは 256KB となっています。

SWFとStep Functions

SWF の WF は「ワークフロー」のことでした。

AWS の場合、以下のサービスが用意されています。

SWF(Amazon Simple Workflow)
Step Functions

なるほど、それぞれ別のワークフローサービスだったのですね。

Step Functions は内部的に SWF を利用しているので、SWF の方が高機能ですが複雑です。

そこで、機能はフルではないけど、可視化して編集できる機能が複雑さを緩和できるため、Step Functions の方がオススメのようです。

SNSとSES

どちらかというと、最近は SQS とセットで使うことの多い SNS ですが、もちろん SES とも親和性が高いです。

だからこそ、同じ章にまとめられているのでしょうが。

SNS はパブリッシャーとサブスクライバーを持ち、プロトコルに関係なく通知を受信します。

それをサブスクライバーが各機能に対して処理実行を行います。

Google のクラウドサービスである、GCP の Pub/Sub と同じ位置付けですね。

SES は高機能かつセキュアなメール配信サービスですが、メール配信を取り扱うシステムを使わないとなかなか使う機会もありませんよね。

以前、SSL のサーバ証明書の認証確認のために、レジストラの WHOIS に登録されたメールを受信するために SES を利用したことがありました。

受信したメールを S3 に出力してメール本文の URL にアクセスしたのを今でも覚えています。

SNS や SQS については以前、コマンドラインからの操作をまとめていました。

AWSクライアントを使ってLocalStack上のSNSやSQSに対してコマンドライン操作する以前まで、AWS の SNS や SQS のサービスを利用するには AWS の契約が必須だと思っていたのですが、LocalStack の...

試験勉強(10日目)

さて、3 日間サボりました。今回は「開発者ツール」と「プロビジョニングサービス」について。

AWS で開発者ツールと言われてもピンときませんが、以下のようなサービスのことを指しているようです。

CodeCommit
CodeBuild
CodeDeploy
CodePipeline

多くの現場では CI のツールを活用されていると思いますが、AWS の Code シリーズで代用できるものもあるかもしれませんね。

個人的には、数年前に CodeDeploy が発表された時に Jenkins 不要になるかなと期待しましたが、まだまだ Jenkins や CircleCI を使う機会の方が圧倒的に多いです。

プロビジョニングサービスは Chef や Ansible のような環境構築の自動化を提供するものです。

AWS では CloudFormation や Elastic Beanstalk が有名ですが、実際に使ってみないとメリット・デメリットがわかりません。

ここで勉強していきたいと思います。

CodeCommit

CodeCommit は Git リポジトリを提供するマネージドサービス。

企業では GitHub Enterprise を採用しているところも多いと思いますが、Backlog などの SaaS サービスを利用している企業ではそこの Git リポジトリを使っている場合もあるでしょう。

小規模であれば通常の GitHub や BitBucket のケースもあるでしょうし、ソース管理自体は Git を採用しているところが大半でしょうね。

CodeCommit もそのうちの 1 つですが、CodeCommit に対するイベントをトリガーに他の AWS のサービスを操作できるのが特徴のようです。

CodeBuild

CodeBuild は Jenkins のようにソースコードをビルドしたり、テスト(ユニットテスト、シナリオテスト)を定期的に実行するサービスを担当します。

確かに Jenkins のためだけに EC2 を用意するのもリソースが必要になりますし、CodeCommit 以外に Git や BitBucket からソースコードを取得できるなら CodeBuild も選択肢としてはアリかもしれません。

設定が yaml ファイルで定義できるのも楽そうですね。イメージ的には CircleCI に近い?

また、従量課金(ビルドに掛かった時間)なので、Jenkins を EC2 で立てておくよりもコストパフォーマンスが良さそうです。

Java や Kotlin など肥大化してくると時間が掛かるビルドですが、スケールアップも気軽にできるので、スペック調整でコストを抑えることもできますね。

CodeDeploy

CodeDeploy はモジュールを EC2 など各種サーバへ配布するサービスです。

Jenkins でもできますが、ロードバランサが絡む場合は手間が掛かります。

PHP のようなスクリプト言語なら中間コードのキャッシュを気にする程度でいいですが、アプリケーションサーバの再起動が伴う場合はロードバランサからの切り離しが必須です。

この辺を意識しないで、負荷を考慮しながらデプロイできるのはメリットが大きいですね。

まあ、コンテナサービスが主流になって ECS や EKS の利用が増えてきているので、ちょっと出番は少なくなるかもしれませんが。

CodePipeline

CodePipeline について多くのことを書く必要はなさそうですが、CodeCommit、CodeBuild、CodeDeploy を束ねて処理させることができるサービスです。

途中で承認フローを挟んだり、ソースの取得元を CodeCommit ではなく Git にしたり、ビルドを CodeBuild ではなく Jenkins に置き換えたりもできます。

Elastic Beanstalk

Elastic Beanstalk は定番のインフラ構成を自動構築するサービスとなっています。

よって、複雑な構成のものは定義できないですが、一般的な構成は簡単に素早く用意することができます。

一般的な構成例は以下の通り。

・Webサーバ(ELB + Auto Scaling + EC2)
・Batchサーバ(SQS + Auto Scaling + EC2)

この Elastic Beanstalk はマネジメントコンソールから操作しますが、AWS CLI や EB CLI などのクライアントツールにも対応しているので、頻繁に構築するものはコマンドで用意しておくと運用が楽になります。

また、アプリケーションのデプロイもサポートしていて、CodeDeploy のようにいくつかのデプロイ方式が用意されています。

私は実際に、「Immutableデプロイ」のプロジェクトを少し運用した経験があります。

これは以下の順番でデプロイ作業を行います。例えば、3 台の EC2 にデプロイすることを想定してみます。

・EC2 インスタンスを新規に 1 つ作成しデプロイする
・ELB にアタッチされたら、残りの 2 台も同様に構築する
・3 台とも ELB にアタッチされたら、既存の 3 台の EC2 インスタンスを停止・削除する

一番安全な方法ではありますが、All at Once デプロイや Rolling デプロイなどに比べると時間が掛かるというデメリットもあります。

OpsWorks

OpsWorks は初めて聞くサービスでしたが、Chef を利用した構成管理サービスとのことです。

Chef のサーバやクライアントを用意しなくても OpsWorks が代わりをしてくれます。

対応している方式は以下の 2 つ。

・Chef Client ローカル方式
・Chaf Server/Client 方式

CloudFormation

CloudFormation は AWS リソースを自動構築するためのサービス。

テンプレートファイルは yaml か json で定義しますが、これはある程度、構築や運用をしていかないと覚えられないでしょうね。

書籍に yaml のサンプルと解説が掲載されていますが、さすがにじっくり読む気にはなりませんでした。

この中身が試験問題に出たら諦めます(笑)

今後、CloudFormation を活用する機会があるなら頑張って覚えますが。

Terraform もどうなるかわかりませんが、どうせなら Terraform をマスターしていきたいですね。

練習問題は正解したので、概念的な問題が出ればなんとかなるでしょうか。

試験勉強(11日目)

またしても 1 日、試験勉強をサボってしまいました。

一応、残りの章をサラっとは読んでみたのですが、「分析サービス」はあまり縁がなく意欲がわかなかったのです。

ただ、Kinesis は名前を何度か聞いたことのあるサービスなので、どういった分析ツールがあるのかチェックだけしておきましょう。

また、その次の章の「AWSのアーキテクチャ設計」は重要そうなので要チェックです。

EMR

EMR は分散処理フレームワークのこと。

分散処理って CPU のコア数にも依存しますし、どうしても並列に捌きたいバッチに利用するイメージです。

そんなので解釈あってるのかな?

分散処理基盤と分散処理アプリケーション基盤の 2 つから構成されているようです。

また、アーキテクチャは以下の 3 つから成り立っています。

・マスターノード
・コアノード
・タスクノード

分散処理基盤は、大きく以下の機能を持っています。

・分散処理に必要な EC2 の調達や廃棄などのリソース調整
・S3 を分散処理に扱いやすいストレージとして扱う機能

分散処理基盤は、その動作の特性からスポットインスタンスと相性が良い。

ETLツール

「ETLツール」は、データソースからのデータの抽出・変換・投入の役割をする。

関連サービスとして、以下の 3 つが用意されています。

・Data Pipeline
・Glue
・Kinesis

Kinesis は AWS が提供するストリーミング処理プラットフォーム。

Kinesis のイメージとしては動画ですが、これは Video Streams という 1 機能であり、実際には他に 3 種類の機能があります。

・Data Stream
・Data Firehose
・Video Streams
・Data Analytics

試験対策としては、Data Stream の機能を把握しておくといいようです。

Data Pipeline はデータ処理やデータ移動を支援するサービスで、ビジュアル操作で設定が可能となっています。

試験勉強(12日目)

締めくくりは「AWSのアーキテクチャ設計」となっています。

最初の「VPN設計」とも繋がる部分がありそうですが、まずは読み進めていきましょう。

AWSのアーキテクチャ設計

AWS の試験の中で最も割合が多いのが「回復性の高いアーキテクチャを設計する」項目だそうです。

そこで、AWS Well-Architected フレームワークを意識しておく必要があります。

アーキテクチャのポイントで、覚えておくべき構成要素は下記の 5 つです。

・復旧手順のテスト
・障害からの自動復旧
・スケーラブルなシステム
・キャパシティ推測が不要であること
・変更管理の自動化

AWS は障害の発生をシミュレーションしやすく、障害復旧の自動化や復旧のテストがしやすい特徴があります。

と言っても、カオスエンジニアリングのような大規模で予測不能なテストのことではなく、想定できる障害試験がしやすいということです。

障害からの自動復旧はこれまでの復習になりますが、以下のようなケースが考えられます。

・CloudWatch を活用したメトリクス監視やアラート検知
・ELBのヘルスチェックによるEC2の制御
・マルチAZ構成によるRDSのスタンバイ構成

スケーラブルというと Auto Scaling が思いつきますが、それ以外にも AWS の多くのサービスはスケールアウトしやすい設計になっています。

また、ElastiCache などの利用により、スケールアウトした個々に依存しそうなものを逃がすこと(ステートレス)もできます。

キャパシティは、スケールアウトとスケールアップのバランスをサービスごとに使い分けることがポイントとなります。

RDS の場合だと、リードレプリカは気軽に増やせるのでスケールアウトで対応して、マスタはスケールアップするなどですね。

パフォーマンスに優れたアーキテクチャ

主にリソース選択について。

例えば、コンピューティングリソースなら以下のようなイメージです。

・インスタンス型のサービスならEC2
・コンテナ型のサービスならECS
・関数型のサービスならLambda

っと書いてて気付きましたが、この章はこれまでの章の総決算ですね。

要点をまとめるよりも、繰り返し読んだ方が良さそうな内容です。

この記事の冒頭で、試験勉強を進めるにあたって、以下のような目標を書きました。

1回目

全体の文章を読み進める
章末の練習問題を解く

2回目

各章のポイント欄を再度チェックする
章末の練習問題を解く

ただ、「各章のポイント欄を再度チェックする」というのは、この「第13章」だけで十分カバーできそうです。

よって、この章を合計で 2 回読み込んでから、各章の練習問題に再チャレンジしたいと思います。

次回は、2 回目の読み込みと練習問題チャレンジを行います。

予定では、その次に模擬試験という流れになりそうです。

3回目

本の最後にある模擬試験を繰り返し行う