お仕事

AWSクラウドプラクティショナー資格取得のための学習用備忘録(AWSクラウドの概念)

 

メモ

仕事で前回のITパスポート資格に続き、スキルアップと今のPJで活かすためにAWSの資格を取得することにしたのでその勉強用の備忘録です。

まずは「クラウドプラクティショナー(AWS Certified Cloud Practitioner(CLF-C01))」から。

いつも何か勉強するときは基本的に書きながら覚えるのでここでアウトプットします。

有益な情報かどうかは不明(笑)

 

スポンサーリンク

AWSクラウドの概念

 

クラウドとは

 

クラウドとは、AWSのようなクラウドサービスプラットフォームから
インターネット経由で様々なITリソースを
オンデマンド(従量課金)で利用できるサービスの総称。

 

クラウドコンピューティングの利用により
従来オンプレミスのシステムではできなかった様々なことができるようになる。

 

AWSの長所と短所

 

6つのメリット

 

1.固定費(設備投資費)が柔軟な変動費へ

クラウドを利用することで、リソースを利用した時に利用した分だけ支払う方法に変えることができる。

大きな初期投資を行う必要がなくなるスタートアップ企業はもちろん、
既存の企業もシステムの総所有コストを削減させることで
新規システムへの投資を柔軟に行うことができ継続的なコストパフォーマンスを改善できる。

総所有コストには各種人件費やデータセンター費用に加え
電気代やソフトウェアライセンス、保守費用などが含まれる。

 

2.スケールによる大きなコストメリット

クラウドの利用により、オンプレミスよりも低い変動コストを実現できる。

理由は数十万単位の多くのユーザーがクラウドを使用するため
規模の経済を活かして従量課金性の料金も低く提供できるため。

さらに、AWSは2018年までに60回を超える値下げを行ってきた。

 

3.キャパシティ予測が不要に

必要に応じてリソースの増減を行うことができるため、最大のインフラ容量を予測する必要がなくなる。

リソースの調整やスケールアップ/スケールダウンの実行をわずか数分で行うことができる。

万が一、リソース不足やリソース過多になった場合は、状況に応じて柔軟にスケーリングを行えば良い。

 

4.速度と俊敏性の向上

AWSでは新しいITリソースを簡単に利用できる。

従来のオンプレミス型なら数週間〜数ヶ月単位の時間がかかる導入も
クラウドなら分単位の短い時間を要するだけで開発者が新しいリソースを利用することが可能になる。

アプリエンジニアが行なっているアジャイル開発の仕組みを
クラウドインフラのリソース調達に適用することも可能。

結果、検証や開発にかかるコストと時間が大幅に減るため、組織の俊敏性も大幅に向上。

新しいビジネスアイデアが浮かんだ場合でも、他者に先んじてそのアイデアを市場に問うことが可能になる。

 

5.データセンターの運用と保守への投資が不要に

AWSのサービス利用料には、従来のオンプレミスシステムの各種費用が含まれている。

例えば、サーバー代、ライセンス費用、データセンター利用料、ラックの利用料、電気代、ネットワーク利用費用、ハードウェアベンダーへの保守費用、各種人件費が含まれる。

さらに、定期的な機器更改に関わる日宇洋も検討する必要はない。

これにより、サーバーの設置、連携、起動といった重労働が不要になり、ビジネスを差別化するPJに専念できる。

 

6.わずか数分で世界中にデプロイ

AWSなら数クリック、数分で、オレゴンリージョンにWebサーバーを構築できる。

わずか数回クリックするだけで、世界中の複数のリージョンにアプリケーションを用意に展開できる。

いつものオフィスにいながらにして、シンプルな操作と最小限のコストで世界中にデプロイできる。

 

クラウドアーキテクチャの設計原理

 

・故障に備えた設計(Design for Failure)をすれば、何も故障しない

クラウドサービスのそれぞれのサービスは全て、ハードディスクなどの単体の部品として置き換えて考える。

時間が経てば故障するということを認識し、この考えをアーキテクチャに取り入れたのが「故障に備えた設計」。

災害が襲ってからスケーラブルなインフラに対処するということが起きないように、故障を処理するメカニズムをあらかじめ構築する。

そうすれば、クラウドに対して最適化された耐故障性の高いアーキテクチャを構築できる。

これを実現するためには、単一障害点(SPOF)をなくすという考え方をする。

1.1つのデータセンターのみで運用しない

2.単一のインスタンスのみで構成しない

※マネージドなサービスは単一障害点にならないように考慮されているため、積極的に利用する

 

・コンポーネントの分離

クラウドはサービス指向アーキテクチャの設計原則を踏襲する。

システムのコンポーネントを疎結合にすればするほど、スケーリングが大規模にうまく行える。

鍵となるのは、互いに過度に依存し合わないコンポーネントを構築し
あるコンポーネントが何らかの理由で故障、スリープ、ビジー状態になっても
システムの他のコンポーネントが構築され、故障が生じていないかのように作業を継続すること。

疎結合は、各種アプリケーションのレイヤーやコンポーネントを分離すること。

つまり、各コンポーネントは他のコンポーネントと非同期に相互作用し、お互いに「ブラックボックス」として扱われる。

Webアプリケーションアーキテクチャの場合、APPサーバ、Webサーバ、DBにそれぞれ分離できる。

コード的な観点、機能的な観点からの依存関係はなくなる。

 

また、バッチ処理のアーキテクチャにおいては
互いに独立している非同期コンポーネントを作成できる。

コンポーネントの分離を実現するためには
Amazon SQS(Simple Queue Service)を使ったキューイングチェーンを利用して
非同期かつ疎結合にすることが可能。

キューには処理が完了されるまでデータが残っているため
万が一処理中のコンピューティングリソースに障害が起きたとしても
他のコンピューティングリソースが処理を継続できるため、耐障害性の確保にも繋がる。

また、マイクロサービスアーキテクチャを用いることで
システムを複数の小規模なサービスの集合体として構成し
コンポーネントの分離を促進することができる。

 

・弾力性の実装

クラウドは、インフラに弾力性(Elastic)という新しい概念をもたらす。

弾力性は伸縮性ともいい、
リソースの性能を柔軟にスケールアウトしたり、スケールインすることが可能。

 

弾力性は、次の3つの方法を用いることで実現できる。

1.巡回スケーリング:一定間隔(毎日、週ごと、月ごと、四半期ごと)に発生する定期的なスケーリング

2.イベントベーススケーリング:予定されているビジネスイベントのためにトラフィックリクエストが急激に増加すると予想されるときに実施されるスケーリング(新製品の立ち上げやマーケティングキャンペーンなど)

3.オンデマンドの自動スケーリング:監視サービスを利用することにより、監視項目(CPUの平均利用率やネットワークI/O量など)に基づいてトリガーを送信しスケールアウト/スケールインを行う

 

イベントベーススケーリングは、スケジュールドスケールアウトパターンを利用することで弾力性を実現できる。

一方、オンデマンドの自動スケーリングは、スケールアウトパターンを使用することで弾力性を実現できる。

クラウドでは、弾力性を活かしていつでもリソースの増減が可能。

必要なときだけ調達し、不要なときは廃棄ができる、いわば使い捨て可能なビジネスリソースとしてAWSを活用できる。

 

・並列化を考慮する

クラウドでは、並列化を簡単に行える。

クラウドでアーキテクチャを設計する場合は、並列化の概念を取り入れる必要がある。

クラウドでは繰り返し可能なプロセスを極めて用意に構築できるため
できるだけ並列化を実践し、さらに可能であれば自動化することを推奨。

Webアプリケーションを例にとると
ロードバランサーを使用して複数の非同期のWebサーバー全体で受診リクエストを分散させる。

弾力性と並列化を組み合わせると、クラウドの美しさが引き立つ。

スケールアップ:単体性能を向上:増強方法はシンプル

スケールアウト:台数を増加:複数台構成のため、耐障害性で優位

★ロードバランサーを組み合わせて並列処理を行う

★スケーリングは弾力性を組み合わせて、高負荷時にはスケールアウト、低負荷時にはスケールインを行う

 

・動的コンテンツデータをコンピュータの近くに、静的コンテンツデータをエンドユーザーの近くに保管する

従来のオンプレミスシステムでは、伝送遅延を回避するために
データをコンピュータまたは処理要素のできるだけ近くに保管することが良いと言われていた。

一方、クラウドではデータをネットワーク経由で利用するため
配信のオーバーヘッドやボトルネック対策は必須。

クラウド外にある大量のデータを処理する必要がある場合は
データをクラウド上に移してから処理を実行する。

例えば、データウェアハウスアプリケーションの場合、
データセットをクラウドに移行し、次にデータセットに対して並列クエリを実行することが望ましい。

RDBを用いてデータを保管、検索するWebアプリケーションの場合は
DBとAPPサーバをクラウドに一度まとめて移行するのが良い。

また、静的コンテンツは、CDNなどのサービスを利用して配布しておくのも良い。

★静的コンテンツは外部に出して、エンドユーザーの近くに保管する。

★動的に処理するデータは、クラウド上のコンピューティングリソースの近くに保管する。

 

AWS Well-Architected フレームワーク

 

信頼性、セキュリティ、効率、コスト効果が高いシステムを設計し
クラウドで運用するために作られた、アーキテクチャのベストプラクティス。

運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化という5本の柱を基本としている。

1.運用上の優秀性:ビジネス価値を実現するためのシステムを実行してモニタリングし、
それらをサポートするプロセスと手順を継続的に改善する機能。

2.セキュリティ:リスクの評価と軽減戦略をとおしてビジネス価値を提供しながら
情報、システム、資産を保護する能力。

3.信頼性:インフラやサービスの障害から復旧、必要に応じたコンピューティングリソースの
動的な取得、設定ミスや一時的なネットワーク問題などの障害の軽減といったシステムの機能。

4.パフォーマンス効率:コンピューティングリソースを効率的に使用してシステム要件を満たし
需要の変化や技術の進歩に合わせてこの効率を維持する能力。

5.コスト最適化:最も安価にシステムを実行してビジネス価値を実現する能力。

 

AWSクラウドの概念 まとめ

 

・クラウドとは、インターネット経由でコンピューティング、DB、ストレージ、アプリケーションなどの
ITリソースをオンデマンドで利用できるサービスの総称。

・オンプレミスとは、サーバー、ネットワーク、ソフトウェアなどの設備を自前で用意し運用するシステム。

・AWSクラウドコンピューティングには6つのメリットがあり、これは試験に出る重要な概念。

・AWSを活かしたシステム構成では、Design for Failure(故障に備えた設計)、疎結合性、弾力性、並列化、データの保管場所に留意する。

・Well-Architectedフレームワークとは、信頼性、セキュリティ、効率、コスト効率が高いシステムを設計し
クラウドで運用するための、アーキテクチャのベストプラクティス。





-お仕事

© 2024 ポンサラの逆襲