Zenn
📌

AWSの基礎知識

2023/09/16に公開
AWS
tech

AWSが使われる理由

AWSなどのパブリッククラウドがまだ普及前の従来インフラ基盤はどうだったか?

サーバなどはデータセンター（DC）によって管理していました。
DCは企業によっては保有しているところもありますが、リース(レンタル)してサーバを置かしてもらうことも可能です。
⇨ このようにDCを利用してサーバを日々運用していました

問題点

  • サーバ機器などは購入してから届くまで1ヶ月かかる場合もありリードタイムが長くなってしまう
  • DCに関わる費用が発生する
  • 物理機器の購入費が高額。（1台100万とかもあるので小さな企業では小さくスタートできづらい）
  • ソフトウェア費用
  • メンテナンス費用

改めて、以下導入までの流れ
選定 → 購入 → 輸送 → 設置 → 設定
長いステップを踏まなければならない

参考） https://aws.amazon.com/jp/aws-ten-reasons/

パブリッククラウド（AWS）の登場

特徴として以下のようなことができるようになった。

  • さまざまなITサービスを借りることができるようになった。
  • 料金は使った分だけ請求が発生する従量課金制度
  • キャパシティをプールできるようになった(⇨ AWSがあらかじめ機器を確保(保有)しているので、サーバ台数、ストレージ容量などの柔軟性を持ったインフラ管理ができるようになった)
  • リードタイムの短縮化（サーバを建てるだけであれば数分で借りれるようになった）
  • 技術の標準化 ⇨ いろんな製品を簡単に触れる => 技術の幅が広がる　＝>　技術の標準化（ネットに技術情報が溜まりやすい）

AWSインフラストラクチャ

AWSとはグローバルインフラストラクチャ = 物理的なDCを世界中にありサービスを提供している
　- リージョン ⇨ 国、広い地域で物理的に分離する地域単位の名称

  • AZ ⇨ DCを1箇所に集めずに1つ以上のDCが集合している地域
  • エッジロケーション ⇨ CloudFrontやRoute53などリージョンに固定されずグローバルで展開されている地域(サービス)
  • ＋＠ 上記で説明したもを繋ぐ専用のネットワーク回線を持っている

では、日本では？

東京・大阪リージョンがある。

リージョン名 : ap-northeast-1
AZ名 : ap-northeast-1a,c,d

マルチAZ構成

AZをまたがるインフラ構成を組むことができ、これは複数のDCで稼働していることになりより耐障害性が向上する。
このような構成をマルチAZ構成っといいます。

責任共有モデル

AWSを利用するにあたって責任範囲を明確に分けたモデル(概念?)がある。

参考） https://aws.amazon.com/jp/compliance/shared-responsibility-model/

AWS責任範囲

物理機器やDCなど、またソフトウェアまでがAWSの責任範囲

ユーザー

データの暗号化や、アクセス制限などのセキュリティ、データの管理方法(設定)がユーザーの責任範囲

あらかじめ、AWSでは各種サービスにSLAを設けている。
SLAはどれだけそのサービスが稼働できるか稼働率を保証するもの。
万が一、保証した稼働率以下になった場合は返金するなどの対応をしておりAWSの責任範囲を守っている

AWSのAPI AWSを操作する

  • マネジメントコンソール
    ⇨ GUIで操作

  • AWS CLI
    ⇨ CLIコマンドで操作できる（専用の）

  • AWS SDK
    ⇨ プログラミング言語で操作する

SDKに関するちょっとした疑問。。。
AWS SDKとAWS CDKって似ているけどどう違うのか？

SDKの方は、バックエンドやフロントエンドのプログラミングがメインで、その中でS3にオブジェクトをアップロード・ダウンロード・削除するなど、AWSのリソースを利用するために使うことが多いです。なのでバックエンドやフロントエンドのエンジニアが使うことが多い。
CDKの方は、AWSリソースを作る（インフラを構築する）ことがメインです。なのでインフラのエンジニアが使うことが多い。

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

VPCという仮想のネットワーク空間を作成できるサービスがある。
その中でサブネットを切ることができ、AWSでは以下の考え方がある。

  • パブリックサブネット ⇨ インターネット直接通信ができる
  • プライベートサブネット ⇨ インターネットと直接通信ができない

6つの長所

固定費から変動費

AWSでは基本的に従量課金制を採用している

規模の経済

ユーザー数が多い　⇨ 規模の経済が大きい
これをしやすくするためにスコールしやすさがメリット

キャパシティの予測が不要

柔軟にスペックの変更を行うことができるため、キャパシティの予測が不要となる
例) S3の容量は実質無制限

速度と俊敏性の向上

サーバ1台などであれば数分で開始（起動）させることができる

DCの運用や保守への投資が不要

AWSの考えとして「ソフトウェアの開発に注力してほしい。価値ある仕事を集中しよう」というよう考えがある
そのため「価値」に直結しにくと考えられるDCの保守などの時間をなるべく削減しようという考え
※ サーバレスとかがより近い気がします

世界中にデプロイできる

AWSはグローバルサービスなので、ユーザーの位置に合わせた柔軟な対応ができる

W-A 6つの柱

Well-Architected6つの柱

AWSのインフラを設計する上で役立つ設計原則。
※ あくまで原則なので完全に網羅しなければ使えないとかではない。

参考) https://www.ctc-g.co.jp/solutions/cloud/column/article/54.html


参考) https://aws.amazon.com/jp/blogs/news/aws-well-architected-framework-security-pillar-hri/

運用上の優秀性

インフラをコード化、自動化するかなどしてオペレーションミスを軽減していこうということ
自動化推進のためのサービスなどもあったりする

小規模かつ可逆的な変更を頻繁に行って切り戻しをしやすくしよう

セキュリティ

アイデンティティ基盤(IAM)の実装 ⇨ 権限管理を行なっていこうという話。
その中でも権限は必要最低限である「最小権限の法則」を推奨しています。

追跡可能性 ⇨ ログ保管、アラーム設定を利用して現状を把握すること
CloudTrail CloudWatch

全レイヤーでセキュリティを適用する
NW ~ コンピューティング ~ アプリケーション 全てのレイヤーでセキュリティを強化する措置は行うこと

データに人の手を入れない
データが触れられる＝データの改竄の恐れがあるので、基本は取得したデータに対する権限管理を行なって保護することが重要

信頼性

障害は起こってしまうことが前提で構成すること
Multi-AZやマルチリージョンなどAWSでは冗長構成を取ることができる
単一障害点をなくすということ

水平方向のスケーリングで可用性を高めていく
垂直でもスケールは可能ですが、障害を起こす箇所については増えていない

パフォーマンス効率

最新のテクノロジーをすぐに扱うことができる。
⇨ より頻繁に検証などを実践しやすくなった

コスト最適化

コスト利用状況を見れるため費用分析を行うことができ、無駄な費用の発生を確認できる。
AWS Trusted Advisorなどを使って無駄なコストの発見しやすくサービスも用意している

持続可能性

地球環境に配慮した理念(SDGs的なもの)

環境のためにも効率的なハードウェアを利用していこうということ
手元のデバイスの容量を圧迫をあまり与えない ⇨ データはサーバ側で保存すればいい

3層構造


参考) https://teratail.com/questions/306714

リクエストとレスポンス

クライアントがリクエスト（ください）をサーバに向かって投げる
サーバがリクエストを受けとり、レスポンス(応答) を返す

参考) https://medium-company.com/http-get-post-違い/

DNS

どこに向かっていリクエストが飛んでいるのか？
⇨ IPアドレスに向かって飛んでいる ⇨ 英数字はドメインという

ではどうやって英数字からIPアドレスがわかるのか？名前解決している？
⇨ DNSサーバで名前解決をしている
Route53がDNSサービスになる

DBサーバ

⇨ データに対する処理を行っている
⇨　 データ管理するの用のサーバをDBサーバ
⇨ SQL言語を使って操作する

タグ戦略

タグとはAWSリソースに付与できる管理情報

  • AWSが自動で付与(管理)するタグ ⇨ aws:xxxxx
  • ユーザーが作成するタグ ⇨ Key Value

メリット

タグによって以下のことができるようになります。

  • 検索
  • 管理
  • フィルタリング

Resource Groups

  • 一括でタグ管理
  • リスト化することができる
  • IAMでタグを利用したアクセス制御できる

タグのベストプラクティス

  • 機密情報はタグ付けしない
  • 持続的な管理戦略
  • シンプルなほど良い

いろんなタグの戦略やカテゴリー

  • 技術タグ （環境、機能、システム名
  • 自動化系 (バックアップ周期、自動起動/停止時刻
  • ビジネス (プロジェクト名、管理者名
  • セキュリティ (監査要件、データの重要度

タグdemo

コスト集計対象にする

Billing ⇨ コスト配分タグ
フィルタリングを行うためにはステータスが「アクティブ」になっている必要があります
非アクティブのものはチェックボックスから有効化にすることで集計対象となります。
※ 対象となるには24時間程度の時間が必要となります。

コストをフィルタリングする

CoseExploler ⇨ グループ化の条件 ⇨ タグ選択
タグごとの値に集計してくれる

一括管理

Resource Grouup ⇨ タグ付け ⇨ タグエディター
以下の値を入力することで検索ができます

  • リージョン
  • リソースタイプ
  • 検索対象 値

⇨ リソースの検索後はチェックボックスから選択して一括編集を行うことができます。

リソースグループ作成

上記の一括管理する時のリソースをグループ化することができます。
グループ化することによって途中追加したタグリソースでも自動的に追加されるので便利

Discussion