AWS概要

2024/01/20に公開

Amazon Web Servicesの基礎知識について

オンプレミスとAWSの違い

従来のインフラ環境(オンプレミス)

データセンターと呼ばれるサーバを設置して運用していくもので、ラックにサーバを格納し、サーバを冷やすために温度調節、入管するためにはセキュリティカード必須となります。

企業は、データセンターを保有またはラックをレンタルする。(企業の資産として保有し利用します。)

ラックレンタル料金、機器の購入費用、管理費用等に多額の資金が必要になります。

  1. データセンターにかかわる費用
  2. 物理機器の購入費
  3. ソフトウェア費用
  4. メンテナンス費用
  5. 物理機器調達のリードタイム

    機器一台を購入するにしても、機器選定→購入申し込み→輸送時間→ラッキング→初期セットアップ といった作業が発生するため使用開始まで時間がかかります。

AWS環境

オンプレミス環境で必要だったITリソースを借りることが出来るサービス

ユーザまたはオフィスのネットワークを使用し、AWSサービス(サーバー、ストレージ、NW)にアクセスします。

メリット
  • 使用した分だけ請求が来る従量課金制(サービス利用した分、保存した単位、転送したネットワーク)
  • CPUやメモリ等のキャパシティをプールしてくれる
  • EC2インスタンス(仮想サービス)はWebブラウザで数クリックで数分以内で使用可能(オンプレと比較しリードタイムの短縮)

以下、オンプレミスとAWSの比較

オンプレミス AWS
多額の初期費用が必要 使用した分のみ支払う(従量課金制)
キャパシティ予測必要(インフラ見積もり時にスペック想定) キャパシティ予測不要
通常1か月~ 即時利用可能
専用線、接続制限 どこからでも接続可能
技術が広くカバー困難 技術の標準化

AWSの特徴として、手軽に利用することが出来るためユーザ数が多い(規模の経済)ことからが学習がしやすい環境です。

AWSグローバルインフラストラクチャ

AWSクラウド:物理的なデータセンターを利用したサービス

リージョン:地域単位に分割して管理(国や広範囲な地域が一つの単位)

  • 目的:障害対策や安定性を実現するためリージョンは物理的に離れて点在している

       また、高帯域で冗長化されたAWS専用のネットワーク回線で接続されています。(安定した品質、ハイスピード、故障に強い)

AZ(アベイラビリティゾーン):1つ以上のデータセンターをまとめた単位

  • 目的:障害が発生した際に別のデータセンターでサービスを継続して稼働することが出来る

エッジロケーション:配信したい画像や動画をキャッシュすることで地理的に離れたユーザにもより素早くコンテンツを配信することが出来る

日本には、東京リージョンと大阪リージョンがあります。

マルチAZ構成:同じ構成のシステムを2つのAZにまたがって設計し、障害に備えておく設計原則

責任共有モデル

責任共有モデルとは、AWSにて障害が発生した際にAWS?利用者?といったどちらの責任かを明確にするものです。

AWSの責任:リージョン、AZ、エッジロケーションなどに関連するハードウェアやグローバルインフラストラクチャそのものに責任を持ちます。(AWSをサービスととして提供するための物理的な機器)

  • データセンター内で稼働しているサーバ、ストレージ、データベース。ルーター、スイッチ、そのうえで稼働するソフトウェア、ディスクの廃棄、データセンターのセキュリティ管理など

ユーザの責任:この上を全部責任を持ちます。

  • OSパッチ適用、アップデート、ファイアーウォール設定、データバックアップ、開発したアプリケーション、ユーザIDなどアクセス管理やデータ暗号化など

AWSを操作する3つの方法(API)

  • AWS CLI

     コマンドラインで操作

     コマンド例:aws ec2 run instances
  • マネジメントコンソール

     Webブラウザ上からGUIで操作
  • AWS SDK

     プログラミング言語を使用する方法

共通しているのが、AWSはAPIのエンドポイントをインターネットに公開しているので、最終的にはエンドポイントに対してHTTPプロトコルで指示を出すこと。エンドポイントを受け取ったAWSは、指示されたとおりにリソースの操作を行う。

パブリックサービス、プライベートサービス

・AWSはインターネット回線を利用して世界中のどこからでも利用可能

・AWSのエンドポイントに対してHTTPリクエストし、AWSは指示された通りにリソースを操作するもの

パブリックサービス:インターネットから直接アクセスできるサービス(S3、CloudFront)

プライベートサービス:VPC内に構築するサービス。パブリックIPアドレスを持つことできるサービスもある。(EC2、RDS)

VPC:利用者ごとに仮想的なNW空間を確保してくれるもの(AZ内のデータセンターの内側に構築したサービス)

VPC内のサービス:基本的にプライベートIPアドレスで通信する

インターネットサービス:パブリックIPをもち、ドメイン名をもつ。エンドポイントとしてアクセスポイントを持つイメージ。

クラウドコンピューティングの6つの長所

固定費から変動費へ

オンプレミス:CAPEX(設備投資) 固定費
  • 物理サーバ(サーバとなるコンピュータ、ネットワーク機器、セキュリティ機器、電源設備、およびそれらを配置するデータセンター等の物理的な機器や設備を「所有」する必要があるため、導入費用や人件費、場所や土地代といったコストが発生します。
  • 耐用年数の間は税金控除
AWS:従量課金制(多額の初期投資が不要)OPEX(事業運営費)EC2
  • 費用として税金控除(毎年)

規模の経済:一定の規模や数量を確保することで、一つ当たりのコストが下がる考えかた

  • ユーザ数が多い =規模の経済
  • スケールによる大きなコストメリット(AWSは利用料を値下げできる)

キャパシティ予測が不要(システム導入に先立ってキャパシティを決定すると、多くの場合、効果で無駄なリソースが発生したり、または逆に思わぬ追加設備が必要になる・・・)

  • オンプレミス:事業計画をたててスペックの見積もり、事業成長、事業計画など…
  • AWS:稼働中にスペック変更(最低限のスペックにしておき、スペックが足りなかったら稼働中のサーバのCPUやメモリ、ストレージのサイズ変更)

速度と俊敏性向上

  • AWSではクリックで数分以内にサーバ(EC2)を立ち上げることができる。
  • オンプレでは週週間単位でかかっていた時間が分単位になる。
  • 変化にも対応できる:ITリソース使用までの時間が大幅に減るため、組織の俊敏性も大幅に向上

データセンターの運用や保守に投資が不要(データセンターやインフラにコストを費やすのはやめ、元価値あることに集中しようというコンセプト・・・インフラではなく開発スピードを上げていきましょう)

  • オンプレミス:必要であったサーバのラッキングやメンテナンス、電源システム、廃棄
  • AWS:価値のある仕事に集中しよう

グローバル化を即座に実現(世界中にインフラを構築できるように設備しているため、Web画面上から数分でアプリケーションを安全にデプロイすることができる)

  • 世界中に即座にデプロイすることが出来る
  • 最低限のコストで、ネットワーク速度も速く、ユーザにストレスなく利用してもらえるような環境提供すること

Well-Architected Framework 6つの柱

Well-Architected Frameworkとは、AWSでシステムを導入したり構築する際に役立つ設計原則で、ベストプラクティスの6つの観点からまとめたもの

運用上の優秀性(オペレーショナル・エクセレンス)

システム運用を効率化し、開発のプロセスや手順を継続的に改善することで、利用者はサービスの価値を高めましょうという・・・ものです。
  • 運用をコードとして実行する(CloudFormationなインフラ構築をコード化し、自動化・省略可でき人為的なミスを阻止する。)
  • 小規模かつ可逆的な変更を頻繁に行う(システム更新は顧客影響や切り戻しなどのリスクを抑えるために可能な限り小規模に、定期的に実行するように計画すること)
  • 運用手順を定期的に改善(定期的に手順の改善、手順に理解を深めること)
  • 障害を予想する
  • 運用上のすべての障害から学ぶ

セキュリティ

AWSはインターネット上に環境を構築する性質上、常に攻撃のリスクがありますが、AWSサービスを利用し適切に設定することでセキュリティ強化を図り、セキュリティ事故やリスクや影響を軽減できる
  • 強力なアイデンティティ基盤の実装(最初権限の付与)
  • アイデンティティ:ユーザIDやパスワードなどの「識別情報」、IAM 最小権限の法則
  • トレースアビリティの実現(Amazon CloudWatchを利用してログやアラームにてシステムで起きていることを把握する、リアルタイムな運用監視)
  • 全レイヤーでセキュリティを適用する(ネットワーク、コンピューティング、アプリケーションなどシステムの役割に分割した領域のこと)
  • セキュリティのベストプラクティスを自動化する(インフラ構築をコード化してセキュリティの設定もれを自動的に防いだり、標準化していく)
  • 伝送中および保管中のデータ保護(暗号化関係)
  • データに人の手を入れない(SQSやLambda)
  • セキュリティイベントに備える(対応する手順、作成するだけではなく実際にセキュリティ事故を想定した訓練実施し、手順を実際に使用することでセキュリティイベントに備える)

信頼性:Reliability

信頼性の高い設計とは、障害を起きないようにするのではなく、障害は起こってしまうものだという前提で、あらかじめ迅速な復旧手順を整備したり、復旧そのものを自動化するなどあらかじめ対策する。
Design for Failure(故障のための設計)
  • 障害から自動的に復旧する(マルチAZ)
  • 復旧手順をテストする
  • 水平方向にスケールしてワークロード全体の可用性を高める(EC2インスタンスのスペックが同じものの数を増やす)
  • キャパシティを推測することをやめる(容量など)
  • オートメーションで変更を管理する(インフラ構築の自動化:ヒューマンエラーをなくす、CloudFormation)

パフォーマンス効率

  • 最新テクノロジーの標準化
  • わずか数分でグローバル展開する
  • サーバレスアーキテクチャを使用する
  • より頻繁に実験する
  • 適切なアプローチを選択する(適切な構成を選択)

コスト最適化

  • クラウド財務管理の実装
  • 消費モデルを導入
  • 全体的に効率を測定する
  • 差別化につながらないインフラ管理に費用や負担をかけるのをやめる
  • 費用や分析及び属性化する

持続可能性(SDGS)

  • 影響を把握する
  • 持続可能性目標の設定
  • 使用率の最大化
  • より効率的なハードウェアとソフトウェアの提供を予測して採用する
  • マネージドサービスの使用(AWSが管理してくれるもの)
  • クラウドワークロードのダウンストリームの影響を軽減
GitHubで編集を提案

Discussion