Open shareof opened 4 years ago
サービスを提供するためのデータセンタを示す。
ちなみにその中で提供されているサービスはAmazon CloudFront(CDN)である。
こちらのエンドポイントを叩くことで全てのエッジロケーションを見ることができる
https://ip-ranges.amazonaws.com/ip-ranges.json
経営用語の一つであり、企業が従業員に対してコンプライアンスを遵守させるために、自社で作成する計画のこと
コンテナ化と相対的な関係に位置する仮想技術であり、ハードウェアに搭載されているプロセッサやメモリの使用時間を細かく分割してそれぞれをひとまとめにし複数の個別独立した仮想サーバを実現するために用いられるソフトウェアのこと
両者の大きな違いについては、下図からもわかるようにホストOS上でゲストOSが動作するかしないか
ということである
一連の業務をアウトソーシングしたサービスこと(クラウド等が第一声としてあがる)
AWS がいかに安心なサービスかを第三者がまとめた監査レポート
相手が誰(何)なのか確認するのは 認証 リソースへのアクセス権限を与えること 認可
Identity and Access Managementの頭文字をとったもので、IT環境にアクセスを行う上で必要不可欠な以下2つの要素
Identity≒ユーザID
、アクセス管理(Access Management)
からなるセキュリティ用語である。
ネットワークを流れるデータのうち、外から中に入ってくるデータ(量): インバウンドトラフィック ネットワークを流れるデータのうち、中から外に出ていくデータ(量) : アウトバウンドトラフィック
ネットワークトラフィック(通信量)を増大させ、通信を処理しているコンピューティングリソース(通信回線やサーバの処理能力)に負荷をかけることによってサービスを利用困難にしたり、ダウンさせる攻撃のこと
DDOS得意性 DDOSはDOS攻撃を発展させたものであり、攻撃元が複数のコンピュータを乗っ取りターゲットに対して一斉攻撃を行う性質をもつ
AWS側がいくらコストをかけてセキュリティを担保したところで、ユーザの側の利用次第ではセキュリティの維持が難しくなる そのため AWSとユーザが負う責任が明確に分かれ それぞれのセキュリティを共有して守っていくこと
[x] クラウド本体のセキュリティ AWSグローバルインフラストラクチャーに含まれるリージョンやAZ、エッジロケーションといったデータセンタの地域、マネージドなサービスのソフトウェアの各種管理(アップデートやセキュリティパッチのインストール)がAWSの担当
[x] クラウド内のセキュリティ ゲストオペレーティングシステムの管理(アップデート、セキュリティーパッチのインストール)やAWSより提供されるセキュリティグループファイアーウォールの設定がユーザの担当
[x] データの保護 安全性の非常に高いAWSデータセンタに全てのデータが保存される設計になっている
[x] コンプライアンスの要件に準拠 インフラストラクチャー内で数多くのコンプライアンスプログラムを管理できる。 そのため、コンプライアンスの一部は最初から達成される
[x] コストの削減 ユーザ自身がデータセンタのなどの施設を持たず、AWSデータセンタに頼ることできるため、大幅なコストの削減かつ、最高難度のセキュリティを保つことができる
[x] 迅速なスケーリング クラウドの使用量に合わせて迅速にセキュリティをスケーリングできる
さきに述べたAWSの責任共有モデル
でAWSが負うべきクラウド本体の責任をレイヤ毎に分解すると以下のようになる
環境レイヤー
、物理的な境界防御レイヤー
、インフラストラクチャーレイヤ
、データレイヤ
の集合から構成される
各レイヤーの役割について
[x] 環境レイヤー 立地の選択、建設、運用・維持に至るまで、環境に固有の要因について考慮されている。AWS は、洪水、異常気象、地震といった環境的なリスクを軽減するために慎重にデータセンターの設置場所を選択している。 AWSの各リージョンにおけるデータセンタ郡は互いに独立し、物理的に分離されて配置されているため、不測の事態が発生した場合処理中のトラフィックを影響のある地域から自動的に移動できる設計が成されている
[x] 物理的な境界防御レイヤー AWSデータセンタの物理的なセキュリティは境界防御レイヤーから開始される 保安要員、防御壁、進入検知テクノロジー、監視カメラ等がその役割を担っている
[x] インフラストラクチャーレイヤー 発電設備、冷暖房換気空調設備、消化設備などでサーバを保護することを目的としているが、究極的にはユーザのデータを保護することに役立っている(サーバを保護することで必然的にユーザのデータも守ることができるため)
[x] データレイアー ユーザのデータを保持する唯一のエリアであるため、防御の観点ではどのレイヤーよりもクリティカルである 防御策はアクセスを制御し各レイヤーにおいて特権を分離することからはじまる。 またAWSはこのレイヤーをさらに保護するために脅威検出機器やシステム的な手続きを備えている
管理プレーンの保護に関するセキュリティの範囲はユーザの担当である
※ルートアカウントの定義 AWSサインアップ時に作成したメールアドレスのアカウント が該当する このアカウントは全ての操作を行うことができるため、通常時の運用では適切な権限のみを付与したユーザを作りそのアカウントで運用するべきである。また1つのアカウントに対しユーザは複数作成できる
[x] キーペアの管理 EC2などのAWSインスタンスへのログインで利用する。 認証には公開鍵認証方式を用いているため、ユーザ側は秘密鍵を適切に管理する責任がある。 そのため、秘密鍵を共有することは好ましい行為ではなく、ユーザごとにキーペアを作成し、ユーザ毎の公開鍵をサーバ(EC2などのインスタンス)に設定するのが望ましい。
[x] APIキーの管理
操作手段 | 利用方法 | 認証方式 |
---|---|---|
Webブラウザ | AWSマネージメントコンソール | ユーザ名/パスワード |
コマンド | AWS CLI |
アクセスキー/シークレットアクセスキー |
プログラム | AWS SDK | アクセスキー/シークレットアクセスキー |
ユーザは、アクセスキーとシックレットアクセスキーを作成・保持することでAWS CLIやAWS SDKの認証情報として利用できる 基本的な利用方法としては、認証情報を環境変数に設定もしくは、認証ファイル内に格納して利用する また、これらの認証情報はユーザのアカウントと同等であるため、権限の強いアカウントでは利用しない(特にルートアカウント) ことが望ましい。
ユーザが操作できる全ての部分はユーザに責任がある
ユーザとAWSでそれぞれ分担する
ユーザはAWSのデータセンタ等をみてデータの安全性を確かめることはできないが、第三者が監督している調査レポート(AWS Artifact)を通じて確認することがきる。
ユーザのAWSクラウドリソースへのアクセス管理サービスである。 この管理サービスを利用することにより、AWSのユーザとグループを作成及び管理し、アクセス権を使用してAWSリソースへのアクセスを許可及び拒否できる。
EC2やLambdaなどのAWSリソースに権限の付与を行うことができる。 メリットとしてはAWS内部でIAMロールとEC2を直接紐付けることができるのでキー管理が不要となる。
1つ以上のインスタンスのトラフィックを制御するための仮想的ファイアウォール 従来のファイアウォールとの差異は個別のインスタンスに対してファイアウォールを設定できる点である。
行える設定
留意点 セキュリティグループを新規作成する際は インバウンドルールがない そのため、インバウンドルールをセキュリティグループに追加するまで別のホストから送信されるインバウンドトラフィックは許可されない。
マネージドな型の分散サービス妨害(DDOS)に対する保護サービスあり、アプリケーションのダウンタイムとレイテンシを最小限に抑える常時稼働の検出と自動インライン緩和策を提供している。
AWS Shieldにはふたつのレベルでのサービスが存在する
[x] Standard 全てのAWSユーザはAWS Shield Standardの保護の適応を自動的に受けることができる 機能としては、Webサイトを標的にした一般的なネットワーク及びトランスポート層のDDOSを防御することができる
[x] Advanced 従来の業務(攻撃通知、レポート生成など)DDOS Response Teamアウトソースできるのでユーザ直結する業務に専念できる また、AWS WAFサービスが無償で無制限に利用可能となる
アプリケーションの可用性低下、セキュリティの侵害、リソースの過剰消費などの一般的なWebの脆弱性からWebアプリケーションを保護するマネージド型のWebアプリケーションファイアウォール
留意点 従来のWAFとは異なり、予めWAFの定義は内臓されていないためどのトラフィックをWebアプリケーションに許可またはブロックするかをユーザ自身で行う必要がある。
AWSのEC2上にデプロイされたアプリケーションのセキュリティとコンプライアンスを向上させるための脆弱性診断サービス 診断が行える事項
参考文献 現在AWSには24箇所のリージョンと1つの ローカルリージョンをが存在する。 このローカルリージョンとは 2018年2月に開設された大阪リージョン を示す。 ローカルリージョンのリージョンの決定的な違いは以下である
[x] 1. 単独のリージョンだけの利用はできない。 大阪ローカルリージョンが、アベイラビリティーゾーン(AZ)を1つしか持たないため基本的に東京リージョンとの併用が前提となる。主な用途は金融機関や医療機関など社内規定や順守すべきセキュリティ対策基準などの関係で、海外リージョンにデータを移すことが難しい機関のために用意された特別なリージョンである。
[x] 2. 利用するのに事前の申し込みと審査が必要 金融系のサービスなど、法制度の要件によって、データの冗長性を国内のデータセンターで確保する必要がある場合に大阪ローカルリージョンが利用できる
複数リージョンに 完全に稼働にする同じシステム を構築し、災害時におけるダウンタイムを最小限にするデザイン
AWSが提供しているグローバルインフラストラクチャーは AZ 及び リージョン を中心に展開している。
リージョンとは違う場所に200箇所以上し、主にふたつの用途がある。
EC2ではクライアントが好きな時に必要な量だけ使用できるように未使用のEC2キャパシティが存在する この未使用のキャパシティ量によって変動する料金のこと
EC2(Amazon Elastic Compute Cloud)の略であり、AWS上にインスタンスという単位で仮想サーバの構築を行うことができるシステム
[ ] 必要な時に必要なだけの量を使用 従来のオンプレミス環境では予め予測してサーバ台数を見積もる必要があったが、AWSのEC2では必要な時に必要なだけのインスタンスを稼働させることができる。このためピーク時のみインスタンスを増やすなどの考えができるため、弾力性 に長けている
[ ] 変更可能なインスタンスタイプから性能を選択 EC2では様々インスタンスタイプという性能の組み合わせから選択することが可能 下図はインスタンスタイプの表記を表したもの
インスタンスの性能が低い方が一見コスパがよく見えるが、最適なコスト効率を図る上では 必要としているコンピューティンング処理を最も早く完了できるインスタンス を選択することにある。
[ ] 数分でサーバを調達して起動できる 手動でEC2のインスタンスを起動するステップは極めて用意であるためものの数分で起動できる
[ ] 世界中のリージョンから起動場所を選択 EC2の起動する場所を世界中のリージョンから選択することができる また、どのリージョンで起動しても時間差はほとんどない
[ ] AMIからいくつでも同じサーバを起動できる EC2インスタンスは先ほどのステップでも紹介したよう、AMIから起動する 1つのAMIから幾つでのインスタンスを起動できるため、 同じ構成を持ったEC2インスタンスを複数起動できる
[ ] セキュリティグループ(FW)でトラフィックの制御ができる
起動したEC2のインスタンスではキーペアを使用することで管理者権限(Admin)を利用できる
AMIで指定するOSがAmazon Linuxの場合はデフォルトユーザとして ec2-user Ubuntuの場合は ubuntu が割り当てられている
$ ssh -i .ssh/MyKey.pem ec2-user@<host>
[x] オンデマンドインスタンス 料金オプションを使わずともEC2インスタンスの起動時に発生する定額料金のこと
[x] リザーブドインスタンス 予め利用期間がわかっている場合に利用すると効果を発揮する料金オプションであり、1年または3年の使用期間を事前に設定できる。
[x] スポットインスタンス スポットインスタンスとは、AWSサーバ上に存在し、使われていないEC2インスタンスに値段をつけ、その入札価格が現在のスポット価格(※長期ではなく、1回ごとの取引で決定され成立した市場価格)を上回っている限り、そのインスタンスを利用することができるというもの
[x] Dedicated Hosts EC2 インスタンスを起動できるお客様専用の物理サーバー EC2を起動するホストを専有するオプションであり、セキュリティ、ガバナンス要件、ライセンス要件を満たす目的で利用される。ほかの料金オプションとの最大の違いは インスタンスではなく、ホストに対しての従量課金 であること
[x] ハードウェア専用インスタンス アカウント専用のハードウェアでEC2を実行する Dedicate Hotsとは違い、インスタンス単位で料金が発生する
[x] Saving Plans 1年または、3年でより柔軟にコストを節約(Saving)できる
EC2インスタンスに送られてくるユーザのリクエストトラフィック可用性を高めるために分散させる
[x] ロードバランサタイプ
[x] ヘルスチェック インスタンスが正常に稼働しているか検査(疎通確認等)を行い、正常稼働なインスタンスのみにリクエストを送るようにするし組む
[x] インタネット向け/内部向け ELBではインターネット向け(パブリックIPアドレス) か 内部向け(プライベートIPアドレス)かを選択することができる
[x] 可用性のマネージドサービス ELBを通過するトラフィックが増える事で自動的にELBノードも水平方向に増えるため多量のリクエストをユーザから受けても SPOFにならない。
[x] クロスゾーン負荷分散 ターゲットに対し、AZを越えて負荷分散すること 複数AZにまたがって登録されたEC2インスタンスに均等に負荷が分散できるため、リクエストの分散が均等になり、ターゲットインスタンスのリソースを無駄なく使用することができる。
インスタンスを必要なタイミングで必要なインスタンス分だけ動的に用意することができる。 そのため、インスタンスをもっとも効率よく使用することができる。
※ Auto Scalingではポリシーだけではなく、スケジュール も設定できる
[ ] EC2インスタンスの構成はステートレス AWSでは不要となったEC2インスタンスはスケールインされるため、インスタンス自体に 情報や状態を持たせない ステートレスな構成が求められる
[ ] ブートストラップ 起動しているアプリケーションのバージョン情報や、プログラム自体に改修を行った場合AMIの再作成、起動設定の再作成を行わずに [ユーザデータ]()を返してApplyできる機能のこと
ユーザデータを利用してApplyするshスクリプトの例
#!/bin/bash
set -ex
yum -y update
cd /var/www/html
git pull
IP_ADDRESS= $(curl -s http://<host>/latest/meta-data/public-ipv4)
echo $IP_ADDRESS >> /etc/conf/app.conf
ソースコードさえ用意することでそのプログラムを実行させることができるサービス
[ ] サーバの構築が不要 実行したいプログラムのラインタイムを選択してソースコードのアッップロードするだけで実行ができる
[ ] サーバの管理が不要 以下のようなサーバ管理が不要になる
[ ] 一般的な言語サポート 対応している言語
[ ] 並列処理/スケーリング リクエスト数に応じて自動的にLambda関数が増えるのでAuto Scalingの設定は不要になる
[ ] 柔軟なリソースの設定 Lambdaで設定する性能は メモリであり、128MB ~ 3008MB間で64MB刻みで設定を行える。 尚、タイムアウト時間は最長で15分に設定することができるため、15分以内で終了する処理が前提となる。
[ ] ミリ秒単位の無駄のない課金
[ ] 他のAWSサービスとの連携 イベントをトリガーにできるもの
[ ] 特定の時間になった時(Cloud Watch Events)
[ ] [S3]()にデータがアップロードされた時
[ ] [DynamoDB]()に新しいアイテムが書き込まれた時
[ ] Auto Scalingアクションが実行された時
[ ] Webページでボタンが押下された時
[ ] Kinesisにレコードが追加された時
[ ] Alexaに質問を投げた時
EC2インスタンスにアタッチして使用する ブロックストレージボリューム
インスタンスのホストローカルのストレージであり、データは一時的なものとして扱われる。
Amazon Simple Service が正式名称であり、インターネット対応の完全マネージド型のオブジェクトストレージ
[ ] 無制限のストレージ容量 バケット(bucket)を作成することでデータを保存することができる。 尚一つのファイルについては5Tバイトまでという制限はあるが頻繁にアクセスを行うファイルで5TBを超えるデータはまず存在しないため、問題にはならない
[ ] 高い持久性 S3ではリージョンを選択してバケットを作成し、データをオブジェクトとしてアップロードする。 そのオブジェクトは1つのリージョン内の複数のAZにまたがって自動的に冗長化してデータを保存する。 尚S3の持久性はイレブンナインである。
[ ] インターネット経由でのアクセス S3へのアクセスはHTTP/HTTPSで行い、マネージメントコンソールやAWS CLI、SDK , APIからのアクセスすることができる。
下記は インタネットゲートウェイとNATゲートウェイの比較
AWSクラウド内にプライベートなNWを構築可能にするサービス
リージョンを選択して複数のAZを跨って作成することができる。 また、IPアドレスの範囲はCIDERで定義する
VPCで設定したアドレス範囲をサブネットにわけて定義する。 サブネットの定義を行う際には、AZとIPアドレス範囲を選択する必要がある。 またAWSでは以下のIPアドレスは予約されている
VPCとパブリックネットワークを接続するためのゲートウェイであり、インタネットゲートウェイ自体が高い可用性を持っているため SPOF にならない
サブネットの経路をルートテーブルで設定する。 ルートテーブルはVPCを選択して作成する。また、テーブル作成時にデフォルトとして「メインルートテーブル」が生成されるが、サブネットに関連付けられたデフォルトのテーブル であるため、そのまま使用せず、カスタムのルートテーブルを作成する。
仮想FWであり、デフォルトではインバウンド(受信)へのアクセスが全て拒否されている状態である。 送信元にはCIDRでIPアドレスを範囲指定するほかに、他のセキュリティグループIDを指定することができる。 また、インバウンドへのアクセスが拒否されていることから「ホワイトリスト」を設定するなどと呼ばれる
サブネットに対して設定する仮想FWのため、サブネット内の全てのリソースに対してのトラフィックに影響する そのため、必要でない場合はデフォルトの状態で問題がない。
世界中に150箇所以上あるエッジロケーションを使い、最も低いレンテンシーでコンテンツを配信できるコンテンツ配信ネットワークサービス(CDN)
クライアントが所有しているドメインの証明書を設定できるため、HTTPSのアクセスを受けることができ通信を保護できる。証明書はAWS Certificate Manager を使用すると追加料金なしで作成できる。
DNSサービス(ドメイン対してのIPアドレスをマッピングしてユーザからの問い合わせに回答する)であり、エッジロケーションで使用されている。
[x] 様々なルーティング機能
[x] 高可用性を実現するヘルスチェックとフェイルオーバー ルーティングではヘルスチェックと組み合わせることができるため、プライマリーDNSがヘルスチェックで失敗となった場合、瞬時にセカンダリーDNSへ切り替えることができる。また、ロケーションを問わず世界中のレージョンを使用できるため、システム全体の可用性は極めて高い
[x] ルートドメイン(Zone Apex) のエイリアスレコード Route 53ではAレコードなどの各レコードセットにエイリアスを設定することができるため、高可用性を実現できる
対応しているデータベース
インフラ管理から開放されるため、本来の開発に注力できる。
インフラ管理の開放を実現した3つの構成要素
AWSが クラウドに最適化して再設計を行ったRDBエンジンであり、MySQLとPostgresSQLとの互換性を持つ
データベースの移行を容易に行うためのサービス
フルマネージドなDBであり、リージョンを選択することができる。 またNoneSQLでデータを扱えるため、テーブルを作成する手間が省ける 水平スケーリングで大量の問い合わせにも対応できるが、複雑なクエリには向かない。
EC2のインスタンス、RDSのインスタンス、DynamoDBテーブルなどの各インスタンスの現在の状態、情報をモニタリングするサービス
[x] 標準(組み込み)メトリクスの収集、可視化 AWSが提供している範囲で知り得る情報を 標準メトリクスとして提供している EC2インスタンスの例をあげると、標準メトリクスとしてCPU使用率、ハードウェアやネットワークのステータス情報が収集される。
[x] カスタムメトリクスの収集、可視化 EC2ではメモリやアプリケーションのステータスなどの OS以上の範囲及び、クライアントがコントロールしている範囲 については標準メトリクスとしては収集されない。 そのため、[CloudWatchエージェント]()と呼ばれるメトリクス収集プログラムにから取得する。
[x] ログの収集 CloudWatchエージェントをインストールすることで、EC2のアプリケーションログ、Lambdaのログ、VPC Flow Logなどを収集可能
[x] アラーム CloudWatchではメトリクス対してアラームを設定可能であるため、モニタリングに基づく運用を自動化できる
EC2のCPU使用率が10分間80%を上回る時
ログにOutOfMemoryろいう文字列が5分間で2回以上出現した時
RDSのディスク空き容量が残り10GB未満になり、そのまま5分が経過した時
クライアントのAWSアカウント環境の状態を自動的にチェックして回り、ベストプラクティスに対してどうであったかを示すアドバイスをレポートするサービス
※ そのほかでは、IAMパスワードポリシーが有効化されているかなどもチェックを行う
[ ] フォールトトレランス(対障害性) 対障害性を高めるための以下のようなアドバイスを提供する
[ ] サービス制限 AWSアカウントを作成した時点でいくつかのサービス制限があり、これを ソフトリミット と言う サービス制限では 制限に近づいたサービスがアラート報告を受ける この制限が存在する意図については以下の2点である。
[ ] CloudTrail AWSアカウント内の全てのAPI呼び出しを記憶するためのツール
[ ] AWS Config AWSリソースの変更(VPC等)を自動で記録するツール
[ ] CloudFormation AWSの各リソースを含めた環境を自動作成/更新/管理するツールでJSON形式またはYAML形式で記述されたテンプレートから Stack というリソースの集合体を作成する。 また、AWS環境を何度でも自動で構築することができる。
[ ] Elastic Beanstalk Webアプリケーションの環境を簡単にAWSに構築するためのツールであり、CloudFormationと違う点は独自でテンプレートの作成を行う必要がなく、パラメータを変更することでApache, Nginx ...etc 各言語の実行環境も合わせて構築ができる、
クライアントがDC、サーバ等の設備を用意する必要がないため、初期コストは発生しない。また、必要な時に必要な分だけのリソースを使うことができるため、 資本の支出を変動費 にすることできる。 そのため、この消費モデルを組織全体で受け入れることでコストの最適化が進む
サービスによって用途が違うため、必然的に課金方式も異なることになる またリージョンによっても料金は異なる。
EC2の購入オプション, S3ストレージクラス. EBSボリュームタイプ などから要件に応じて適切な料金モデルを選択できる
どのサービスにどれくらいのコストを費やしたかは請求書で確認することできる。 また、月の途中であっても課金の状況を確認できる。
コスト配分タグにより、ROIの請求分析ができる
請求金額もCloudWatchメトリクスの一環であるため、アラームを仕込みAWSリソースの使いすぎ防止に努めることができる。 また、予め設定した予算よりもAWSリソースの料金が超過すると予測された時にアラームできる機能として[AWS Budgets]()がある。
AWSのアカウントは個人や組織で複数のアカウントを作成することができるが、管理面で煩雑的になりやすい。 そのため AWS Organizations を使用することで複数のアカウントを一括で管理することができる。
複数のアカウントを一括で管理する AWS Organaizations機能例
AWSアカウントには4つのサポートプランが存在する。クライアントは適切なサポートプランを選択することによって 運用の安全性を保ち エスカレーションパス (問い合わせ先)を確保することができる
AWSでどれくらいのコストがかかるのかを事前に見積もってくれるツール
AWSへの移行、導入を検討している際にオンプレミス環境で構築した場合とのコストを比較してくれるツール
# 特定のEC2インスタンスにログインを行いs3バケット一覧を表示するコマンドを実施
[ec2-user@########## ~]$ aws s3 ls
Unable to locate credentials. You can configure credentials by running "aws configure".
※エラーログから推察できるようにクレデンシャル情報がcredentalsというconfigファイルに登録されていないため認証エラーとして弾かれてしまう。
そんため最低でも以下のクレデンシャルを最低限設定する。
# IAMアクセスキーをセットする
$ aws configure set aws_access_key_id <you`re IAM Access Key>
# IAM シークレットアクセスキーをセットする
$ aws configure set aws_access_key_id <you`re IAM Secret Access Key>
クレデンシャル情報が反映されているか確認する
$ cat ~/.aws/credentials
[default]
aws_access_key_id = XXXXXXXXXXXXX
aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXX
aws cliが通るかs3のバケット一覧取得コマンドで再度検証してみる
[ec2-user@######## ~]$ aws s3 ls 1>/dev/null && echo "Succeed"
Succeed
実際にs3コマンドでbucketを作成してみる
[ec2-user@######## ~]$ aws s3 mb s3://aws-tbucket
make_bucket: aws-tbucket
bucketが正常に作成したかコンソールとCLIの両方で確認を行う
[ec2-user@####### ~]$ aws s3 ls | grep aws
2020-08-19 04:35:36 aws-tbucket
AWS Console
data.txtというダミーデータを用意し、先ほど作成したaws-tbucketにアップロードする
[ec2-user@####### test_resource]$ aws s3 cp ./data.txt s3://aws-tbucket/
upload: ./data.txt to s3://aws-tbucket/data.txt
アップロードしたファイルを実際にダウンロードしてみる。
$ rm data.txt
ec2-user@###### test_resource]$ aws s3 cp s3://aws-tbucket/data.txt ./
download: s3://aws-tbucket/data.txt to ./data.txt
[ec2-user@###### test_resource]$ ll
total 4
-rw-rw-r-- 1 ec2-user ec2-user 20 Aug 19 05:03 data.txt
バケットの削除を行う バケットの中にオブジェクトがあると普通には削除することができないため(--force)で強制して削除を行う
[ec2-user@###### test_resource]$ aws s3 rb s3://aws-tbucket
remove_bucket failed: s3://aws-tbucket An error occurred (BucketNotEmpty) when calling the DeleteBucket operation: The bucket you tried to delete is not empty
[ec2-user@###### test_resource]$ aws s3 rb s3://aws-tbucket --force
delete: s3://aws-tbucket/data.txt
remove_bucket: aws-tbucket
[ec2-user@####### test_resource]$ aws s3 ls | grep aws
[ec2-user@####### test_resource]$
定義 本学習ログは、「AWS認定 クラウドプラクティショナー」と呼ばれるテキストに沿って解釈したものである。
第2章クラウドの概念について 2020/07/27~2020/07/28
クラウドとは?
オンプレミスとは?
※そのため、クラウドはよくオンプレミスの対義語として扱われる。
リージョンとは?
AZ(アベイラビリティーゾーン)
リージョンの内の独立した区間を示すもので、主に可用性の指標となる
SPOF(Single Point Of Failure)
SOA(Service Oriented Architecture)
スケールアップとスケールアウト
単体性能の向上を図るのが、スケールアップ でサーバの台数を増設して全体のスループットの向上を図るのがスケールアウト
キューイングチェイン(Queuing Chain)
AWSを疎結合なシステムとして実現するために用いているメッセージキューイングのデザインパターンである。
EC2インスタンスの処理を例にとった場合 ある処理を担当するEC2インスタンスから、次の処理を担当するEC2インスタンスへの処理の受け渡しはSQSを仲介(Chain)して行う。 もう少し技術的な観点から述べるのであれば ジョブ(メッセージ)の受信 → ジョブの処理 → ジョブ(メッセージ)の送信
EC2
AWSで利用できるシステムのひとつであり、AWS上に仮想サーバーを構築して自由に利用できるのが特徴 また、EC2では仮想サーバのことをインスタンスという単位で呼ぶ EC2というシステムをわかりやすく解説してくれているサイト
モノリシックとマイクロサービスについて
(左図)モノリスとは 一枚岩 という意味であるようにアプリケーション内部に複数の基幹システムを集合させた設計を示す。 このアーキテクチャの欠点としてはシステムの仕様が変更された場合に本当はある一部分の基幹システムだけを改修すればよいが、他の基幹システムと密接な関係で設計されているためインタフェースなどの見直しが必要となる点がひとつでもう一つはモジュール毎の単体テストを行い辛いという欠点がある。
対してマイクロサービスは基幹システムとういう思考ではなくそれらを 一つのサービス と捉えて違いに素の関係を作る設計 である。各サービスはREST APIとしてWebアプリからリクエスト(GET,POST,DELETE,PUT)を受ける形をとる。 そして言うまでもないが、互いに素の関係でサービスを設計しているので、単体テストも他のモジュールに依存しないため、行いやすいく、改修が発生した場合も局所的な改修で済む
データウェアハウス(DWH)
様々なシステムからデータを保存し、それを分析するために整理する、いわばデータの「倉庫」である。 DBとの欠点的な違いについてはDBだとデータの保存や編集などさまざまな機能を有するが、DWHの場合は
データの分析
に特化しているため、各システムのデータを時系列的に収集し、サブジェクト別に整理することで、より詳細な分析が可能となるAWSの長所と利点について
1.固定費(設備投資費)が柔軟な変動費に変わる
従来の環境(オンプレミス)では事前にデータセンタやサーバに多額のコストを支払う必要があったが、クラウドでは利用したい時に利用した分の従量課金となるため、無駄なコストを削減できるようになる。そのため、TCOの面でも経済的になる。2.スケールによる大きなコストメリットがある
数十万単位のユーザがクラウドを利用しているため、一人一人が利用する金額を低額に設定できる。3 .キャパシティの予測が不要になる
オンプレミス環境の場合だと、予め最大ピークのLatencyなどを見積もってサーバを構築したり、DCを配置する必要があるが、 クラウドでは、必要な分だけ利用できるというメリットがあるため必要になった際に、スケールアウトやスケールアップを行うだけでよくなる。そのため、初期投資の際に発生する無駄なコストを見直すこともできる。4.速度と俊敏性の向上が期待できるようになる
AWSを利用することで、今まで数週間かかっていたITリソースの調達をわずか数分で行えるようになる。 そのため、アジャイルなどのスピードを求めた開発モデルに恩恵を受けやすい。5.データセンタの運用と保守への投資が不要になる
AWSを利用する際に、料金プランの中に、サーバの運用や保守などの手間賃も含まれているためユーザはサーバの設置、連携、起動などの時間がかかる操作を行わずに済む。 そのため、ユーザに直結した業務(アプリ開発)などに専念することができる。6.わずか数分で世界中にデプロイができる
クラウドアーキテクチャの設計原理について
形あるものは全て壊れるということを大前提におき、設計を行う 具体的な内容としては
ハードウェアはいつか故障する
,停電によりシステムはダウンしてしまう
,などと故障ありきで設計を行うことを Design for Failure(故障に備えた設計) といい、クラウドでこの設計を実現するためにはSPOFを作らないようにすることが大切である。コンポーネントの分離
クラウドの設計においてスケーリングを大規模に行う際に重要となるのは、そのシステムが疎結合で構築されているかどうかである。AWSでは各コンポーネントを疎結合にするためにAmazonSQSと呼ばれるキューイングチェーンを利用することで 非同期 かつ 疎結合なシステムを実現している。
弾力性の実装
ここで 弾力性 という言葉がでできたが、よくわからないので調べることにした。
クラウドはインフラストラクチャーに 弾力性(Elastic) という新しい概念を持たせることができる。 弾力性を以下の方法で実現が可能となる
常に並列化を考慮する
参考文献 クラウドでは
繰り返し可能なプロセスを用意に構築することができる(スケーリング等)
そのため、できるだけ並列化を図り尚且つ可能であれば自動化を実践すること重要である。動的なコンテンツデータをクラウドコンピューティングリソースの近くに保管し、静的なコンテンツデータをエンドユーザの近くに保管する
AWS Well-Architectedフレームワーク