AWSのクラウドプラクティショナー
という資格取得に向けて学習中。
復習に見返せるようにメモしていきます。
自分の勉強メモです。過度な期待はしないでください。
AWS認定資格
■ AWS公認資格の種類
AWS認定資格には、役割別認定資格と専門知識認定資格の2つのタイプがあります。
▶︎ 役割別認定資格
役割別の資格は、「基礎・アソシエイト・プロフェッショナル」の3つのレベルに分かれ、
さらに、アソシエイトとプロフェッショナルでは、「アーキテクト・運用・開発者」の3つの
バッジで役割別に知識を証明することになります。
▶︎ 専門知識認定資格
専門知識認定資格としては、「ネットワーキング・ビッグデータ・セキュリティ・
機械学習・Alexaスキルビルダー」があります。これらはクラウドプラクティショナーの資格を
持っていることが受験資格の一つであり、特定の分野に特化した資格になります。
AWS認定資格は ３年ごとに更新する必要があり、再認定試験を３年ごとに更新するか、
役割別資格の場合は上位レベルの資格を取得する必要があります。
下記の画像は、AWS公認資格の種類一覧になります。
引用元：AWS認定公式
■ クラウドプラクティショナー
今回は先ずベーシックである、クラウドプラクティショナーの資格に向けて学習していきます。
この資格は、専門知識認定資格の認定試験を受けるための条件とされてます。公式サイトでは、
6ヶ月間の基礎的な AWS クラウドの知識と業界の知識を持っている人とされています。
内容としては、AWSクラウドの知識とスキルを身につけ、全体的な理解を効果的に説明出来る
レベルとなっています。
▶︎ 受験者の概要
この資格では、次の能力がある事を証明出来ます。
⚫️ AWSクラウドとは何か、及びベーシックばなグローバルインフラストラクチャについて
定義出来る。
⚫️ AWSクラウドのベーシックなアーキテクチャ(構造)原理が説明出来る。
⚫️ AWSクラウドの価値提案について説明出来る。
⚫️ AWSプラットフォームの主なサービスと一般的なユースケース※1 について説明出来る。
⚫️ AWSプラットフォームのセキュリティとコンプライアンスのベーシックな側面、
及び共有セキュリティモデルについて説明出来る。
⚫️ AWSクラウドにおけるデプロイと運用の、ベーシックで重要な特徴を説明出来る。
※1 ユースケース
利用者があるシステムを用いて特定の目的を達するまでの、双方の間のやり取りを明確に
定義したもの。 要は、システムの使用例の事。
▶︎ 出題範囲とその比率
| 分野 | 試験における比率 |
|---|---|
| クラウドの概念 | 26% |
| セキュリティ | 25% |
| テクノロジー | 33% |
| 請求と料金 | 16% |
割合は上記の通りとなっていますが、最新の情報は変更される事があるの事があるので
AWS認定の準備ページの「クラウドクラウドプラクティショナー」内のリンクがある、
「AWS認定クラウドプラクティショナー試験ガイド」で確認しておくと良い。
AWSクラウドの概要
■ クラウドとは？
クラウドとは、一言でいうと「ユーザーがインフラやソフトウェアを持たなくても、
インターネットを通じて、コンピューティング（仮想サーバー）、データベース、
ストレージ（ディスク領域）、アプリケーションをはじめとした、様々なITリソースを
オンデマンド※1 で利用出来るサービスの総称です。
※1) オンデマンド
利用したい時に、利用した分だけ支払い、金額が変化する従量課金料金体系の事。
Webやメールといったインターネットのサービスも、オンデマンドなサービスといえる。
今迄は、ハードウェアを購入したり、ソフトウェアをパソコンにインストールしたり、
ソフトウェアのライセンスを購入しなければ、サービスが使えない事が一般的でしたが、
クラウドの出現によりハードウェアを購入したり、ソフトウェアをインストールしなくても
利用出来るようになりました。
また、サーバー、ネットワーク、ソフトウェアなどの設備を自分達で導入・運用する
オンプレミスのシステムでは、調達する機器の台数や性能を見積もってシステム設計・構築を
する必要がありました。さらに、調達する機器の場合簡単に入れ替える事が出来ない為、
処理ピークを想定して機器の導入を考慮して調達する器具を考えたりする必要がありました。
一方クラウドを利用する事で、従来のオンプレミスのシステムでは出来なかった様々な問題を
解決出来るようになります。
クラウドの代表的なシステムが AWS（Amazon Web Services）となります。
#### ■ AWSのメリット ##### ▶︎ オンデマンドな固定費 従来のオンプレミスのシステムでは、機器などに多額の投資をする必要がありましたが、 クラウドを利用する事で、リソースを利用したい時に利用したい分だけ支払う方法に 変える事が出来ます。なので、多額の投資を行う事がないのは大きなメリットになります。
また、既存のシステムの一部をクラウドシステムで代用する事で、総所有コストを削減
する事が可能になります。
▶︎ 規模の経済を活かした低従量課金制度
数十万単位の多くのユーザーがクラウドを利用している為、規模の経済※2 を活かして
従量課金制の料金を低く提供する事が出来ます。
※2) 規模の経済
事業規模が大きければ単位当たりのコストが下がる効果のこと
▶︎ キャパシティ予測が不要
AWSでは、必要に応じてリソースの増減を行う事出来るので、従来のオンプレミスのように
キャパシティの最大のインフラ容量を予測する必要がなくなりました。
クラウドなら、リソースの調整やスケールアップ/スケールダウンの実行をわずか数分で行う
事が出来ます。例えば、万が一リソース不足になった場合でも柔軟にスケーリング（規模の増減）
を行う事が出来ます。
▶︎ 速度と俊敏制の向上
AWSでは、従来のオンプレミスとは異なり、新規構築が不要な上に、
分単位の短い時間を要するだけで、新しいITリソースを利用する事が可能になる為、
迅速なリソース調達が可能になりまた、組織の俊敏性も大幅に向上します。
▶︎ 運用管理費用が不要
AWSでは、各種サービスの利用料には運用管理費用が含まれています。
例えば、サーバー代、ライセンス費用、データセンターの利用料、保守費用、
人件費などが含まれています。
これにより、クラウドを利用する事で、サーバーの設置、連携、起動といった作業が
不要になり、ユーザーに直結した業務に専念する事が可能です。
▶︎ デプロイが容易
デプロイとは、開発した機能やサービスを利用できる状態にする作業の事を指します。
つまり、特定のアプリケーションやサービスをインターネットを通じていつでも利用出来る
状態にする事をいいます。
従来であれば、Webサーバーを構築するにも、データセンターへ出向き、キッティング、
ネットワークケーブリング、そしてOSのセットアップと多く工数を要するのに対して、
AWSでは、わずか数回の作業で世界中のリージョンにアプリケーションを容易に展開する事が
出来ます。オフィスに居ながらにして世界中にデプロイする事が出来ます。
#### ■ クラウドアーキテクチャの設計原理 ##### ▶︎ Design for Failure Design for Failure とは、「故障に備えた設計」という意味です。
故障や災害が起きてから、スケーラブルに対処するという事がないように
設計時に故障を処理するメカニズムをあらかじめ構築する事で、耐故障性の
高いアーキテクチャ構築が出来ます。
こういった設計をするに当たって、「単一障害点（SPOF）※3」をなくす考え方をします。
※3) 単一障害点（SPOF）
SPOFとは、ある単一のポイントが働かないと、システム全体が障害に陥るような箇所を指す。
システムの可用性を高める為には、SPOFの存在する機器を冗長構成するなど、SPOFが残ら
ないように設計を行う必要がある。
オンプレミスのシステムでは、万が一故障した時の為に 「RAID構成」をとっています。
RAIDとは、複数の外部記憶装置（ハードディスクなど）を一台の記憶装置として
冗長運用（システムを止めずに運用）する技術の事です。
下記の画像にように、全く同じ中身のディスクを作り、万一片方のディスクが故障した
場合でもミラーリングされた側のディスクで継続運用する事で運用し続けます。
▶︎ コンポーネントの分離
クラウドの設計原理は、お互いに依存し合わないコンポーネントを構築し、
あるコンポーネントが何らかの理由で故障やスリーブ状態になっても、システムの
他のコンポーネントが構築され、故障が生じていないかのように作業を継続
する事を可能にします。
鍵となる考え方は、サービス思考アーキテクチャ（SOA）と疎結合という考え方です。
▪️ サービス思考アーキテクチャ（SOA）
特定のシステムや製品を指すものではなく、「コンピュータ・システムを開発する時の
考え方・手法」を指した言葉です。
１つのシステムを「１つの大きな製品」ではなく「複数の部品（サービス）が集まったもの」
として考えます。基本的に「１つの処理に１つのサービス」として区切られており、個々の
独立性は高く、サービス同士の依存性は低いのが特徴です。その為、不都合なサービスが
あった場合、そのサービスだけ修正を行い他のサービスと取り替えるといった事が可能です。
各サービスはブラックボックス化されているので、これによりサービス同士の依存による
システムの煩雑化を防ぐ事が出来ます。サービス同士の依存性が低い為、より低いコストで
システムを運用する事が可能です。
つまり、SOAという考え方で製作した場合、変更の必要があるサービスのみ調整を行い、
短時間で対応することが可能のなる為、「１つの大きな製品」として作った場合に比べて
柔軟に対応出来る為、処理の変更に掛かる時間を大幅に減らす事が出来ます。
> ▪️ 疎結合 システムの構成要素間の結びつきや互いの依存関係、関連性などが弱く、各々の独立性が 高い状態の事をいいます。逆に、要素間の結びつきが強く独立性が低い状態の事は「密結合」 といいます。 > 疎結合な設計では、各要素が互いに深く結びついてはおらず、一部分の変更が他の要素に 影響を及ぼす度合いが小さく、互換性や拡張性、担当や責任の分担のしやすさ、不具合発生 時の原追のしやすさなどで優れています。
また、バッチ処理アーキテクチャでは、お互いに独立している非同期コンポーネントを作成 出来ます。コンポーネントの分離を実現するには、Amazon SQSを使ったキューイングチェーン を利用して非同期かつ疎結合にする事が可能です。
SQSを使用する事で、万が一処理中に障害起きたとしも SQSにデータが一旦保存されるので
SQS（A）で障害が起きても、SQS（B）に送付先を変更すれば、SQSにたまったデータは失われ
ません。もしSQSなかった場合、SQS（A）で障害が起きた場合、SQS（B）に行き先を変えて
データが流れるまでの間のデータはロストしてしまいます。
SQS自体がメッセージを一定時間保持してくれるので、フローデータの耐障害性が高ります。
それ以外にも、A以外のCでも同じデータが必要になった場合にも、SQSのデータ送付先に
Cを追加するだけで良いメリットがあります。
また、マイクロサービスアーキテクチャを用いる事で、システムを複数の小規模なサービスの
集合体として構成し、コンポーネントの分離を促進する事が出来ます。
▶︎ 弾力性の実装
弾力性は伸縮性ともいい、リソースの性能を柔軟にスケールアウトしたり、
スケールインする事が可能です。
弾力性の方法にも下記の３つ方法があります。
◼︎ 巡回スケーリング
一定間隔に発生する定期的なスケーリング
◼︎ イベントベーススケーリング
予定されているインベントの為にトラフィックリクエストが急激に増加されると
予想される時に実施するスケーリング
トラフィック量/処理量の増大予定時刻に合わせて自動的にインスタンスを
増やす事が出来る、スケジュールドスケールアウトパターンを利用する事で
弾力性を実現する。
◼︎ オンデマンド自動スケーリング
監視サービスを利用する事により、監視項目に基づいてトリガーを送信して
実施するスケーリング
トラフィック増加を自動的に検知しインスタンスを増やす事が出来る
スケールアウトパターンを利用する事で弾力性を実現する。
▶︎ 並列化を考慮
クラウドでは、並列化を簡単に実装する事が出来ます。
並列化させる事で、並列データ処理はネットワークによって接続された複数の
プロセッサもしくは計算機（以下，計算機とする）を用いて、与えられたデータ処理を
並列化して実行する事が可能になり、処理能力を高速化を目指すものである。
また、ロードバランサーを使用して、複数の非同期のWebサーバー全体で受信
リクエストを分散させて、Webサイトへのアクセス集中やサーバー故障などの場合でも、
アクセス中の利用者に安定したサービス提供を継続可能します。
#### ■ AWS Well-Architected フレームワーク AWSが推奨するアーキテクチャフレームワーク、クラウドを運用する為の ベストプラクティスです。 要約 ) AWS認定公式サイト : [AWS Well-Architected](https://wa.aws.amazon.com/index.ja.html)
また、AWS Well-Architected Tool を利用する事で、最新の AWSベストプラクティスに
照らしてワークロードをレビューし、クラウド向けにワークロードのアーキテクチャを設計する
方法についてアドバイスを得る事が出来ます。
AWS Well-Architected フレームワークは、５本の柱を基本としています。
▶︎ 運用上の優秀性
ビジネス価値を実現する為のシステムを実行してモニタリングし、
それらをサポートするプロセスと手順を継続的に改善する機能。
▶︎ セキュリティ
リスクの評価と軽減戦力を通してビジネス価値を提供しながら、
情報、システム、資産を保護する能力。
▶︎ 信頼性
インフラストラクチャやサービスの障害から復旧、必要に応じて
コンピューティングリソースの動的な取得、設定ミスや一時的なネットワーク問題などの
障害の軽減といったシステム機能。
▶︎ パフォーマンス効率
コンピューティングリソースを効率的に使用してシステム要件を満たし、需要の変化や
技術の進歩に合わせてこの効率を維持する能力。
▶︎ コスト最適化
最も安価にシステムを実行してビジネス価値を実現する能力。