AWSコアサービス４
AWS責任共有モデル
セキュリティに対してAWSとユーザーとで責任分界して対応する責任共有モデルとなっている。
【ユーザー側の責任範囲】
・構築したアプリケーション
・ユーザーアクセス、ロールベースのアクセス
・ユーザーが利用するAWSサービス
【AWS側の責任範囲】
・AWSインフラストラクチャ（ハードウェア、ソフトウェア、ネットワーク）
・AWSデータセンター
◾️ユーザー側でやるべきセキュリティ対応
セキュリティに対してAWSとユーザーとで責任分界して対応する責任共有モデルとなっている。
・IAMによるアカウント管理 / パスワードルールの設定
・セキュリティグループの設定など適切なネットワーク設定やトラフィック保護
・構築したアプリケーションのセキュリティ対応
・ネットワーク / インスタンスオペレーションシステム（バッチ）などの設定
責任共有モデルの統制範囲
セキュリティに対してAWSとユーザーとで責任分界して対応する責任共有モデルとなっている。
◾️継承される統制
→ユーザーがAWSから完全に継承する統制
物理統制と環境統制がある
◾️共有統制
・バッチ管理
→AWSがインフラストラクチャの不具合に対するパッチ適用および
修復に責任を負うが、ユーザーはゲストOSおよびアプリケーションの
パッチ適用に責任を負う
・構成管理
ユーザーは独自のゲストオペレーティングシステム、データベース、
アプリケーションの構成に責任を負う
・意識とトレーニング
ユーザーの従業員のトレーニングはユーザーが実施する
◾️ユーザー固有の統制
→AWSサービスにデプロイするアプリケーションに基づいて、
ユーザーが全ての責任を負う統制
データをルーティングまたは区分する必要があるサービスおよび
データ通信の保護またはゾーンセキュリティなど
IAMの概要
AWS Identity and Access Management（IAM）は安全にAWS操作を実施するための認証・認可の仕組み。
・AWS利用者認証の実施
・アクセスポリシーの設定
・ユーザー個人またはグループ毎に設定
主要トピック
IAMの主要トピックはユーザー、グループに加えてポリシーとロールの４つ。
ユーザー
・ルートユーザー
・IAMユーザー
ルートユーザー
最初に作成されるのがルートユーザーであり、通常の管理には利用しないアカウント。
・AWSアカウント作成時に作られるIDアカウント
・全てのAWSサービスとリソースを使用できる権限を有するユーザー
・日常的なタスクはルートユーザーを使用しないことが強く推奨される
※パワーユーザーはIAMユーザーやグループの管理以外の全てのAWSサービスにフルアクセス権限を有するユーザーで別のもの。
ルートユーザーにしかできない操作権限が存在する。
【ルートユーザーのみの実施権限】
・AWSルートアカウントのメールアドレスやパスワードの変更
・IAMユーザーの課金情報へのアクセスに関するactivate / deactivate
・他のAWSアカウントへのRoute53のドメイン登録の移行
・CloudFrontのキーペアの作成
・AWSサービス（サポート等）のキャンセル
・AWSアカウントの停止
・コンソリデイテッドビリングの設定
・脆弱性診断フォームの提出
・逆引きDNS申請
IAMユーザー
IAMポリシー内でAWSサービスを利用できるユーザー。
基本操作はIAMユーザーで実施することになる。
IAMポリシー
IAMポリシーを作成してユーザーなどへのアクセス権限を付与（JSON形式の文書）
◾️管理ポリシー
・AWS管理ポリシー
→AWSが作成および管理する管理ポリシー
・カスタム管理ポリシー
→AWSアカウントで作成・管理する管理ポリシー
同じポリシーを複数のIAMエンティティにアタッチできる
◾️インラインポリシー
・自身で作成および管理するポリシー
→１つのプリンシパルエンティティ
（ユーザー、グループ、またはロール）に埋め込まれた
固有ポリシーで、プリンシパルエンティティに
アタッチすることができる
IAMポリシーはJSON形式で設定される。
・Effect
Allow → 許可
Deny → 拒否
・Action
対象のAWSサービス
例：s3:Get
・Resource
対象のAWSリソース
ARNで記述
・Condition
アクセス制御が有効となる条件
ユーザーベースとリソースベースのポリシー適用がある。
IAMロール
AWSリソースに対してアクセス権限をロールとして付与できる。
ユーザーのアクティビティの記録
・Access AdvisorのService Last Accessed Data
→IAMエンティティ（ユーザー、グループ、ロール）が
最後にAWSサービスにアクセスした日付と時刻を表示する機能
・Credential Report
→利用日時などが記録されたIAM認証情報に係るレポートファイル
・AWS Config
→IAMのUser、Group、Role、Policyに関して変更履歴、
構成変更を管理・確認することができる機能
・AWS CloudTrail
→AWSインフラストラクチャ全体でアカウントアクティビティを
ログに記録し、継続的に監視し、保持することができる機能
アクセス権限の一時付与
一時的なアクセス権限の付与を可能にする。
・AWS Security Token Service（STS）
→動的にIAMユーザーを作り、一時的に利用するトークンを発行するサービス
・Temporary Security Credentials
→AWSに対して一時的な認証情報を作成する仕組み
IAMとAWS Organizations
IAMはAWSアカウント内のユーザー管理を実施。
Organizationsは複数のAWSアカウント自体の管理を実施。
AWS Organizations
AWS OrganizationsはIAMのアクセス管理を大きな組織でも楽に実施できるようにするマネージド型サービス。
・複数のアカウントの一元管理
→AWSアカウントをグループ化してポリシーを適用して一元的に管理する
・新規アカウント作成の自動化
→コンソール / SDK / CLIでAWSアカウントを新規作成して、
作成内容をログ管理できる
・一括請求
→複数AWSアカウントの請求を一括化する
組織という単位を構成して、マスターアカウントがメンバーアカウントを管理するという仕組み。
CloudTrailの概要
AWS CloudTrail
AWSユーザの操作（API操作やユーザのサインインアクティビティ）をロギングするサービス。
・ルートアカウント / IAMユーザのオペレーションをトラッキングして
ログを取得するサービス
・CloudTrailログファイルは暗号化されてS3に保存
・KMSによる暗号化もサポート
・無料
ユーザとアクセスとAPIコールのログ情報をS3バケットに保存し、CloudWatch上で解析できる。
マルチアカウントで利用可能で、複数AWSアカウントの情報を集約可能。
CloudWatchの概要
AWSリソースとAWSで実行するアプリケーションのモニタリングサービスで、様々なログやメトリクスを監視できる。
・CloudWatch（メトリクス監視）
→AWS上で稼働するシステム監視サービスで、死活監視、性能監視、
キャパシティ監視を実施
有料枠では確認内容や設定の柔軟性が充実化する
・CloudWatchLogs
→CloudWatchと連動したログ管理プラットフォームサービス
EC2上のOS・アプリケーションのログやAWSマネージドサービスの
ログを取得する
・CloudWatchEvents
→CloudWatchはAWSリソースに対するイベントをトリガーに
アクションを実行
オペレーションの変更に応答し、応答メッセージ送信、
機能のアクティブ化
変更、状態情報収集による修正アクションを実行する
データを取得・表示・アクションの実行までを集中管理。
CloudWatchメトリクスを利用して、多くのメトリクスを取得することが可能。
◾️標準メトリクス
・CPUUtilization / ディスク利用率 / 読み込みIOPSなど
一般的なメトリクスの多くが取得可能
・５分間隔でのメトリクス取得
◾️カスタムメトリクス（拡張モニタリング実行時）
・標準では取得できないメトリクス
・１秒から６０秒でのリアルタイムでのメトリクス取得
必要なRDSのメトリクスを選択してダッシュボードで可視化することが可能。
AWSコアサービス３
S3の概要
AWSストレージサービス
AWSは３つの形式でストレージサービスを提供。
●ブロックストレージ
・EC2にアタッチして活用できるディスクサービス
・ブロック形式でデータを保存
・高速、広帯域幅
・EBS、インスタンスストア
●オブジェクトストレージ
・安価かつ高い耐久性をもつオンラインストレージ
・オブジェクト形式でデータを保存
・S3、Glacier
●ファイルストレージ
・複数のEC2インスタンスから同時にアタッチ可能な共有ストレージサービス
・ファイル形式でデータを保存
・EFS
Simple Storage Service（S3）
ユーザがデータを容量制限なく保存可能なマネージド型で提供されるオブジェクト型ストレージ。
◾️特徴
・高い耐久性
９９.９９９９９９９９％
・安価なストレージ
容量単価：月額１GB / 約２.５円
・スケーラブルで安定して性能
データは冗長化されて保存されデータ容量に依存しない性能が
AWS側で保証される
・暗号化
転送中や保存時にデータを暗号化可能
◾️データ保存形式
・バケット
オブジェクトの保存場所
名前はグローバルでユニークな必要あり
・オブジェクト
S3に格納されるファイルでURLが付与される
バケット内オブジェクト数は無制限
・データサイズ
データサイズは０KBから５TBまで保存可能
S3のオブジェクト構成
◾️Key
オブジェクトの名前であり、バケット内のオブジェクトは一意に識別する
◾️Value
データそのものであり、バイト値で構成される
◾️バージョンID
バージョン管理に用いるID
◾️メタデータ
オブジェクトに付随する属性の情報
◾️サブリソース
バケット構成情報を保存および管理するためのサポートを提供
アクセス制御リスト（ACL）
S3のデータ構造
S3はバケット単位で保存スペースを区別し、オブジェクトでデータを格納する
S3→バケット→オブジェクト
AWSストレージサービス
・STANDARD（※通常これを選ぶ）
複数箇所にデータを複製するため耐久性が非常に高い
・STANDARD-IA
スタンダードに比べて安価
データの読み出しに容量に応じた課金
・One Zone-IA
アクセス頻度は低いが、必要に応じてすぐに取り出すデータ向け
・RRS
Reduced Redundancy Storage 低冗長化ストレージ
Glacierから取り出したデータ配置等
・Amazon Glacier
最安のアーカイブ用ストレージ
データ抽出にコストと時間（３〜５時間）を要する
ライフサイクルマネジメントで指定
ボールロック機能でデータを保持
S3 Inteligent-Tiering
低頻度アクセスのオブジェクトを自動的に低頻度アクセス層に移動することでコストを削減する。
※３０日間アクセスがないと自動的に低頻度アクセス層に移動する
データベースの基礎
データベース
データベースは関連したデータの形式を揃えて収集・整理して検索などの操作やデータ管理を実行するシステム。
データベースを実現したシステムをDBMS（データベースマネジメントシステム）という。
基本的なデータベースはテーブルという表形式でデータを格納している。
データベースは追加・参照・更新・削除などのデータ操作を容易に実行するソフトウェアやデータモデルと一体。
総称してCRUDと呼ぶ。
データベースとストレージ
ストレージはデータベースの記憶装置を構成する１つの要素。
◾️ストレージ
・コンピュータの主要な構成要素の１つでデータを永続的に記憶する装置
◾️データベース
・データベース内のデータを保存する装置はストレージであるが、
データベースそのものではない
・ストレージ＋データを管理、操作するデータベースソフトウェア
データベースの役割
データベースはデータ操作を異常なく実行でき、データを安全に保護しつつ、保存、操作ができる仕組みを提供している。
データベースの役割を支える仕組みを理解する。
◾️トランザクション
データベースをある一貫した状態から別の一貫した状態へ変更する
１つの処理の束のこと
◾️データモデル
実世界におけるデータの集合をDBMS上で利用可能な形に
落とし込むためのモデル
トランザクション
データベースをある一貫した状態から別の一貫した状態へ変更する１つの処理の束のこと。
・同時アクセスした場合に上手く処理する
・データ処理に失敗したら、元に戻してくれる
・システムがクラッシュしてもデータを保護する
トランザクション：ACID
ACIDは信頼性のあるトランザクションシステムの持つべき性質のこと。
◾️Atomicity（原子性）
トランザクションが「全て実行される」か「１つも実行されない」の
どちらかの状態になるという性質
◾️Consistency（整合性）
トランザクションの前後でデータの整合性が保たれ、
矛盾のない状態が継続される性質
◾️Isolation（独立性）
トランザクション実行中の処理過程が外部から隠蔽され、
他の処理などに影響を与えない性質
◾️Durability（耐久性）
トランザクションが完了したら、その結果は記録されクラッシュしても
失われることがないという性質
トランザクション：耐久性
データを更新する際にCOMMITとする更新が反映されるがCOMMITされないとデータがロールバックして保護する。
トランザクション：整合性
同時に複数人がアクセスした場合などにデータ整合性を維持する必要がある。
同時に複数人がアクセスした場合など、データのデータ整合性を維持するための方式（結果整合性や強い整合性など）
データモデル
データモデルはデータベースのデータの持ち方などの構造や処理を定めるデータの論理的な表現方法。
データベースには様々なデータモデルが存在し、利用目的に応じて使い分ける。
・リレーショナルモデル
・グラフモデル
・キーバリューストア
・オブジェクト
・ドキュメント
・ワイドカラム
・階層型
RDSの概要
RDSは様々なデータベースソフトウェアに対応したフルマネージドなリレーショナルデータベース。
以下のような標準ソフトウェアを利用したデータベースを構築できる。
AWSのデータベース構築
AWSにおけるデータベース構築はEC2に自らインストールして構築するか、専用DBサービスを利用するかの２通り。
・EC2
メリット：自由にDB構成や機能を利用
デメリット：構築・運用が手間
・RDS等
メリット：構築・管理が楽（大部分がAWS側）
デメリット：AWS提供の範囲内での利用制限
RDSの制約事項
RDSはマネージド型で楽な反面、AWSから提供される機能範囲内での制限を受ける。
【RDSの主な制限事項】
・バージョンが限定される
・キャパシティに上限がある
・OSへのログインができない
・ファイルシステムへのアクセスができない
・IPアドレスが固定できない
・一部の機能が使えない
・個別パッチは適用できない
RDSの特徴
RDS自体がマネージド型の高可用なのに加え、マルチAZによるMaster / Slave構成を容易に構築することができる。
同期レプリケーションや自動ファイルオーバーなどのような構成にすることによって信頼性や耐障害性を高められる。
さらに、非同期レプリケーション（リードレプリカ）を作ることによってリードレプリカをデータを参照するので読み込み速度をスケーリングすることができる。
最大１５台（Aurora）、RDSは５台設置できる。
また、自動 / 主導でスナップショットを取得して保存管理し、耐障害性を確保できる。
スケーリング
マネージドコンソールやAPIからスケールアップ可能。
・インスタンスタイプを変更してスケールアップ / ダウンを実施
・コマンドライン（AWS CLI）やAPIからストレージを数クリックで容易にスケールアップ / ダウンをする
・一時的にインスタンスタイプを大きくしてその後戻すことも可能
・ストレージサーズは拡張はできるが縮小はできない
データベースシャーディングを利用してRDSの書き込み処理をスケーリングする。
ユーザーのIDによってデータベースのアクセス先を変えることができる。
DBインスタンスの暗号化
保管時のインスタンスとスナップショットの暗号化が可能。
【暗号化対象】
・DBインスタンス
・自動バックアップ
・リードレプリカ
・スナップショット
【暗号化方式】
・AES-256暗号化
・AWS KMSによる鍵管理
・リードレプリカも同じ鍵を利用
・インスタンス作成時にのみ設定可能
・スナップショットのコピーの暗号化 / リストア可能
AWSコアサービス２
AWSアーキテクチャの設計原則
５つの設計原則
Well-Architected Frameworkは次の５つの原則で構成される。
・回復性の高いアーキテクチャを設計する → Reliability
・パフォーマンスに優れたアーキテクチャを定義する → Performance Efficiency
・セキュアなアプリケーションおよびアーキテクチャを規定する → Security
・コスト最適化アーキテクチャを設計する → Cost Optimization
・オペレーショナルエクセレンスを備えたアーキテクチャを定義する → Operational Excellence
●Reliabitity（信頼性）
●Perfomance Efficiency（パフォーマンス効率）
●Security（安全性）
●Cost Optimization（コスト最適化）
●Operational Excellence（運用上の優秀性）
Well-Architected Framework
次の３つの内容で構成される。
❶Well-Architected Framework ホワイトペーパー
❷AWSのSAまたは認定パートナーによる支援制度
❸セルフチェック向けのWell-Architected Tool
ベストプラクティスを利用することで最適解や改善点を把握する。
あくまで参考であり絶対というものではない。
・要件定義
AWSを利用したシステム要件を検討する材料として
ホワイトペーパーを確認して最適な要件検討に利用する。
・設計
設計においてホワイトペーパーを確認しながら、適切な設計方式を検討する。
・構築
リリース前にAWSのインフラ構成にリスクや改善点がないか
ホワイトペーパーに基づいて確認する
・運用
運用中に定期的にホワイトペーパーに沿ったレビューを実施し、
リスクや改善点がないか確認する
AZの選択
１つのリージョンにつき２つのAZを利用してアーキテクチャーを設計することが基本。
※３つ以上はコスト効率が低下する。
マルチAZ構成
マルチAZにサーバーやDBの冗長構成を確立させることで高い可用性を実現する。
マルチリージョン構成
Route53を介して、２つの同じシステム構成をフェイルオーバーすることが可能。
Well-Architected Toolの確認
Well-Architected Toolは構築中または運用中のアプリケーションがベストプラクティスに沿っているかを検証できるツール。
Well-Architected Toolの定義
Well-Architected Toolの独特の用語を理解して、利用していく。
●ワークロード
ウェブサイト、ECサイト、モバイルアプリのバックエンド、分析プラットフォーム
などビジネス価値をもたらす一連のコンポーネントが特定する
設計、テスト、実稼働、本稼働の製品ライフサイクルを通じて
進捗するアーキテクチャでの重要な変更内容のこと
●レンズ
改善すべき分野を特定する一貫した方法
●高リスクの問題（HRI）
ビジネスに最大な悪影響を及ぼす可能性があるアーキテクチャおよび運用上の問題
●中リスクの問題（MRI）
その程度はHRIより低いビジネス上の問題
ELBの概要
ELB（Elastic Load Balancing）
マネージド型のロードバランシングサービスで、EC2インスタンスの処理を分散する際に標準的に利用する。
・インスタンス間の負荷を分散する
・異常なインスタンスを認識して対応する
・パブリック / プライベートどちらでも使用可能
・ELB自体も負荷に応じてキャパシティを自動増減するスケーリングを実施
・従量課金で利用可能
・マネージドサービスなので管理が不要
・Auto Scaling、Route53、Cloud Formationなどと連携
ELBの主要機能
●ヘルスチェック
EC2インスタンスの正常 / 以上を確認し、利用するEC2の振り分けを行う
●負荷分散
配下のEC2の負荷に応じて、複数のAZに跨るEC2インスタンスの負荷分散を行う
●SSLサポート
ELBでSSL Terminationできる
●スティッキーセッション
セッション中に同じユーザから来たリクエストを全て同じEC2インスタンスに送信
●Connection Draining
インスタンスが登録解除されるか異常が発生した場合に、
そのバックエンドインスタンスへの新規リクエスト送信を中心する
●S3へのログ保管
ELBのアクセスログを指定したS3に自動保管
負荷分散によるスケーラビリティとヘルスチェックによる高可用性を実現。
スケーラビリティの確保
複数のEC2インスタンス / ECS Serviceへの負荷分散
トラフィックの量を分散できる
高可用性
複数のアベイラビリティゾーンにある複数のEC2インスタンスECS Serviceの中から
正常なターゲットにのみ振り分け
ELBのタイプ
現在利用できるロードバランサーは３タイプで用途に応じて使い分ける。
CLB（Classic Load Balancer）
初期に提供されたELBであり、標準的なL4 / L7におけるロードバランシングが可能だが複雑な設定はできない。
・HTTP / HTTPSとTCP / SSLプロトコルのL4とL7に対応
・ELBとバックエンドのEC2インスタンス間で
・CLB配下のインスタンスは、全て同一の機能を持ったインスタンスが必要
・異なる機能に対してコンテントベースルーティングは出来ない
ALB（Application Load Balancer）
レイヤー７の対応が強化された単一ロードバランサーで、異なるアプリケーションへリクエストをルーティングが可能。
・URLのパスに基づいてルーティングが可能なパスベースルーティングが可能
・WebSocketとHTTP/2のリクエストを受付
・１インスタンスに複数ポートを登録可能
・EC2インスタンスをターゲットグループに割り当てる際、
複数ポートを個別のターゲットとして登録することが可能なため、
ポートを利用するコンテナをロードバランシング可能
・ターゲットグループでのヘルスチェックが可能
・アクセスログの情報追加
・EC2と同様に削除保護が可能
・ALB自体が自動的にキャパシティを増減
CLBとALB
ALBはパスルーティングによりCLBより容易にバランシング構成が可能。
NLB（Network Load Balancer）
NLBは超低遅延で高スループットを維持しながら秒間何百万リクエストを捌く様に設計された新しいロードバランサー。
・開放型システム間相互接続（OSI）モデルの固定IPアドレスをもつL4ロードバランサ
・揮発性ワークロードを処理し、毎秒数百万のリクエストに対応できる能力
・VPC外のターゲットを含めたIPアドレスや静的IPアドレスでの登録可能
同一ターゲットグループに登録可能
・大規模アクセスが予測される際にCLBやALBで必要だったPre-warming申請が不要
・ALBやCLBはX-Forwarded-Forでアクセス元IPアドレスを判断していたが、
NLBは送信元IPアドレスと送信元ポートの書き換えを行わないため、
パケットからアクセス元が判断可能
・NLBはフォルトトレランス機能を内臓したコネクション処理をもち、
数ヶ月から数年のオープンなコネクションを処理できる
・コンテナ化されたアプリケーションのサポート
・各サービスの個別のヘルスステータスのモニタリングのサポート
Auto-Scalingの概要
５つの設計原則と１１のベストプラクティス
使い捨てリソースの使用
サーバーなどのコンポーネントを一時的なリソースとして利用・設計する。
スケーラビリティの確保
需要増にトラフィック量が処理できなくなる前に、処理サーバーを拡張することで対処する必要がある。
スケーリングのタイプ
スケーリングタイプは垂直スケーリングと水平スケーリングの２タイプ。
Auto-scalingは水平スケーリング。
●垂直スケーリング
スケールアップ
メモリやCPUの追加・増強
スケールダウン
メモリやCPUの削除・低性能化
●水平スケーリング
スケールアウト
処理する機器 / サーバー台数を増加する
スケールいん
処理する機器 / サーバー台数を低減する
Auto-Scalingの要素
Auto-Scalingは主に次の３つの要素で構成される。
１、Auto-Scalingグループ
２、Auto-Scaling configuration起動設定
３、スケーリングプラン
Auto-Scalingグループ
スケールするインスタンスの最大数など基本情報を設定する。
・起動インスタンスの最小数と最大数を設定する
・今時点で必要な最適なインスタンス数（Desired Capacity）の数量になる様に
インスタンスを起動 / 終了
・起動台数をAZ間でバランシングする
・AZ障害時は障害のない別のAZにその分のインスタンスを起動する
Auto-Scaling Configuration：起動設定
スケールアウトの際に起動するインスタンス内容を設定する。
主な設定項目
・AMI
・インスタンスタイプ
・セキュリティグループ
・キーペア
・IAMロール
Auto-Scaling Plan
どの様にスケールするかの方法を定義する。
●Auto-Scaling Groupサイズの維持
現在のAuto-Scaling Groupのインスタンス最小台数を維持する設定をする
●手動スケーリング
設定外で予期せぬスケーリングが必要となった場合に手動でスケーリングを実施
●スケジュールベース
予測された需要増時期に合わせたスケーリングスケジュールを設定
●動的スケーリング
予測不能なケースにスケーリングポリシーにスケール方針を設定して、
動的にスケールアウトを実施
Auto-Scaling Plan
Auto-Scaling Planは複数組み合わせて利用することができる。
ヘルスチェック
Auto-Scaling配下のEC2のヘルスチェックにはEC2のステータス情報またはELBのヘルスチェックのどちらかを利用する。
●EC2ステータス
インスタンスのステータスがrunning以外の状態を異常と判断
●ELB
ELBのヘルスチェック機能を活用する
ELBとAuto-Scalingによる冗長構成の構築
EC2
ロードバランサー作成
ALBを選択
証明書を取得しているならHTTPSを選択
AWSコアサービス
サーバーの理解
サーバーとは
サービスを提供するソフトウェアとその機能が稼働しているコンピュータのこと。
サーバーソフトウェア
サーバーソフトウェアがサーバーの役割と機能を提供する。
サーバーのハードウェア
サーバーのハードウェアはデータセンターなどに設置された巨大なコンピュータなどが代表格。
PCやスマホでもサーバーソフトウェアをインストールしてサーバーとして機能させることができる。
サーバーの役割
リクエストとレスポンスの処理を実行してくれるのがサーバーであり、サーバーがアプリケーションサービスを実行する。
その役割に応じて様々なサーバーが存在する。
例：WEBサーバー、アプリケーションサーバー、バッチサーバー、データベースサーバー、APIサーバー、DNSサーバー、メールサーバー
WEBサーバー
HTTPに対応しWEBページを表示させたりするサーバーのこと。
・WEBサイトを作成、管理するソフトウェアによって起動するサーバー。
・WEBページを作成して、HTML上に表示する。
・クライアントからのリクエストに対してWEBページや画像をレスポンスとして返す。
データベースサーバー
リクエストに対して必要なデータを登録・更新・取得・削除などのデータ管理を実行するサーバーのこと。
・データベース処理を管理するソフトウェアによって実行されるサーバー。
・データの登録、更新、取得、削除などの処理を実行する。
・データベースのバックアップなどの管理処理も実施。
アプリケーション開発におけるDB
アプリケーション上のデータベースエンジンが導入されたデータベースサーバーの基本構成。
ローカル端末からWEBページやアプリケーションに対してDBを利用するリクエストを実行する。
アプリケーションサーバー（またはWEBサーバー）からデータベースサーバーにDB処理がリクエストされる。
データベースサーバーがリクエストに応じたDBエンジンによるトランザクション処理を実行して、実行結果を返答する。
データベースサーバーの実行結果を含めたアプリケーションの処理結果をローカル端末に返答する。
EC2の概要
EC2とは
数分で利用可能となる従量課金（時間〜秒単位）で利用可能な仮想サーバー。
・起動、ノード追加、削除、マシンスペック変更が数分で可能。
・管理者権限で利用可能。
・WindowsやLinuxなどのほとんどのOSをサポート。
・OSまでは提供されているタイプを選択することで自動設定され、OSより上のレイヤーを自由に利用可能。
・独自のAmazon Machine ImageにOS設定を作成し、保存して再利用が可能。
利用する単位をインスタンスと呼び、任意のAZにインスタンスを立ち上げてサーバーとして利用する。
利用するAMIイメージ（OSセッティング）を選択→インスタンスタイプ選択→ストレージ選択→セキュリティグループ選択→キーペア設定
AMIイメージ
AMIイメージはOSセッティング方式を選択する。
インスタンスタイプ
インスタンスタイプの選択はCPU・メモリ、ストレージ、ネットワークキャパシティなどのサーバーリソースの選択。
t2.nano
t2→ファミリーと世代
nano→インスタンスの容量
インスタンスファミリー
M5：汎用
T2：汎用
C5：コンピューティング最適化
H1：ストレージ最適化
D2：ストレージ最適化
R4：メモリ最適化
X1：メモリ最適化
F1：FPGA
G3：GPU
リサーブドインスタンス
利用期間を長期指定して利用する形式で、オンデマンドに比較して最大７５％割安になる。
スポットインスタンス
予備のコンピューティング容量を、オンデマンドインスタンスに比べて割引（最大９０％）で利用できるEC2インスタンス。
・予備用を入札式で利用するためとても安い（最大９０％引き）
・起動に通常よりも少し時間がかかる。
・予備用のため途中で削除される可能性がある。
→一時的な拡張などの用途で利用。
物理対応可能なインスタンス
物理サーバーにインスタンスを起動して制御が可能なタイプのインスタンス。
ハードウェア専有インスタンス
・ホストHWのレベルで、他のAWSアカウントに属するインスタンスから物理的に分離する。
・同じAWSアカウントのインスタンスとはHWを共有する可能性がある。
Dedicated Host
・EC2インスタンス容量を完全にお客様専用として利用できる物理サーバー。
・サーバーにバインドされた既存のソフトウェアライセンスを利用可能。
Bare Metal
・アプリケーションが基盤となるサーバーのプロセッサーとメモリに直接アクセス可能なインスタンス。
・AWSの各種サービスとの連携が可能でOSが直接下層のハードウェアにアクセス可能。
ストレージ
EC2で直接利用するストレージは不可分なインスタンスストアと自分で設定するEBSの２つ。
インスタンスストア
・ホストコンピュータに内蔵されたディスクでEC2と不可分のブロックレベルの物理ストレージ。
・EC2の一時的なデータが保持され、EC2の停止、終了と共にクリアされる。
・無料
Elastic Block Store（EBS）
・ネットワークで接続されたブロックレベルのストレージでEC2とは独立して管理される。
・EC2をTerminateしてもEBSは保持可能でSnapshotをS3に保持可能。
・別途EBS料金が必要。
セキュリティグループ
インスタンスのトラフィックのアクセス可否を設定するファイアーウォール機能を提供。
キーペア
キーペアを利用して自身がダウンロードした秘密鍵とマッチした公開鍵を有するインスタンスにアクセスする。
AWSの仕組み
インフラやアプリ開発に必要な機能がオンデマンドのパーツサービスとして提供されている。
サーバーを立ち上げるのに数分で無料で今すぐにでも利用できることが大きな特徴。
$ MV ~/Downloads/pem名.pem/ ~/.ssh/
読み取り権限の変更
$ chmod 400 ~/.ssh/pem名.pem
$ ssh -i ~/.ssh/pem名.pem ec2-user@パブリックIPアドレス
今回はEC2インスタンスをハードウェアとして、Apache HTTP Serverをサーバーソフトウェアとして設定。
EBSの概要
EC2にアタッチされるブロックレベルのストレージサービス。
【基本】
・OSやアプリケーション、データの置き場所など様々な用途で利用される。
・実体はネットワーク接続型ストレージ。
・９９.９９９％の可用性
・サイズは１GB〜１６TB
・サイズと利用期間で課金
【特徴】
・ボリュームデータはAZ内で複数のハードウェアにデフォルトで
レプリケートされており、冗長化不要。
・セキュリティグループによる通信制御対象外であり、
全ポートを閉じてもEBSは利用可能。
・データは永続的に保存。
他のAZのインスタンスにはアタッチできない。
また、１つのEBSを複数のインスタンスで共有することはできない。
同じAZ内のインスタンスのみ付け替えが可能。
【特徴】
・EC2インスタンスは他のAZ内のEBSにはアクセスできない。
・EC2インスタンスに複数のEBSを接続することはできるが、
EBSを複数のインスタンスで共有することはできない。
・他のインスタンスに付け替えできる。
Snapshot
EBSはスナップショットを利用してバックアップを取得する。
【特徴】
・Snapshotでバックアップ。
・SnapshotからのEBSを復元する際は別AZにも可能。
・SnapshotはS3に保存される。
・Snapshotの２世代目以降は増分データを保存する
増分バックアップとなる（１世代目を削除しても復元は可能）。
・Snapshot作成時にブロックレベルで圧縮して保管するため、
圧縮後の容量に対して課金が行われる。
スナップショっぷはリージョン間を跨いで利用可能。
Snapshot作成時はデータ整合性を保つため静止点の設定を推奨。
スナップショットとAMI
Amazon Machine ImageはOS設定のイメージであり、Snapshotはストレージのバックアップとなる。
⬛️AMI
ECインスタンスのOS設定などをイメージとして保持して、新規インスタンス設定に転用するもの。
⬛️Snapshot
・ストレージ / EBSのその時点の断面のバックアップとして保持するもの。
・ストレージの復元や複製に利用。
サブネットマスクとサブネット
IPアドレスとサブネットマスク
IPアドレスは３桁（０〜２５５）×４つの組み合わせで、各桁が８つのバイナリ値の集合を表す。
サブネットマスクはIPアドレス表記の後ろに/数値でくっついている。
10.0.0.255/24
CIDR（Classless Inter-Domain Routing）
サブネットマスクの値を設定し、同じネットワークとして扱うIPアドレスの個数を調整できるIPアドレスの設定方法。
195.51.xxx.xxx/16
左から１６桁目までが同じネットワーク範囲と指定。
ロックされていない１６桁分のビットの間が有効なIPアドレスとして活用できる。
最小値：10.0.0.0
最大値：10.0.255.255
IPアドレスの範囲は今後の拡張も踏まえて十分な余裕がありつつ、多すぎないレンジを指定する。
10.0.0.255/16
推奨レンジ（65,534アドレス）
CIDRに/xxを設定した際に設定可能となるIPアドレス数の組み合わせ
/18 → 16384
/20 → 4096
/22 → 1025
/24 → 256
/26 → 64
/28 → 16
サブネットによるグループ化
ローカルなネットワークに沢山の機器が繋がっていると特定の端末を発見しづらい。
サブネットマスクでアドレス範囲をグループ化することで、見つけやすくなる。
このサブネットマスクによるグループ化されたアドレス範囲内をサブネットと呼ぶ。
VPCの概要
Virtual Private Cloud（VPC）
VPCはAWSクラウド内に論理的に分離されたセクションを作り、ユーザーが定義した仮想ネットワークを構築するサービス。
・任意のIPアドレス範囲の選択をして仮想ネットワークを構築。
・サブネットの作成、ルートテーブルやネットワークゲートウェイの設定など
仮想ネットワーキング環境を完全に制御可能。
・必要に応じてクラウド内外のネットワーク同士を接続することも可能。
・複数の接続オプションが利用可能。
単一のVPCを構築すると単一AZの範囲に設定される。
同一リージョン内ではVPCは複数のAZにリソースを含めることが可能。
サブネットとVPC
VPCとサブネットの組み合わせでネットワーク空間を構築する。
VPCはサブネットとのセットが必須。
VPC設定順序
CIDR方式でアドレスレンジを選択 → AZのサブネットを選択 → インターネット経路を選択 → VPCへのトラフィック許可の設定
CIDR
CIDRに/16を設定した際に設定可能となるサブネット数とIPアドレス数の組み合わせ（AWS管理IPの５つを引いたもの）
サブネット → サブネット数 → サブネット当たりのIPアドレス数
/18 → 4 → 16379
/20 → 16 → 4091
/22 → 64 → 1019
/24 → 256 → 251
/26 → 1024 → 59
/28 → 4096 → 11
すでに利用されているなどして設定できないアドレスもある（/24の例）
ホストアドレス → 用途
.0 → ネットワークアドレス
.1 → VPCルータ
.3 → AWSで予約されているアドレス
.255 → ブロードキャストアドレス
サブネット
サブネットはCIDR範囲で分割したネットワークセグメント。
パブリックサブネットとプライベートサブネットがある。
パブリックサブネットはトラフィックがインターネットゲートウェイにルーティングされている。
プライベートサブネットはインターネットゲートウェイへのルートがないサブネット。
サブネットはVPC内に複数設置でき、プライベートとパブリックに分かれる。
VPCとサブネットにはCIDR（IPアドレス範囲）が付与され識別される。
サブネットはインターネットアクセス範囲を定義するために利用する。
VPCにサブネットを設定
VPCにCIDR/16を設定し、サブネットに/24の設定を推奨。
パブリックサブネットからインターネットに接続するにはインターネットゲートウェイが必要。
プライベートサブネットからインターネットに接続するにはNATゲートウェイがパブリックサブネットに必要。
VPC外部接続
VPCの外側にあるリソースとの通信にはパブリックのAWSネットワークかエンドポイントを利用する。
インターネット経路の設定
ルートテーブルとCIDRアドレスでルーティングを設定する。
・ルートテーブルでパケットの行き先を設定。
・VPC作成時にデフォルトで１つルートテーブルを作成。
・VPC内はCIDRアドレスでルーティング。
VPCとの接続
VPCとのオンプレミス接続
接続方法は２種類ある。
１、VPN接続
２、専用線接続（Direct connect）
Direct Connect
お客様のデータセンターやオフィスを専用線などを介してAWSへプライベートに接続するサービス。
メリット
・安価なアウトバンドトラフィック料金
・ネットワーク信頼性の向上
・ネットワーク帯域幅の向上
Direct Connectロケーションに物理的に自社オンプレ環境を接続することでAWS環境との専用接続を実現する。
Direct Connect gateway
Direct Connect gatewayにより、同一アカウントに所属する複数リージョンの複数AZから複数リージョンの複数VPCに接続。
VPNとDirect Connect
VPNの方が安く素早く利用できるが、信頼性や品質は専用線が勝る。
・コスト
V 安価なベストエフォート回線が利用可能
D キャリアの専用線サービス契約が必要となり割高
・リードタイム
V クラウド上での接続設定で可能なため即時
D 物理対応が必要なため数週間
・帯域幅
V 暗号化のオーバーヘッドにより制限がある
D ポートあたり１G / １０Gbps
・品質
V インターネット経由のためネットワーク状態の影響を受ける
D キャリアにより高い品質が保証される
・障害切り分け
V インターネットベースのため自社で保持してる範囲以外の確認は難しい
D 物理的に経路が確保されているため比較的容易
VPCエンドポイント
VPCエンドポイントはグローバルIPを持つAWSサービスに対してVPC内から直接アクセスするための出口。
２種類の接続方法がある。
Gateway型はサブネットに特殊なルーティングを設定し、VPC内部から直接外のサービスと通信する。
特徴
・アクセス制御
エンドポイントポリシーを設定
・料金
無料
・冗長性
AWS側が対応
PrivateLink型はサブネットにエンドポイント用のプライベートIPアドレスを生成し、DNSが名前解決でルーティングする。
特徴
・アクセス制御
セキュリティグループを設定
・料金
有料
・冗長性
マルチAZ設計
NATゲートウェイ
NATゲートウェイによりプライベートサブネットのリソースがインターネットまたはAWSクラウドと通信が可能になる。
特徴
・AWSによるマネージドNATサービス
・EIPの割り当て可能
・最大１０Gbpsの高パフォーマンス
・ビルトインで冗長化されている高可用性
・アベイラビリティゾーン毎に設置する
VPC Flow logs
VPC Flow logsはネットワークトラフィックを取得しCloudWatchでモニタリングできるようにする機能。
・ネットワークインターフェースを送信元 / 送信先とする
トラフィックが対象
・セキュリティグループとネットワークACLのルールで
accepted / rejectされたトラフィックログを取得
・キャプチャウインドウと言われる時間枠（約１０分間）で
収集、プロセッシング、保存する
・RDS、Redshift、ElasticCache、WorkSpacesの
ネットワークインターフェーストラフィックも取得可能
・追加料金はなし
VPCの設定上限
VPCの各種設定においては上限数があるため、大規模に利用する場合は考慮する必要がある。
リージョン当たりのVPCの上限数 ５
VPC当たりのサブネットの上限数 ２００
AWSアカウント当たりの１リージョン内のElasticIP数 ５
ルートテーブル当たりのルート上限数 １００
VPC当たりのセキュリティグループの上限数 ５００
セキュリティグループ当たりのルールの上限数 ５０
VPCを分割するケース
アプリサービスや組織構成などの用途に応じてVPCを分割する。
・アプリケーションによる分割
・監査のスコープによる分割
・リスクレベルによる分割
・本番、検証、開発フェーズによる分割
・部署による分割 共通サービスの切り出し
VPC Peering
VPC peeringにより２つのVPC間でのトラフィックルーティングが可能。
・一部のリージョン間の異なるVPC間のピア接続も可能
VPCによるネットワーク構築
VPC作成
サブネットIPアドレス 10.0.0.0/16
インターネットゲートウェイ作成
タグ名をVPCと同じ名前を入力
detachedになっている為アクションからVPCにアタッチを選択
サブネット作成
IPv4 CIDR ブロック 10.0.0.0/24
IPv4 CIDR ブロック 10.0.1.0/24
IPv4 CIDR ブロック 10.0.2.0/24
パブリックサブネット設定（インターネット接続）
ルートテーブルをクリック
ルートの編集→追加
ターゲットにインターネットゲートウェイを選択
0.0.0.0/0を送信先に設定（フルオープン）
通信プロトコルとOSI参照モデル
通信ルール
IPアドレスによって送信先の住所がわかってもその中の誰に送信するのかもわからないといけない。
インターネット通信の際にメールやWEBアクセスなど、目的によって通信方法が異なる。
例えば、メール設定をしてくださいと言われると、よくわからないままPOPとSMTPにIPアドレスぽいものを設定させられる。
SMTM（Simple Mail Transfer Protocol）はメール送信プロトコル
POP（Post Office Protocol）はメール受信プロトコル
何インターネット通信の際にメールやWEBアクセスなど、目的によって通信方法が異なる。
HTTP（Hyper Text Transfer Protocol）はHTML（Hyper Text Markup Language）で書かれた文書などの情報をやり取りする時に使われるプロトコル。
WEBサイトの通信プロトコル ＝ HTTP
OSI参照モデル
この通信プロトコルを性質や送信対象に応じて、７つの層に分けているのがOSI参照モデルと呼ばれる規約。
●アプリケーション層
・WEBアプリケーションの通信サービスが実現できるよう
固有の規定を定義
・この中でアプリケーションごとにプロトコルが細分化されている
・メールソフトウェア用プロトコル
→POP / SMTP
→HTTP / HTTPS
●プレゼンテーション層
・文字の送り方を決めているところ
文字コード、圧縮、データ暗号 / 復号など
・送信側と受信側のコンピュータで使用している
表現形式がことなっても、世界中でWEBサイトが表示されるのは
このため
●セッション層
・アプリケーション間でもセッションの
確立、維持、終了するまでの手順を規定
・セッションとはアプリケーションと通信した際の
一連の継続的な処理やつながりのこと
・ノード間のデータ伝送におけるコネクションを確立して、
アプリケーション間でセッションを開始するための
ポート番号の割り当てを規定
・TCPを利用して、到着順序や到着確認を実施
・コネクション：セッションでデータ転送を行うための
論理的な回線のこと
・セッション：通信の開始から終了までを管理する１つの単位のこと
・ノード間の起点から終了までの通信を規定
・IPアドレスを利用した割り当てや、
ルータによる宛先のコンピュータまでの最適なパスを選択して
データを送信などを実施
・１つのネットワーク回線上で直接接続された
ノード同士の通信について規定
・LANではイーサネットにより
同じネットワークセグメント内におけるノード間の通信を
MACアドレスを利用して実施
●物理層
・ネットワークの物理的な接続や伝送方式を規定プロトコル
・０と１のビット列を電気信号に変換しネットワークへ伝送する方法
通信したい内容に応じて、適切なレイヤーの規定に準拠して設定される必要がある。
アプリケーション層 → HTTP
プレゼンテーション層 → SSL
ネットワーク層 → IP
データリンク層・物理層 → イーサネット優先ケーブル（MACアドレスを利用）
ポート番号
通信する出入り口となっているのがポート番号で、メールボックスのような役割を担っている。
・ポートとはオペレーティングシステムが
データ通信を行うためのエンドポイント
・インターネット上の通信プロトコルで同じコンピュータ内で動作する
複数のソフトウェアのどれが通信するかを指定するための番号
HTTP通信 → ８０番
HTTPS通信 → ４４３番
LINE → ５０００番 / ５５２８番
SSH通信 → ２２番
メール通信（SMTP） → ２５番
メール受信（POP） → １１０番、１４３番
セキュリティグループとネットワークACL
セキュリティグループ
インスタンスへのトラフィックのアクセス可否を設定するファイアーウォール機能を提供。
※デフォルトは全て拒否に設定されている
EC2インスタンスに対するトラフィック制御を実施するファイル機能を提供。
ネットワークACL
セキュリティグループとネットワークACL
トラフィック設定はセキュリティグループまたはネットワークACLを利用する。
セキュリティグループ設定
・サーバー単位
・ステートフル
インバウンドのみ設定すればアウトバウンドも許可される。
・許可のみをIn / outで指定
・デフォルトでは同じセキュリティグループ内通信のみ許可
・全てのルールを適用
ネットワークACLs設定
・VPC / サブネット単位で適用
・ステートレス
インバウンド設定だけではアウトバウンドは許可されない。
・許可と拒否をIn / outで指定
・デフォルトでは全ての通信を許可する設定
・番号の順序通りに適用
セキュリティグループの設定
１、EC2
２、作成したインスタンスのセキュリティグループを選択
３、セキュリティグループ作成
セキュリティグループ名・説明の入力
ルール（インバウンド）追加でポート番号を指定（IP 0.0.0.0/0）
HTTP、HTTPSなどを選択
４、インスタンスに戻りネットワーキングを選択
５、先ほど作ったセキュリティーグループを選択
セキュリティグループの割り当てを押す
６、設定完了
ネットワークACLの設定
VPCのマネジメントコンソール
セキュリティ → ネットワークACL
インバウンドルールとアウトバンドルールを設定していく
インバウンドルールの編集
ルールの追加
番号入力
タイプ（HTTPなど）入力
許可 / 拒否の設定
アウトバウンドの設定
ルールの追加
番号入力
タイプ（HTTPなど）入力
許可 / 拒否の設定
Route53の概要
IPアドレスとURL
人が読みやすいURLに変換して、住所として利用している。
Domain Name SystemサーバーはURLとIPアドレスの対応関係を管理し、変換する。
リクエストとレスポンスがWEBアプリケーションの基本の動き。
リクエストを送信する際にDNSサーバーにURLのIPアドレスを確認して、送信先を特定する。
DNSレコードというIPアドレスとURLを紐付けた表を確認してルーティングする。
Route53は権威DNSサーバーの機能をマネジメント型で簡単に利用できるサービス。
・主要機能はドメイン登録 / DNSルーティング / ヘルスチェックの３つ
・ポリシーによるルーティング設定
トラフィックルーティング / フェイルオーバー / トラフィックフローに
基づく様々な条件のルーティング設定が可能
・マネージドサービスとして提供しており、
ユーザー側で冗長性などを考慮する必要がない
Route53の利用方法
Route53の利用を開始してドメインを登録するとホストゾーンを自動生成し、そこにルーティングを設定する。
１、Route53にドメインを設定
２、ドメイン名と同じホストゾーンを自動生成
３、ホストゾーンにルーティング方法となるDNSレコードを作成
４、トラフィックルーティングを設定
ホストゾーン
ドメイン（example.com）とそのサブドメイン（sub.example.com）のトラフィックのルーティングする方法についての情報を保持するコンテナ。
パブリックホストゾーン
・インターネット常に公開された
トラフィックのルーティング方法を定義
プライベートホストゾーン
・VPCに閉じたプライベートネットワーク内の
どのようにトラフィックをルーティングするかを定義
・１つのプライベートホストゾーンで複数VPCに対応
・VPCが相互にアクセス可能であれば
複数リージョンのVPCでも同じホストゾーンを利用可能
トラフィックルーティンのタイプ
様々なルーティング方式を選択して設計することが可能。
●シンプルルーティング（Simple）
・レコードセットで事前に設定された値のみに基づいて
DNSクエリに応答する
・静的なマッピングによりルーティングを設定
●加重ルーティング（Weighted）
・複数エンドポイント毎の重み設定によりDNSクエリに応答する
・重み付けの高いエンドポイントに多くルーティングする
●フェイルオーバールーティング（Failover）
・ヘルスチェックの結果に基づいて、
利用可能なリソースをDNSクエリに応答する
・利用可能なリソースにのみルーティングされる
●複数値回答ルーティング（Multivalue）
・ランダムに選ばれた最大８つの別々のレコードを使用して
IPアドレスを設定して、複数の値を返答する
・IPアドレス単位でヘルスチェックを実施して
ルーティングすることで、正常なリソースの値を返す
ELBに変わるものではないが、正常であることが確認できる
アベイラビリティとロードバランシングを向上させることが可能
●レイテンシールーティング（Latency）
・リージョンの遅延によりDNSクエリに応答する
・基本的にはユーザーの最寄りのリージョンに返答する
・リージョン間の遅延が少ない方へルーティングされる
●位置情報ルーティング（Geolocation）
・ユーザーのIPアドレスにより位置情報を特定して、
地域毎に異なるレコードを返す
・ネットワーク構成に依拠しない、精度の高いレコードの区分けが可能
●地理的近接性ルーティング
・ユーザーとリソースの場所に基づいて
地理的近接性ルールを作成して、トラフィックをルーティングする
AWSリソースを使用している場合は、
リソースを作成したAWSリージョン
AWS以外のリソースを使用している場合は、リソースの緯度と経度
・必要に応じてバイアスを設定し、
特定のリソースにルーティングするトラフィックの量を変更できる
・トラフィックフローを利用する必要がある
トラフィックフロー
従来はALIASレコードを駆使して、複雑なルーティングポリシーを作成していたがトラフィックフローによる視覚的なフローでの複雑なポリシー設定が可能となった。
Route53によるドメイン登録
Internet Service Provider（ISP）がインターネット接続を提供する。
IPアドレスとURL
リクエストを送信する際にDNSサーバーにURLのIPアドレスを確認して、送信先を特定する。
ドメインは階層構造になっているため、それぞれの場所をDNSになんども聞く必要がある。
クラウドとAWSの概念
クラウドと仮想化
クラウドは仮想化技術によって成り立っているサービス。
そのため、クラウドを理解するにはまず仮想化について理解する必要がある。
仮想化とは
仮想的なインフラの構成を隠して、仮想化された単位に分けたり、統合したりして利用させる技術。
仮想化の仕組み
物理的なインフラに仮想化ソフトウェアを設定して、実質的な機能をユーザーに切り分けて提供する。
１つの物理的なサーバーを買ってきたけど、容量が大きくて１つのシステムやユーザーで利用するのはもったいないという場合に仮想化ソフトウェアを使う。
仮想化ソフトウェアには、Vmware型・ハイパーバイザ型の２タイプが主に使われている。
個々のユーザーは個別のサーバーのように利用できる。
柔軟にサーバー範囲を切り分けて利用できる。
仮想化の対象
次のようなインフラを仮想化することができる。
サーバーの仮想化
・１台の物理サーバー上に複数のOSを動作させる技
・ハイパーバイザ型 / VMware型 / コンテナ方式
ストレージの仮想化
・複数のストレージを仮想的に統合して１つの大きなストレージプールを構成する技術
・ブロックレベル仮想化 / ファイルレベル仮想化
ネットワークの仮想化
・新たな仮想ネットワークの構築や制御をソフトウェアにより動的に実施する技術
・SDN / VLAN
デスクトップの仮想化
・サーバー上に置いたPC環境のデスクトップ画面を遠隔地にある接続端末に転送する技術
・仮想PC方式 / ブレードPC方式
仮想化のメリット
仮想化を利用することでインフラ利用の効率性や柔軟性が圧倒的に向上する。
・サーバースペースの削減 / データセンター費用の削減
・効率的なサーバー利用によるコスト削減
・調達の迅速化
・構成変更やメンテナンス対応の柔軟性
・セキュリティの向上
コンテナ
コンテナはホストマシンのカーネルを利用し、プロセスやユーザなどを隔離する仮想化方式。
Docker
Dockerはコンテナ型の仮想環境を作成、配布、実行するためのプラットフォーム。
・コンテナはホストマシンのカーネルを利用し、プロセスやユーザなどを隔離する
・Dockerはミドルウェアのインストールや各種環境設定をコード化して管理
１、コード化されたファイルを共有するため誰でも同じ環境構築が容易に可能
２、作成した環境を配布共有が容易
３、環境の即時構築・削除が容易なため、CI/CDによる開発ができる
クラウドとは
必要に応じて他社所有のハードウェア・ソフトウェア等をネットワークを介して利用するシステム利用形態。
こんな時はクラウドに、、、
・短期的なキャンペーン用に一時的にサーバーがほしい
・需要増に応じサーバーを増強し、需要減には削減したい
・今すぐデータベースが必要だけど調達している時間がない
インフラを仮想化することで、ソフトウェア化されたサービスとして提供されているのがクラウド型のインフラサービス。
クラウド構成要素
クラウドで提供されるシステム構成要素はインフラ、ミドルウェア、アプリケーションの３層。
クラウドの５つの基本特性
クラウドの特徴は「５つの基本特性」、「３つのサービス」、「３つの提供形態」
オンデマンド・セルフサービス
・利用者は人を介さず、必要に応じてサーバー、ネットワーク、ストレージを設置・拡張・設定が可能
幅広いネットワークアクセス
・ネットワークを通じてPC、スマホ、ダブレットなど各種デバイスから利用可能
リソースの共有
・ハードウェアの使用容量などのリソースは複数利用者により共有し、利用者の需要に応じて動的に割り当てる。物理的配置は考慮不要
迅速な拡張性
・ハードウェア等の資源は必要に応じて自動または手動で増やしたり、減らしたりできる
サービスは計測可能
・稼働状況が常に計測されており、利用状況をコントロール・最適化できる
・計測結果に応じて従量課金が可能
クラウドの３つのサービス形態
主にSaaS、PaaS、IaaSの３つのサービスが存在。
・クラウド事業者がアプリケーションまで提供
・自社はすぐにアプリケーションを利用可能
PaaS
・自社はアプリケーション開発に専念
IaaS
・クラウド事業者がハードウェア提供
・自社でミドルウェア、OSを購入しアプリケーションを開発
クラウドの３つの提供形態
クラウド提供形態はプライベートとパブリックが主流。
加えて両方を併用するハイブリッド型の提供形態がある。
オンプレミス（自社所有）
特徴：ハードウェア / ソフトウェアを購入し、自社にシステムを構築
メリット：自社でハードウェアを自由にコントロール可能
デメリット：調達・構築に時間を要す。運用管理に人材、コストを要す。
プライベートクラウド（自社所有）
特徴：自社内にクラウド基盤を構築し、ハードウェア・ソフトウェアを事業部や子会社間で共同利用
メリット：自社資産の効率化。パブリックと比較しコントロールが自由。
デメリット：クラウド運用管理が難しく、クラウドのメリットが低下
パブリッククラウド（他社所有）
特徴：ハードウェア・ソフトウェアを他社と共同利用し、柔軟に構築・解除が可能
メリット：運用管理を他社に委任可能
デメリット：自社コントロールの範囲が制限
クラウドの進化
クラウドIoT
AWSは他のプラットフォームよりも機能が豊富で、グローバルシェアも高い。
クラウドAI
完成したAI機能をクラウドを通じて即座に利用することも可能。
クラウドファーストの時代へ
クラウドを中核に「ネットとリアルの融合」、「ITとビジネスの融合」が促進される。
「テクノロジーの進化」と「ビジネス変化のスピード」に対応するため、柔軟で素早いシステム開発が求められる。
今後のテクノロジー×ビジネスに柔軟に対応するためには、クラウドファーストが必要不可欠。
AWSとは
AWSはAmazonが提供する総合クラウドサービスで、あらゆる領域のクラウドサービスを網羅的に提供している。
なぜAWSか？
圧倒的なトップリーダーの地位にあるため。
グローバルシェア
Amazonは長年クラウドシェアで３割以上のシェアをキープしており圧倒的な存在である。
Gartnerの調査においてもクラウドのトップリーダーとして位置付けられている。
データ技術力
AIプラットフォームもビッグ４クラウドベンダーが他を圧倒。
なぜAWSがトップなのか
圧倒的な投資額でクラウドをリード。
データ活用の軍拡競争
圧倒的投資によりAIを含めた最新のサービスが続々とリリースされ、後発企業が単体で追いつくことはもはや不可能。
AWSファースト
ITインフラ構築検討の際にはAWSファーストにならざるを得ない。
AWSの仕組み
インフラやアプリ開発に必要な機能がオンデマンドのパーツサービスとして提供される。
サーバーを立ち上げるのに数分で無料で今すぐにでも利用できることが大きな特徴。
インフラ / システム機能をブロックパーツのようにオンライン上に組み合わせて自分の好きな構成を実現する仕組み。
AWSのサービスにはアンマネージド型とマネージド型が存在。
・アンマネージド型
スケーリング / 耐障害性 / 可用性を利用者側で設定し管理する必要がある。
メリット：設定が柔軟に可能
デメリット：管理が面倒
・マネージド型
スケーリング / 耐障害性 / 可用性がサービスに組み込まれておりAWS側で管理されている。
メリット：管理が楽
デメリット：設定が限定的
アンマネージド型の代表的なサービスはEC2（サーバー）
マネージド型の代表的なサービスはRoute53（DNS）
AWSのグローバルインフラ構成
リージョンとアヴェイラビリティーゾーン（AZ）とエッジロケーションの３つの区分。
リージョン
リージョンは国や地域における地理的に隔離されたAWS拠点。
日本には東京と大阪の２つのリージョンが設置されている。
リージョンとリージョンは物理的に独立したインフラ拠点。
ただし、隣接リージョン間は広帯域の専用ネットワークで接続されている。
リージョンに応じてAWSサービスの利用可否と値段が異なる。
米国東部のバージニア北部は最新機能が使える。
アベイラビリティゾーン（AZ）
リージョンの中に複数の独立したインフラ拠点が存在し、それをアベイラビリティゾーンと呼ぶ。
同リージョン内のAZ同士は低レイテンシーのリンクで接続されている。
AZは１つの複数の物理的なデータセンターで構成されている。
AZにある物理インフラを仮想化してユーザーにインフラ機能をサービスとして提供している。
よって、１つのAZ内のみでAWSサービスを利用しているとデータセンターの停止によるサービス停止の可能性がある。
複数AZで分けて信頼性の高いシステム構成にするのが基本的なAWSアーキテクチャとなる。
複数AZを跨ぐと物理的な耐久性などが向上するが、システム間の連携や共有が制限される。
リージョンの選択
データやシステムに係る法律や社内規定を考慮し、基本的には自身の身近なリージョンを選択してAWSシステムを構築する。
リージョンのある国の法律に影響される可能性も考慮する。
事業継続計画（BCP）などの対策のためデータや予備システムとして別リージョンを利用する。
エッジロケーション
エッジロケーションはキャッシュデータなどを利用する際の更に小さなエンドポイントとなる拠点。
・CloudFront
・Lambdaエッジ
コンピューティング
アプリケーションを構築する際にサーバーなどのコンピューティングを起動・実行する関連サービス。
・EC2
AWSを利用して仮想サーバーを立ち上げるサービス。
ELB / AutoScaling / セキュリティグループも必須。
・Lambda
サーバレスでプログラミングコード処理を実行するサービス。
・Lightsail
仮想サーバー、ストレージ、データベース、
およびネットワーキングを予測可能な低価格で提供。
・Elastic Container Service（ECS）
Dockerコンテナをサポートする拡張性と
パフォーマンスに優れたコンテナオーケストレーションサービス。
ストレージ
AWSにおいてデータを保存する際に利用する多様なストレージ。
・S3
スケーラビリティ、データ可用性、セキュリティ、
およびパフォーマンスを提供するオブジェクトストレージサービス。
・Elastic Block Store（EBS）
EC2にアタッチして利用する専用のブロックストレージ。
・インスタンスストア
EC2にアタッチして利用する一時データ保存用ストレージ。
・Elastic File System（EFS）
AWSクラウドサービスおよびオンプレミスリソースで使用するための、
シンプルでスケーラブル、かつ伸縮自在な完全マネージド型のNFSファイルシステム。
・S3 Glacier
安全性と耐久性に優れ、極めて低コストのS3クラウドストレージクラスで、
データのアーカイブや長期バックアップに使用する。
ネットワーキングとコンテンツ配信
ネットワークやコンテンツ配信・AWS環境への接続設定に利用するサービス。
・VPC
IPアドレス範囲の選択、サブネットの作成、ルートテーブルやネットワークゲートウェイの設定など、仮想ネットワーキング環境を構築するサービス。
・CloudFront
低レイテンシーの高速転送により世界中の視聴者に安全に配信する高速コンテンツ配信ネットワーク（CDN）サービス。
・Route53
DNSサーバーの機能を提供し、ドメイン変換とルーティングを実施するサービス。
・Direct Connect
AWSとデータセンター、オフィス、またはコロケーション環境との間に
プライベート接続を確立する専用線サービス。
リアルタイム双方向通信アプリケーションを実現するRESTful API
およびWebSocket APIを作成・管理する。
・Storage Gateway
オンプレミスから実質無制限のクラウドストレージへのアクセスを提供する
ハイブリッドクラウドストレージサービス。
データベース
AWSでは様々なタイプのデータベースサービスがマネージド型サービスで提供されている。
・RDS
MySQL、PostgreSQL、Oracle、SQL Server、MariaDB向けのマネージドリレーショナルデータベースサービス。
・Aurora
MySQLおよびPostgreSQLと互換性のあるクラウド向けの
分散・高速化されたリレーショナルデータベース。
・DynamoDB
規模に関係なく数ミリ数台のパフォーマンスを実現する、
key-valueおよびドキュメントデータベース。
・ElastiCache
RedisまたはMemcachedに互換性のある完全マネージド型の
インメモリデータストア。
・Redshift
高速かつシンプルで、費用対効果の高いデータウェアハウス。
アイデンティティ・セキュリティ・コンプライアンス
AWSでのセキュリティやコンプライアンスに寄与するサービス。
・Identity & Access Management（IAM）
AWSのサービスやリソースへのアクセスを安全に管理するアクセス管理サービス。
・GuardDuty
悪意のある操作や不正な動作を継続的にモニタリングする脅威検出サービス。
・Inspector
自動化されたセキュリティ評価サービスで、AWSにデプロイした
アプリケーションのセキュリティとコンプライアンスを向上させることができる。
・AWS Key Management Service
暗号化キーを簡単に作成して管理し、幅広いAWSのサービスや
アプリケーションでの使用を制御する。
・CloudHSM
法令遵守のためのハードウェアベースキーストレージ。
・WAF
一般的なウェブの脆弱性からウェブアプリケーションまたは
APIを保護するウェブアプリケーションファイアウォール。
・Shield
マネージド型の分散サービス妨害（DDoS）保護サービス。
・Artifact
AWSのコンプライアンスレポートにオンデマンドでアクセスできる
無料のセルフサービスポータル。
マネジメントとガバナンス
運用保守やサポートに関する支援ツールやサービス。
・CloudWatch
アプリケーションを監視し、リソース使用率の最適化を行い、
運用上の健全性を統括的に把握するモニタリングサービス。
・CloudTrail
ユーザーアクティビティとAPI使用状況の追跡するログ取得サービス。
・Config
AWSリソースの設定を評価、監査、審査できるサービス。
・Organizations
複数のAWSアカウント全体の一元管理と一括請求。
・AWS Personal Health Dashboard
AWSのサービス状態のパーソナライズされた表示。
・AWS Service Catalog
一般的にデプロイさているITサービスの一元的な管理サービス。
・AWS Well-Architected Tool
AWSのアーキテクチャ設計原則の確認とワークロードの見直しと改善を支援。
・AWS Systems Manager
AWSの様々なサービスの運用データを確認でき、
AWSリソース全体に関わる運用タスクを自動化する運用支援サービス。
・AWS サポート
ベーシック / 開発者 / ビジネス / エンタープライズプランの４つ。
アプリケーション統合
アプリケーション間の通信制御やフロー作成・データ連携などに利用するサービス。
・SNS
完全マネージド型 pub / sub メッセージング。
・SQS
完全マネージド型のメッセージキューイングサービス。
・SES
Eメール送受信サービス。
移行と移転
AWSクラウドへのインフラ移行やデータ移行に利用するサービス。
・AWS Application Discovery Service
サーバーの設定データ、使用状況データ、動作データが収集して
サーバーの使用率データや依存関係のマッピングなどの移行に必要な情報を
提供するサービス。
・AWS Database Migration Service
データベースを短期間で安全にAWSに移行することが可能な、
データベース移行ツール。
・AWS Server Migration Service
数千のオンプレミスワークロードを従来よりも簡単に、
かつ短時間でAWSに移行できるエージェントレスサービス。
・AWS Show ファミリー
エッジでデータを収集して処理し、AWSとの間でデータを移行する、
非常に安全なポータブルデバイス。
AWSコスト管理
AWSのコストと使用量や経済性を把握し、分析・管理するための可視化ツール。
・AWSのコストと使用状況レポート
AWSのコストと使用状況の詳細を確認するためのレポート。
・AWS Budgets
予算のしきい値を超えた時にアラートを発信するカスタム予算を設定。
・価格算定ツール
AWSのコスト計算を支援するツール。
簡易見積りツール / TCO計算ツール / Pricing Calculator
・AWS Cost Categories
自身の組織やプロジェクト構造に分けてコストをカテゴライズすることが
可能な機能。
・Trusted Advisor
コスト最適化とセキュリティと耐障害性とパフォーマンス向上について
アドバイスを提供するサービス。
AWS活用メリット
IaaSとしてのAWS
AWSの基本サービスはIaaSであり、様々なインフラをインターネットを介してオンデマンドで利用可能なことが利点。
PaaSとしてのAWS
AWSのIaaSに加え、アプリケーション開発ツール（PaaS）を利用して、アプリケーションを構築する。
・コーディングツール → Cloud9
・コード管理、デプロイ → Codeシリーズ / Elastic BeanStalk / Gitなど
・開発環境のインフラ → EC2 / RDS / VPCなど
SaaSとしてのAWS
AI翻訳機能や文章解析AIなどのAWSによって既に完成されたサービスを利用するクラウド形態。
AWS活用例
既にサービスとして出来上がったクラウドサービスをAPIから利用して組み込むことで、最先端の機能を利用できる。
オンプレミスとAWSクラウドの良し悪し
クラウドのメリット・デメリット
柔軟にリソースを活用できるクラウドのメリットに対して、ベンダーロックインという最大のデメリットがある。
メリット
◼️オンデマンドでリソースを柔軟に迅速に活用できる。
◼️オンプレミス環境とのハイブリッドやオンプレミス環境に
デメリット
◼️クラウド業者のサービスに依存してしまうベンダーロックイン。
◼️データ保存先や活用で社内での保管が義務付けられている等、
クラウド環境が利用できない。→回避策はある
ベンダーロックイン
オンプレミスのサーバーでシステム構築を自社内でしていれば、サーバー変更やソフトウェア変更は比較的容易に可能。
EC2インスタンスなどオンプレミスサーバーと類似の製品は移行が容易である。
AWS独自のサーバーレスの仕組みをアプリに組み込んで機能開発してしまうと、環境移行が困難になる。
例えば、AWS LambdaやElastic File System（EFS）、AWS Storage Gatewayなどの機能を、別サーバーでそのまま再現できるわけではない。
どっぷりAWSに依存して環境設定や開発を進めてしまうとAWS外への移行がどんどん困難になる。
オンプレミス環境のAWS
AWS Outpostsはオンプレミス環境にAWSサービスをセットアップして独自に利用できるように構築できる。
AWSの操作
AWSの操作方法は３つ。
１、AWSマネジメントコンソール
SQLについて
データベースとSQL
データベース概要
データベースとは
・検索や蓄積が容易にできる様に整理された情報の集まり
・全てのシステムがデータを取り扱っている
・データを取り扱う手段として、ほぼ全てのシステムが何かしらのデータベースを使用
データベースが必要な理由
１、大量のデータから必要なデータを取り出すため
２、大人数でデータを共有して利用するため
３、データの保護
SQL概要
SQLとは
・データベース、テーブル、行や列を扱うための言語をSQLと呼ぶ
リレーショナルデータベース基本用語
クエリ（問い合わせ）
→データの検索や更新、削除、抽出などの要求をデータベースに送信すること。
データ型
・データベースでは、テーブルを作成するときに、それぞれの列（カラム・フィールド）に指定した形式のデータしか、入力できない様に設定する
このとき指定するデータの形式をデータ型という
数値型
・int型
整数
・tinyint型
とても小さな整数
・int unsigned
数値は符号無しとすることが
文字型
・char型（キャラ）
固定長の文字列２５５文字まで。
文字列を格納するときに指定した長さが
日付・時刻型
・date型
日付
・オラクル社
CREATE
SELECT id, name from products;
データベースからデータを取得する
・ユーザー一覧を出力
select * from users;
select
name as 名前,
price as 価格,
from
products;
select name, price from products where price >= 9800;
比較演算子
select * from products;
select * from products where id = 1;
select * from products where name = '商品0003'
select * from products where price > 1000;
select * from products where price < 1000;
select * from products where price != 100;
select * from products where id in(1,2,3);
select * from products where id not in(1,2,3);
select * from products where price is not null;
select * from products where price is null;
select * from products where price between 1000 and 1900;
like句
'中'から始まるデータの取得
select * from users where last_name like '中%';
'中'を含むデータの取得
select * from users where last_name like '%中%';
'子'で終わるデータの取得
select * from users where last_name like '子%';
limit句
データを１０件取得
select * from products limit 10;
０から１０までのデータ取得
select * from products limit 0, 10;
１１から１０件のデータ取得
select * from products limit 10, 10;
select id, last_name from users where gender = 1 limit 10;
取得したデータの利用方法
・CSV書き出し
select * from products;
Exportボタンをクリック
ファイルを保存（CSV）
データをエクセルに取り込む方法
CSVファイルをインポートする
区切り記号付きを選択
集約関数
・sum
select
sum(amount)
from
orders
where
order_time >= '2019-01-01 00:00:00'
and order_time < '2019-02-01 00:00:00';
・avg
select avg(price) from products;
・min
select min(price) from products;
・max
select max(price) from products;
・count
select count(*) from users;
select count(*) from users where gender = 2;
ユニークユーザー数を求める
select
count(distinct user_id)
from
access_logs
where
request_month = '2019-01-01';
・group by句
select
prefecture_id,
count(*)
from
users
group by
prefecture_id;
・期間ごとに集計する
select
*
from
access_logs
where
request_month >= '2019-01-01'
and request_month < '2019-02-01';
group by
request_month;
・having句
記述順序
select
↓
from
↓
where
↓
group by
↓
having
select
*
from
access_logs
where
request_month >= '2019-01-01'
and request_month < '2019-02-01';
group by
request_month
having
count(distinct user_id) >= 630;
select分の記述順序と実行順序
記述順序
1、 select 取得行（カラム）の指定
2、 from 対象テーブルの指定
3、 where 絞り込み条件の指定
4、 group by グループ化の条件を指定
5、 having グループ化した後の絞り込み条件を指定
6、 order by 並び替え条件を指定
7、 limit 取得する行数の制限
実行順序
1、 from 対象テーブルの指定
2、 where 絞り込み条件の指定
3、 group by グループ化の条件を指定
4、 having グループ化した後の絞り込み条件を指定
5、select 取得行（カラム）の指定
6、 order by 並び替え条件を指定
7、 limit 取得する行数の制限
select
request_month,
count(*)
from
access_logs
where
access_logs where request_month >= '20170-01-01'
and request_month < '2017-02-01'
group by request_month
having
count(*) >= 1000;
データの並び替え
降順
select * from products order by price desc;
昇順
select * from products order by price asc;
※order byで並び順を指定しないとバラバラになる。
order by句
select * from products order by price desc, id asc;
生年月日が古い順に並べる。
select * from users order by birthday asc, prefecture_id asc;
関数と演算子
・足し算
select 10 + 3;
・引き算
select 10 - 3;
・掛け算
select 10 * 3;
・割り算
select 10 / 3;
・余り
select 10 % 3;
select 10 + null;
select 10 - null;
select 10 * null;
select 10 / null;
select 10 % null;
※結果は全てnullになる。
・絶対値の取得
ゼロからの距離の大きさを表す数値
・絶対値の取得
select abs(10);
10
select abs(-10);
10
select abs(0);
0
・四捨五入
round関数
round（対象の数値、丸めの桁数）
select id, name, price * 1.08 from products;
select id, name, round(price * 1.08, 0) from products;
select round(10.555, 0);
select round(10.555, 1);
select round(10.555, 2);
・文字列の演算
select concat(last_name, '', first_name, 'さん') from users;
・メルマガ送信用のリスト作成
select concat(last_name, 'さん'), email from users where gender = 2;
・日付と時刻の演算
現在の日付
select current_date();
現在の時刻
select current_timestamp();
n日後の日付
select current_date() + 3;
n日前の日付
select current_date() - 3;
x時間後の時刻
select current_time() + interval 6 hour;
x時間前の時刻
select current_time() - interval 6 hour;
select * from orders where extract(year_month from order_time) = 201701;
テーブルの結合
内部結合
・顧客一覧を取得
・都道府県名の表示
・必要な列はユーザーID、名字、名前、都道府県名
select
u.id,
u.last_name,
u.first_name,
p.name
from
users as u
inner join
prefectures as p
on u.prefecture_id = p.id;
内部結合＋絞り込み
・顧客一覧を取得
・都道府県名の表示
・必要な列はユーザーID、名字、名前、都道府県名
追加
・女性のみのデータ
select
u.id,
u.last_name,
u.first_name,
p.name
from
users u
inner join
prefectures p
on u.prefecture_id = p.id
where u.gender = 2;
演習
⬛️２０１７年１月の東京都に住むユーザーの注文一覧を出力
・注文ID
・注文日時
・注文金額合計
・ユーザーID
・名字
・名前
select
o.id order_id,
o.order_time order_time,
o.amount amount,
u.id user_id,
u.last_name last_name,
u.first_name first_name
from
orders o
inner join
users u
on o.user_id = u.id
where
u.prefecture_id = 13
and o.order_time >= '2017-01-01 00:00:00'
and o.order_time < '2017-02-01 00:00:00'
order by order_id;
外部結合
select
u.last_name last_name,
u.id user_id,
o.user_id order_user_id,
o.id order_id
from
users u
left outer join
orders o
on u.id = o.user_id
order by u.id;
応用
⬛️全ての商品について、販売個数一覧を出力
select
p.id,
p.name,
sum(od.product_qty) num
from
products
left outer join
order_details od
on p.id = od.product_id
group by p.id;
３つ以上のテーブルを使った結合
・注文一覧を出力
・注文詳細情報と商品情報も一覧の中に入れる
select
o.id order_di,
o.user_id user_id,
o.amount amount,
o.order_time order_time,
p.name product_name,
od.product_qty qty,
p.price product_price
from
orders o
inner join
order_details od
on o.id = od.order_id
inner join
products p
on od.product_id = p.id;
追加
・user_idだとわからないため名字と名前で表示
・上記を一覧に追加
select
o.id order_di,
o.user_id user_id,
u.last_name last_name,
u.first_name first_name,
o.amount amount,
o.order_time order_time,
p.name product_name,
od.product_qty qty,
p.price product_price
from
orders o
inner join
order_details od
on o.id = od.order_id
inner join
products p
on od.product_id = p.id
inner join
users u
on o.user_id = u.id;
多対多の関係を含む結合
・商品ID＝３に紐づく商品カテゴリ名を全て表示
・商品ID
・商品名
・カテゴリ名
select
p.id product_id,
p.name product_name,
c.name category_name
from
products p
inner join
products_categories ps
on p.id = pc.product_id
inner join
categories c
on pc.category_id = c.id
where
p.id = 3;
テーブルの足し算
・ユーザーとアドミンユーザーを足し合わせた一覧出力
・姓
・名
・性別
select
email,
last_name,
first_name,
gender
from
users
union
select
email,
last_name,
first_name,
gender
from
admin_users;
※union allで重複行が削除されない。
例題
・usersテーブルから男性のみ出力
・admin_usersテーブルからは女性のみ
・unionした結果を性別順に並び替える
select
email,
last_name,
first_name,
gender
from
users
where
gender = 1
union
select
email,
last_name,
first_name,
gender
from
admin_users
where
gender = 2
order by gender;
※where、group by、havingといった句をつけることができる。
※order byだけは全体として最後に１つしか記入できない。
サブクエリとは
・ある問い合わせの結果に基づいて異なる問い合わせを行う仕組み
・複雑な問い合わせができる
・where句の中で使うことが多い
・where句以外にもselect句、from句、having句など様々場所で利用できる
サブクエリ（where句）
⬛️２０１７年１２月に商品を購入していないユーザーにメルマガを出す
・ユーザーID
・名字
【構文】
select
列名, ...
from
テーブル名
where
列名 演算子（select 列名 from テーブル名 ...）;
select
id,
last_name,
from
users
where id not in(
select
user_id
from
orders
where
order_time >= '2017-012-01 00:00:00'
and order_time < '2018-01-01 00:00:00');
演習
⬛️２０１７年１２月に商品を購入したユーザーにメルマガを出す
・ユーザーID
・名字
select
id,
last_name,
from
users
where id in (
select
user_id
from
orders
where
order_time >= '2017-12-01 00:00:00'
and order_time < '2018-01-01 00:00:00'
);
応用
・全商品の平均単価よりも単価が高い商品の一覧を出力
select
*
from
products
where
price >
(
select
avg(price)
from
products
);
追加
・商品単価の高い順に並び替える
・商品単価が同じ時は登録順（id照準）に並び替える
select
*
from
products
where
price >
(
select
avg(price)
from
products
)
order by
price desc, id asc;
※ascは省略できる。
条件分岐 case式
・case式を使うと、SQLで場合分けを記述することができる
・場合分けのことを条件分岐という
条件によって値を変更
⬛️ユーザーのアクティビティの度合いによって施策を変える
・ユーザーを累計注文回数でランク分け
A：５回以上
B：２回以上（２ or ３ or ４）
C：１回
※注文回数０回のユーザーは出力必要
・ユーザーID
・累計注文回数
・ユーザーランク（A or B or C）
【構文】
case
when 条件式１ then 値１ → 条件式１がtrue（真）ならば値１
[when 条件式２ then 値２ ・・・] → 条件式２がtrue（真）ならば値２
[else 値３] → どれにも当てはまらなければ値３
end
※[ ]の部分は省略可能。最後のendは省略不可。必須。
select
u.id user_id,
count(*) as num,
case
when count(*) >= 5 then 'A'
when count(*) >= 2 then 'B'
else 'C'
end as user_rank
from
users as u
inner join
orders as o
on u.id = o.user_id
group by u.id;
追加
・ユーザーのランクが高い順に並び替える
select
u.id user_id,
count(*) as num,
case
when count(*) >= 5 then 'A'
when count(*) >= 2 then 'B'
else 'C'
end as user_rank
from
users as u
inner join
orders as o
on u.id = o.user_id
group by u.id
order by user_rank asc;
取得値nullを置き換える
select
p.id,
p.name,
case
when sum(od.product_qty)is null then 0
else sum(od.product_qty)
end as num
from
products
left outer join
order_details ob
on p.id = od.product_di
group by p.id;
演習
・全商品を累計販売個数でランク分けする
・ランクが高い順に並び替え￥いてる
・商品ID
・商品名
・販売個数
・ランク（A or B or C）
select
p.id,
p.name(product_qty),
case
when sum(product_qty) >= 20 then 'A'
when sum(product_qty) >= 10 then 'B'
when
end
sum(product_qty)
from
products
left outer join
order_details od
on p.id = od.product.id
group by p.id
order by rank;
応用問題
◾️全期間での平均客単価
・単価は小数第一位で四捨五入
select
round(avg(amount), 0)
from
orders;
◾️月別での平均客単価
・単価は小数第一位で四捨五入
select
date_format(order_time, '%Y%m') as order_year_month,
round(avg(amount), 0) as average_customer_spend
from
orders
group by
date_format(order_time, '%Y%m')
order by order_year_month
;
◾️都道府県別平均客単価
・単価は小数第一位で四捨五入
select
pref.id as prefecture_id,
pref.name as prefecture_name,
round(avg(o.amount), 0) as average customer spend
from
orders o
inner join users u
on o.user_id = u.id
inner join prefectures pref
on u.prefecture_id = pref.id
group by
pref.id
order by
pref.id
;
◾️都道府県別・月別平均客単価
・単価は小数第一位で四捨五入
select
pref.id as prefecture_id,
pref.name as prefecture_name,
date_format(o.order_time, '%Y%m') as order_year_month
round(avg(o.amount, 0) as average_customer_spend
from
orders o
inner join users u
on o.user_id = u.id
inner join prefectures pref
on u.prefecture_id = pref.id
group by
prefecture_id, order_year_month
order by
prefecture_id, order_year_month
;
データの更新
・新商品を１件追加
・商品名：新製品A
・価格：1,000円
構文
insert into
テーブル名（列１、列２、列３・・・）
values
（値１、値２、値３・・・）
insert into products(name, price) values('新商品A', 1000);
select * from products;
列を省略してinsert
例）insert products values(1002, '新商品A', 2000);
・values句に列の定義順、カンマ区切りで値を設定
・ただし、列を省略するには条件がある
・テーブルの全列に対して、値を指定する必要がある
行を複数行追加
・新商品３件をデータベースに追加
・商品名：新商品C
価格：３,０００円
・商品名：新商品D
価格：４,０００円
・商品名：新商品E
価格：５,０００円
構文
insert into
テーブル名（列１、列２、列３・・・）
values
（値１、値２、値３・・・）,
（値１、値２、値３・・・）,
（値１、値２、値３・・・）;
insert into products(name, price)
values
('新商品C', 3000),
('新商品D', 4000),
('新商品E', 5000);
select * from products;
データの更新UPDATE
・全商品を１０％引き
select * from products;
set sql_safe_updates = 0;
update products set price = price * 0.9;
select * from products;
特定の条件に合致する行のデータを更新する
・商品ID３の商品名を「SQL入門」と書き換える
構文
update テーブル名 set 列１ = 値１, [列２ = 値２...]
[where 条件式];
select * from products where id = 3
update products set name = 'SQL入門' where id = 3
select * from products where id = 3;
update products set name = 'SQL入門1', price = 1000 where id = 3;
select * from products where id = 3;
更新条件にサブクエリを使う
累計販売数が１０を超えている商品については、価値を５％UPする。
select
product_id,
sum(product_qty)
from
order_details
group by
product_id
having
sum(product_qty) >= 10
;
select * from products
update
products
set
price = price * 1.05
where
id in
(
select
product_id
from
order_details
group by
product_id
having
sum(product_qly) >= 10
);
行の削除
・商品に割り当てられている商品カテゴリを使うのを止めるため、商品とカテゴリの紐付きを削除する
select * from products_categories;
delete from products_categories;
※deleteで削除したデータは基本的には元に戻せない
大量のデータをdeleteするときに予想外に時間がかかる場合がある
条件を指定して行の削除
select * from products where id = 1001;
delete from products where id = 1001;
select * from products where id = 1001
削除条件にサブクエリを使う
・１個も売れていない商品は、売るのを止めるため削除する
select
product_id
from
order_details
group by
product_id;
delete
from
products
where
id not in(
select
product_id
from
order_details
group by
product_id
) ;
データベース構造の操作
データベースの追加
構文
create detabase データベース名;
show databases;
create database book_store;
show databases;
テーブルの追加
// データベースの選択
use book_store;
show tables;
create table books(id int not null auto_increment primary key, title varchar(255) not null);
・列 ID
int：整数型
not null：nullを許可しない
auto_increment：idを自動的にふる
primary key；主キーの設定
・列名 title
varchar(255)：最大２５５文字の可変長文字列型
not null：nullを許可しない
テーブル構造の変更
・列の追加
use book_store;
show columns from books;
alter table books add price int affter id;
show columns from books;
・列名の変更
構文：alter table テーブル名 change 旧列名 新列名 データ型;
alter table books change price unit_price int;
・列名の削除
構文：alter table テーブル名 drop 列名;
alter table books drop unit_price;
テーブルの削除
構文：drop table テーブル名;
show tables;
drop table books;
show tables;
データベースの削除
構文：drop database データベース名;
show databases;
drop database book_store;
show databases;
