クラウドプラクティショナーの用語集は下記記事で案内しております。

「【AWS】クラウドプラクティショナー用語一覧」

公式Amazonのドキュメントが最も信頼できるので気になる方は「こちら」から。

AWSクラウドプラクティショナー無料問題

「クラウドの概念」無料問題

問題1

AWSのアーキテクチャ設計において考えるべき必要がないものは？

1. スケーラビリティを確保
2. 環境構築の自動化
3. リソースを使い捨てできるようにする
4. ソースコードの管理

問題2

AWS Well-Architected Framework(W-A)に含まれないものは？

1. セキュリティ
2. パフォーマンス
3. 耐震性
4. 信頼性

問題3

リージョンについて正しい情報はどれか？

1. リージョンはセキュリティを担保するためにある
2. リージョンにはAZが最低1つは含まれる
3. 日本のリージョンは1つで東京にある
4. リージョンは耐障害性を高めるためにある

問題4

AZ（アベイラブルゾーン）について間違った情報はどれか？

1. 東京リージョンには4つのAZがあると言われている
2. 冗長的な電力源を持つ
3. 低遅延で相互接続された2つ以上のデータセンター
4. AWSリージョンをまたがることはできない

問題5

エッジロケーションの情報で間違っているものは？

1. エッジロケーションはAZの一部のデータセンターのことである
2. 動画のローディングなどの重たい処理に利用される
3. サービスとして、DNSがある
4. サービスとして、CDNがある

問題6

クラウドサービスに関して正しい説明はどれか？（複数回答）

1. IaaSではネットワーキング機能、コンピュータ機能、データストレージ領域へのアクセスが提供されます。
2. SaaSでは基盤となるインフラストラクチャの管理を考える必要がなくなります。
3. PaaSではリソース調達、容量計画、パッチ適用などを考慮する必要がなくなります。
4. クラウドサービスは有料である

問題7

クラウドのデプロイモデルに関して正しい説明はどれか？（複数回答）

1. ハイブリッドデプロイモデルとはクラウドのリソースとクラウド以外の既存リソースとの間でアプリを接続するモデル
2. オンプレミスデプロイモデルは仮想化および、リソース管理ツールを使用してリソースをオンプレミスでデプロイする構成
3. オンプレミスデプロイモデルはプライベートクラウドとも呼ばれる
4. クラウドデプロイモデルは完全にクラウド上だけでデプロイされている構成

「クラウドのセキュリティ」無料問題

問題8

コンプライアンスレポートをダウンロードできるサービスはどれか？

1. AWS Key Management Service
2. AWS Security Hub
3. AWS Artifact
4. AWS Secret Manager

問題9

AWS Game Dayについて間違った説明は？

1. AWSの信頼性を高めるためのイベント
2. Chaos Mokeyというソフトを使う
3. 障害を起こす側と守る側でスコアを競う
4. AWS Game Dayの日にはすべてのAWSサービスが使用できなくなる

問題10

機械学習を用いたクラウドネイティブな脅威検知サービスはどれか？

• AWS GuardDuty
• Inspector
• AWS X-Ray
• AWS WAF(ウェブアプリケーションファイアウォール)

問題11

Inspectorの説明で間違っているものはどれか？

1. Inspectorは設定すると自動で継続的なアセスメントを行う
2. セキュリティリスクを評価する
3. ユーザにベストプラクティスを提供する
4. Inspectorサービスは無償サービスである

問題12

ユーザがサービスのセキュリティを強化したい場合、利用するべきサービスはどれか？（※複数回答）

1. IAM
2. MFA
3. AMI
4. セキュリティグループ

問題13

IAMについて間違っている情報はどれか？

1. IAMは無償サービスである
2. IAMの正式名称は「Identify and Management」である
3. ユーザにロール単位で権限を付与できる
4. MFAをユーザに付与することもできる

問題14

AWS KMS（Key Management Service）の説明で正しいものはどれか？（※複数回答）

1. キーの作成ができる
2. 外部キーをインポートできる
3. 1年ごとに自動でキーを更新するように設定できる
4. 無償サービスである

問題15

AWS Shieldに関して正しい説明はどれか？

1. 有償サービスである
2. デフォルトでAWSサービスに組み込まれている
3. アベイラビリティゾーンのサービス
4. SQLインジェクションを保護する

問題16

IAMの説明で正しいものは？（※複数解答）

1. IAMポリシーはユーザにAWSリソースへのアクセス許可設定を提供するドキュメント
2. IAMユーザはグループ化することで、組織に合わせてポリシー管理を楽できる
3. IAMのアクセスキーとシークレットキーはユーザに紐づく
4. AWSロールはAWSリソースにAWSサービスへのアクセスを提供できる

問題17

データベースやその他のアプリケーションにアクセスするために使用される認証情報やアプリケーションを管理するサービスはどれか？

1. AWS Secrets Manager
2. AWS Security Hub
3. AWS IAM
4. AWS KMS（Key Management Service）

問題18

AWS RAM（Resource Access Manager）について間違った説明はどれか？

1. AWS RAMはAWSリソースを組織内のアカウントやサービスと簡単に共有するためのサービス
2. 複数のアカウント間でのリソース共有を簡素化できる
3. セキュリティを向上できる
4. AWS RAMの承認期限は24時間である

問題19

AWSの責任範囲でないものは説明で間違っているものはどれか？

1. データセンターのハード保守
2. データベースのパッチ適用
3. EC2のパッチ適用
4. AWSサービスのバグ

問題20

セキュリティに関して正しい説明はどれか？

1. サブネットに対して、セキュリティグループを設定することで通信トラフィックを制御する
2. インスタンスにネットワークACL（Access Control List）を設定することで、ファイアーウォールと同じように使用できる
3. ネットワークACLは拒否するインバウンドポートと送信元を設定するブラックリスト方式
4. セキュリティグループはデフォルトでは全トラフィックが開いた状態になっている

「クラウドのテクノロジー」無料問題

問題21

ユーザのアクティビティとAPI使用状況を追跡する監査サービスはどれか？

1. AWS CloudTrail
2. Cloud Watch
3. AWS Personal Health Dashboard
4. AWSインフラストラクチャーイベント管理

問題22

Amazon Auroraの特徴で間違っているものはどれか？

1. MySQLと互換性がある
2. PostgreSQLと互換性がある
3. 自動バックアップが実行される
4. キーバリューストア方式でデータを保存する

問題23

動画などの大容量ファイルをローミングする際に使用されるAWSのサービスはどれか？（※複数解答）

1. エッジローケーション
2. Amazon EFS
3. Amazon CloudFront
4. Amazon Cognito

問題24

Amazon CloudFrontの説明で間違っているものはどれか？

1. コンテンツがエッジロケーションにない場合、Amazon S3からデータを取得する。
2. コンテンツがエッジロケーションにない場合、DBから値を取得する
3. コンテンツがエッジロケーションにない場合、MediaPackageチャネルからデータを取得する
4. コンテンツがエッジロケーションにない場合、HTTP通信でインターネットからデータを取得する

問題25

ユーザへのキャンペーン通知などを特定のユーザに絞って処理を実行する際に使用するものはどれか？

1. AWS Device Farm
2. Amazon SNS
3. Amazon Pinpoint
4. AWS Step Function

問題26

アプリケーションにログイン画面を追加しようと考えている。ログイン画面とログイン処理を簡単に行うために利用するサービスはどれか？

1. Amazon SQS
2. Amazon Cognito
3. AWS ConfirmEntry
4. AWS Config

問題27

アプリが処理するリクエストに関するデータを収集するサービスはどれか？

1. AWS X-Ray
2. Amazon Cloud Watch
3. AWSマネジメントコンソール
4. Cloud Trail

問題28

Amazon Cloud Watchの説明で正しいものはどれか？（※複数回答）

1. 標準メトリクスで収集できるのは「ネットワークIO」「CPU使用率」「メモリ使用率」など
2. エージェントを起動し、カスタムメトリクスを利用すれば「ディスク空容量」も監視可能
3. 環境内の異常動作を検知し、アラートの設定が可能
4. ログとメトリクスを視覚化し、自動化したアクションを実行できる

問題29

ある会社が日中しか利用しないサービスをAWSで動かそうと考えています。費用面的にEC2は夜間はシャットダウンさせる予定です。その際にデータを保存しておくのに役立つストレージサービスはどれか？

1. Amazon EC2インスタンスストア
2. Amazon EBS(Amazon Elastic Block Store)
3. Amazon Night DB
4. Amazon TMP DB

問題30

ある企業でHTTPSプロトコルを使用して、SSLエンドポイント経由でデータを安全にアップロードしたいと考えている。データが保存される先はどれか？

1. EBS
2. Amazon EC2インスタンスストア
3. S3
4. EFS

HTTPS プロトコルを使用して、SSL エンドポイント経由で Amazon S3 にデータを安全にアップロードまたはダウンロードできます。

問題31

EC2に関して正しい説明はどれか？（※複数解答）

1. 従量課金で利用可能な仮想サーバー構築サービス
2. EC2を別リージョンに複数設置することで、セキュリティ面が向上する
3. マネージドサービスである
4. EC2に対してパッチ適用を行うのはユーザ側の責任である

問題32

EC2 Auto Scalingの説明で正しいものはどれか？（複数解答）

1. 耐障害性を向上させる
2. アプリの可用性を向上させる
3. コストの削減が見込める
4. 利用料金はAuto Scaling設定時にEC2の増減範囲によって月額で請求される

問題33

複数のEC2インスタンス間でファイルを共有したい場合に利用するサービスはどれか？

1. Amazon EBS
2. Amazon EFS
3. Amazon VPC
4. Amazon EMR

問題34

EC2インスタンスのクラスタでコンテナ化されたアプリを実行できるサービスはどれか？

1. Amazon ECR
2. Amazon MCS
3. Amazon ECS
4. Amazon Batch

問題35

ウェブサイトやウェブアプリケーションを構築する必要がある開発者が Amazon Web Services (AWS) の使用を開始する最も簡単な方法はどれか？

1. EC2
2. Lambda
3. LaightSail
4. テクニカルサポート

問題36

ある会社ではウェブアプリに検索ソリューションを設定しようと考えている。その際に最も適したAWSサービスはどれか？

1. Amazon CloudMap
2. Amazon CloudSearch
3. Amazon SearchSolution
4. Amazon SearchMap

問題37

インタラクティブなクエリサービスで、AmazonS3内のデータを標準SQLを使用して簡単に分析するサービスはどれか？

1. Amazon Neptune
2. Amazon Athena
3. Amazon Kinesis
4. Amazon Polly

問題38

Amazon RDSの説明で間違っているものはどれか？

1. リレーショナル型のデータベース
2. MySQL、Oracle、SQL Server、PostgreSQL、MariaDB、Auroraのエンジンを選択できる
3. 負荷分散のためのリードレプリカを作成できる
4. 設定を加えると自動バックアップ機能が追加される

問題39

Amazon S3(Amazon Simple Storage Service)に関して正しい説明はどれか？

1. S3サービスを利用する際はAZを指定する必要がある
2. S3サービスを利用する際にストレージ量を決めてからサービスが起動される
3. S3に設定を追加することで、スケーリングを自動で行うことができる
4. サーバー側のSSEオプションを使用して、保存データを暗号化できる

問題40

Amazon Batchの説明として間違っているものはどれか？

1. フルマネージド型のバッチ処理実行環境サービス
2. Docker コンテナとして実行できるあらゆるジョブをサポート
3. インタラクティブな処理に向いている
4. 数十万件のバッチジョブでも効率的に実行可能

問題41

インフラストラクチャをコードとして管理し、AWSリソースの起動・設定等をするサービスはどれか？

1. AWS CodeDeploy
2. AWS CloudFormation
3. AWS AutoInfrastructure
4. AWS CodeBuild

問題42

Amazon S3に関して正しい情報はどれか？（※複数解答）

1. S3にはURLでアクセス可能することができる
2. 耐久性は99.999999999%(イレブンナイン)である
3. AZを指定して、リージョン内に直接自動的なレプリケートが出来る
4. 保存されたデータは自動的に3か所以上の別リージョンのデータセンターに複製される

問題43

ビッグデータフレームワークとして、大量のデータを処理および分析するマネージド型クラスタープラットフォームサービスはどれか？

1. Amazon Redshift
2. Amazon EMR
3. Amazon Macie
4. Amazon Machine Learning

問題44

Amazon EBSの説明で正しいものはどれか？（※複数解答）

1. EC2を起動後にアタッチすることができる
2. 暗号化が可能
3. 容量は後から変更可能
4. スナップショット機能で差分バックアップができる

問題45

ある企業で1年に1度確認するかわからない公文書を保存するストレージをクラウドに保存しようと考えています。読み取りまでに時間はかかっても問題ない場合、どのストレージが適しているでしょうか？

1. S3
2. S3 Glacier
3. EBS
4. EFS

問題46

Amazon VPC(Virtual Private Cloud)に関して間違っている説明はどれか？

1. 論理的に分離された仮想ネットワークで、AWS内にユーザ専用のネットワーク空間を提供する
2. AZをまたがることができる
3. 通信プロトコルにはIPv6のみを採用している
4. インターネットに接続するためにはインターネットゲートウェイを使用する

問題47

VPCに設定できるサブネットに関しての説明で正しいものはどれか？

1. サブネットはAZを跨いで作成することができる
2. パブリックサブネットではインターネットゲートウェイにルーティングされる
3. プライベートサブネットはインターネットゲートウェイにルーティングされるが、特定のサイトのみにアクセスできる
4. AWSアカウントで共有できるサブネット数は256である

問題48

複数のVPC間で異なるリージョン間での通信ができるサービスはどれか？

1. VPCピアリング
2. AWS Transit Gateway
3. AWS Fargate
4. AWS Directory Service

問題49

ある企業が保有するオンプレ環境のデータをキャリア専用回線を使用してAWSにデータを転送したいと考えています。適したサービスはどれか？

1. AWS VPN
2. Amazon Connect
3. Data Pipeline
4. AWS Diret Connect

問題50

AWS導入前にAWSを使って期待するビジネス上の成果を達成するためのサポートはどれか？

1. プロフェッショナルサービス
2. エンタープライズサポート
3. ビジネスサポート
4. ディベロッパーサービス

問題51

AWSにおいて全ての組織およびアカウント全体で大規模にセキュリティ・コンプライアンスルールを適用できるサービスはどれか？

1. AWS Config
2. AWS Control Tower
3. AWS Inspector
4. AWS Artifact

問題52

音声とテキストを使用してアプリケーションに会話型インターフェイスを構築するためのサービスはどれか？

1. AWS Glue
2. Amazon Lex
3. Amazon Fsx
4. Amazon Rekognition Image

問題53

ソースコードからビルドしたソフトウェアを本番環境にリリースするために必要なステップのモデル化、および自動化に使用できる継続的な配信サービスはどれか？

1. AWS OpsWorks
2. AWS CodeCommit
3. AWS CodePipeline
4. AWS DataPipeline

問題54

エクサバイト規模のデータ転送サービスでトラックでデータを運ぶサービスはどれか？

1. AWS Snowball Edge
2. AWS Snowball
3. AWS Snowmobile
4. AWS Snowexa

問題55

DynamoDBの説明で正しいものはどれか？（※複数回答）

1. データの形式はJSON
2. 高速で予測可能なパフォーマンスとシームレスな拡張性を持つ
3. キーバリューという構造
4. 完全マネージド型のNoSQLデータベースサービス

問題56

AWSのEBSボリュームの暗号化で使用できるサービスはどれか？

1. AWS STS（Security Token Service）
2. AWS KMS（Key Management Service）
3. アクセスキー
4. AWS Certificate Manager

問題57

AWS Certificate Managerで正しい説明はどれか？（※複数解答）

1. SSL/TLS 証明書で使用されるプライベートキーを保護できる
2. AWS基盤内の各種サービスでの利用に限り、SSL証明書を無料で作成できる
3. サードパーティの証明書はインポートできない
4. 各種AWSサービスにSSL証明書をデプロイできる

問題58

AWS Trusted Advisorについて間違った説明はどれか？

1. AWS Trusted AdvisorはAWS環境を分析し、最適化するベストプラクティスを提供するサービス
2. ビジネスサポートで使用できる
3. エンタープライズサポートで使用できる
4. AWS Trusted Advisorでは「コスト最適化」「パフォーマンス」「可用性」「耐障害性」「サービスクォータ」の観点でチェックを行う

問題59

直感的なウェブベースのUIでAWSリソースを管理できるインターフェイスはどれか？

1. AWS Compute Optimizer
2. AWS マネージメントコンソール
3. AWS System Manager
4. AWS インフラストラクチャーイベント管理

問題60

EC2インスタンスが同じ量のトラフィックを取得するよう調節するAWSサービスはどれか？

1. Route 53
2. ALB（Application Load Balancer）
3. ELB（Elastic Load Balancing）
4. NLB（Network Load Balancer）

問題61

AWS上でのイベント発生のタイミングで通知を行うサービスはどれか？

1. AWS SMS
2. Amazon SES
3. Amazon SNS
4. Amazon SQS

問題62

AWS Elastic Beanstalkの説明で正しいものはどれか？（※複数回答）

1. AWSにアプリケーションをデプロイするための最も早くて簡単な方法である
2. アプリケーションの容量プロビジョニング、負荷分散、自動スケーリング、およびアプリケーションのモニタリングなどの機能を提供するサービス
3. 容量のプロビジョニング、ロードバランシング、スケーリングができる
4. アプリケーション状態モニタリングといった詳細を自動的処理する

問題63

ファイル送信やWebアプリのレスポンスの高速化を行うためのAWSサービスはどれか？（※複数回答）

1. Amazon S3 Transfer Acceleration
2. AWS Application Discovery Service
3. AWS Database Migration Service(DMS)
4. AWS ElastiCache

問題64

AWS Lambdaの説明で間違っているものはどれか？

1. サーバなどのインフラ管理を意識せずにコードを実行できる
2. Lambdaから他のAWSサービス間のデータ転送には料金が発生する
3. Lambda登録時にメモリサイズとCPUタイプを指定できる
4. Lambda関数の作成は無料です

問題65

Webおよびモバイルアプリケーション開発プラットフォームであり、フロントエンド開発とクラウドサービスの統合を簡単にするツールとサービスはどれか？

1. AWS Service Catalog
2. AWS AppSync
3. Amazon AppStream 2.0
4. AWS Amplify

問題66

1つのVPCとオンプレミス環境をVPN経由で接続する時にVPCに設置する通信の出入口はどれか？

1. API Gateway
2. AWS Storage Gateway
3. AWS WAF（ウェブアプリケーションファイアウォール）
4. AWS Virtual Private Gateway

問題67

ある企業が自社の保有するサーバでAWSサービスを利用したいと考えています。どのサービスを利用すれば実現可能でしょうか？

1. Amazon EC2 Dedicated Host
2. Amazon Lightsail
3. AWS CloudHSM
4. AWS Lambda

「クラウドの料金と請求」無料問題

問題68

ある企業が2年程度の長期間でAWSサーバ上でアプリを動かしたいと考えています。アプリの使用上、365日24時間常時稼働していることが条件です。最も最適なインスタンスタイプはどれか？

1. オンデマンドインスタンス
2. スケジュールドリザーブインスタンス
3. スポットインスタンス
4. リザーブドインスタンス

問題69

ある企業がサービスが停まっても構わないが、起動させておきたいAWSサーバを探している。最も適したインスタンスタイプはどれか？

1. オンデマンドインスタンス
2. スケジュールドリザーブインスタンス
3. スポットインスタンス
4. リザーブドインスタンス

問題70

企業が請求を詳細なレベルで追跡・分類できるサービスはどれか？

1. AWS Croud Trail
2. AWS Budgets
3. AWS Cost allocation tags
4. AWS Cost Trail

問題71

1つのユーザインターフェイスで複数のAWSアカウントの請求内容を表示・管理・支払いすることができるAWSのサービスはどれか？

1. AWS Consolidated Billing
2. AWS Billing
3. AWS Cost Console
4. AWS Console

問題72

AWS Organizationsの説明で正しいものはどれか？（※複数解答）

1. AWSのルートユーザーに請求が届くサービス
2. 組織内の複数のAWSアカウントに対して、単一の支払い方法を設定できる
3. 一括請求を使用することにより、サービス使用量を集約できたり、料金面での割引などの恩恵を受けることもできる
4. 必要なAWSサービスへのアクセスのみを許可するといったことも可能。

問題73

AWSリソースの使用量を時系列で可視化し、コストや傾向を分析することができるAWSサービスはどれか？

1. AWS System Console
2. AWS Cost and Usage Reports
3. AWS Cost Explorer
4. AWS Cost and Resource Report

問題74

ある企業では現在オンプレミス環境で稼働しているサービスを保有している。このオンプレミス環境をAWSに移行しようと考えているが、予算がどの程度必要かや運用時のオンプレミスとの比較を行いたいと考えています。そういった際、どのAWSサービスを利用するのが最も適しているか？

1. AWS Cost and Usage Reports
2. AWS TCO Calculator
3. AWS Pricing Calculator
4. AWS Budgets

問題75

コストが閾値を超えた場合にアラートを出すサービスはどれか？

1. AWS SNS
2. AWS Alert
3. AWS Budgets
4. AWS Cost Explorer

以上でAWS クラウドプラクティショナーの無料試験問題は終了です。他にもIT関連の記事を記載しているので、興味あればサイト内見て行ってください。

SpringSecurityの依存関係追加

gladleの場合は下記を追加。

dependencies {
  implementation 'org.springframework.boot:spring-boot-starter-security'
  testImplementation 'org.springframework.security:spring-security-test'
}

mavenの場合はpomファイルに下記を追加。

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-security</artifactId>
</dependency>

これでSpringSecurityの準備はできたのでプロジェクトを作成していきます。

Spring Security実装

今回作成するアプリケーションの階層です。

.
├── HELP.md
├── mvnw
├── mvnw.cmd
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   │   └── com
│   │   │       └── example
│   │   │           └── demo
│   │   │               ├── DemoApplication.java
│   │   │               ├── MvcConfig.java
│   │   │               ├── ServletInitializer.java
│   │   │               └── WebSecurityConfig.java
│   │   └── resources
│   │       ├── application.properties
│   │       ├── static
│   │       └── templates
│   │           ├── hello.html
│   │           └── login.html

MvcConfig

package com.example.demo;

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.ViewControllerRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MvcConfig implements WebMvcConfigurer {

	public void addViewControllers(ViewControllerRegistry registry) {
        // ルーティングの設定 
		registry.addViewController("/hello").setViewName("hello");
		registry.addViewController("/login").setViewName("login");
	}
}

上記でURLのルーティング設定をします。

WebSecurityConfig

package com.example.demo;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
@EnableWebSecurity
public class WebSecurityConfig {

	@Bean
	public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
		http
			.authorizeHttpRequests((requests) -> requests
				.requestMatchers("/", "/home").permitAll()
				.anyRequest().authenticated()
			)
			.formLogin((form) -> form
				.loginPage("/login")
                .defaultSuccessUrl("/hello")
				.permitAll()
			)
			.logout((logout) -> logout.permitAll());

		return http.build();
	}

	@Bean
	public UserDetailsService userDetailsService() {
		UserDetails user =
			 User.withDefaultPasswordEncoder()
				.username("user")
				.password("password")
				.roles("USER")
				.build();

		return new InMemoryUserDetailsManager(user);
	}
}

少し解説します。

    @Bean
	public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
		http
			.authorizeHttpRequests((requests) -> requests
				.requestMatchers("/", "/home").permitAll()
				.anyRequest().authenticated()
			)
			.formLogin((form) -> form
				.loginPage("/login")
                .defaultSuccessUrl("/hello")
				.permitAll()
			)
			.logout((logout) -> logout.permitAll());

		return http.build();
	}

上記の「formLogin」部分が認証処理のメイン部分です。

ログインページを開いた際に認証が成功した場合、defaultSuccessUrlで指定している認証成功後画面に遷移します。

認証処理は下記です。

	@Bean
	public UserDetailsService userDetailsService() {
		UserDetails user =
			 User.withDefaultPasswordEncoder()
				.username("user")
				.password("password")
				.roles("USER")
				.build();

		return new InMemoryUserDetailsManager(user);
	}

今回の認証はユーザ名がuser、パスワードがpasswordでフォームに入力された値と一致すれば認証が通るようになっています。

テンプレート

ログイン画面

HTML「login.html」ファイルを下記のように記載。こちらはログイン画面になります。

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:th="https://www.thymeleaf.org">
    <head>
        <title>Spring Security Example </title>
    </head>
    <body>
        <div th:if="${param.error}">
            Invalid username and password.
        </div>
        <div th:if="${param.logout}">
            You have been logged out.
        </div>
        <form th:action="@{/login}" method="post">
            <div><label> User Name : <input type="text" name="username"/> </label></div>
            <div><label> Password: <input type="password" name="password"/> </label></div>
            <div><input type="submit" value="Sign In"/></div>
        </form>
    </body>
</html>

解説していきます。

<div th:if="${param.error}">
    Invalid username and password.
</div>

上記がエラーがあった場合の画面表示の切り替えです。

<div th:if="${param.logout}">
    You have been logged out.
</div>

上記は同様にログアウト時の切り替えです。

<form th:action="@{/login}" method="post">
    <div><label> User Name : <input type="text" name="username"/> </label></div>
    <div><label> Password: <input type="password" name="password"/> </label></div>
    <div><input type="submit" value="Sign In"/></div>
</form>

上記がログインフォームです。

inputタグのname属性「username」「password」を付与している項目が認証処理にPost通信される部分です。

ログイン成功後の画面

HTML「hello.html」ファイルを下記のように記載。こちらはログイン後の画面になります。

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:th="https://www.thymeleaf.org">
    <head>
        <title>ログイン成功</title>
    </head>
    <body>
        <h1>ログイン成功
</h1>
    </body>
</html>

これで準備完了です。

アプリの起動

アプリ起動後「http://localhost:8080/login」をブラウザで開きます。

認証に失敗した場合

認証に成功した場合

以上で今回の記事は終了です。今回は認証処理を簡略化していますが、次回はDBの値を参照するなどを試してみます。

データベーススペシャリストについて知ろう

データベーススペシャリストに限らず、高度情報技術者試験は4部構成です。

• 午前1：応用情報の午前試験と同じ。免除あり。
• 午前2：SQLとSQL関連用語をメインとする試験
• 午後1：DB関連の読解問題
• 午後2：DB関連の読解問題

それぞれの対策としては下記です。

• 午前1：応用情報過去問でひたすら対策
• 午前2：本記事の用語・SQLを全て網羅→高度情報過去問をひたすらこなす
• 午後1：本記事の用語・SQLを全て網羅→高度情報過去問で読解方法を学び問題形式になれる＋時間内に解答できるようになる
• 午後2：本記事の用語・SQLを全て網羅→高度情報過去問で読解方法を学び問題形式になれる＋時間内に解答できるようになる

データベーススペシャリスト 頻出用語

正規化系

正規化

• 第1正規化：繰り返し項目の排除
• 第2正規化：主キーで決まる項目の排除
• 第3正規化：主キー以外で決まる項目の排除

情報無損失分解

分解された部分同士の自然結合によって元の関係を過不足なく復元できる性質。第3正規形までは保てる。

関数従属性保存

分解後の部分が元の関係に存在した関数従属性を保っている性質。第3正規形までは保てる。

関係従属性

関数従属性の推論則は下記のようになっている。

• 反射率：BがAの部分集合であればA→Bが成立する
• 増加率；A→Bであれば、同じCを加えて{A,C}⇨{B,C}が成立
• 推移率：A→BかつB→Cであれば、A→Cが成立
• 合併率：A→BかつA→Cであれば、A→{B,C}が成立
• 分解率：A→{B,C}であれば、A→BおよびA→Cが成立

SQL関連

セミジョイン法

分散型のDBに保存されているデータの結合時のデータ転送量を削減する方法。2つの表の1方から必要な項目をもう片方の表に送り、結合をする。

ソートマージ法

結合演算のコストを最適化する手法。（不必要な行同士の結合を防ぎます。）

計算系

直積

直積はデータ操作で、2つの関係(表)に含まれる要素のすべての組合せから成る表のことです。

べき等

複数回同一操作をしても、一回しか実行しなくても結果が同じになる（selectなど）

等結合演算

直積と選択で実現できる。

ストアドプロシージャ

一連の処理手順をプログラムとしてまとめて実行できる処理モジュールをDBMS上に用意したもの。

CHAR(10)は常に10バイトでそれ以下のバイトの場合はバイト数がその数に減る。そのバイト数は固定。VARCHARは可変長。補足：日本語は2バイト。

インデックス

B木インデックス

データ量が増加してもパフォーマンス低下が少ない。どのキーに対しても、ランダム検索や範囲検索（between）、挿入・更新・削除を効率よく行うことができる。データの分布やに隔たりがある場合や、NULL値および否定を含む検索条件では効果を発揮できない。

ビットマップインデックス

キーがとり得る値の種類が数個程度と少ない場合に適したインデックス。NULL値の検索ができ、WHEREやAND/OR、NOTなどの否定検索でも使用できる。

スキーマ関連

ANSI/SPARC 3層スキーマ

概念・外部・内部スキーマの三つのグループにわけてデータ定義。物理的・理論的データの独立性を達成するためのアーキテクチャ。

• 概念スキーマ
  データベース化対象業務とデータの内容を理論的なデータモデルとして表現する
• 外部スキーマ
  概念で定義されたデータモデル上に利用者ごとの目的に応じた見方を表現、リレーショナルモデルのビューやネットワークモデルのサブスキーマ。個々のプログラムまたはユーザの立場から見たデータベースの記述。
• 内部スキーマ
  概念スキーマで定義されたデータモデルを記憶装置上にどのような形式で格納するかを表現。ファイル編成やインデックスの設定など。概念スキーマをコンピュータ上に具体的に実現させるための記述。

スタースキーマ

データウェアハウスの実装で用いられる。ファクトテーブルとディメンションテーブルで構成。中心にファクトテーブル。ディメンションテーブルは複数の条件とその条件の組み合わせに対する処理や行動の関係を一覧にした表で、スター型構造を持つ。
ファクトテーブルは売上や注文など時間を追うごとに発生するイベントの実測値である。

データディクショナリ

データディクショナリ(DD)は、データベースのメタデータやデータ定義情報を効率よく管理する情報の保管庫。他のデータベースと同じく表とビューで構成されていて次のような情報が格納されています。（概念スキーマ、外部スキーマ、内部スキーマとそれらの変換定義情報など）

ACID特性

データベースのトランザクション処理を行う上で必要不可欠とされる4つの性質(Atomicity・Consistency・Isolation・Durability)の頭文字を並べた言葉。（原子性、一貫性、独立性、永続性）

弱実体/強実体

独立して存在できるエンティティは強実体。
一方のエンティティが消えた場合、存在できなくなるエンティティを弱実体。

トランザクション関連

2層コミット

前半部（ロック獲得）の後、後半部（ロック解除）の流れをとる。
ロック獲得命令を全て実行した後にだけ、ロック解除命令を実行できる。

チェックポイント処理

実行中のトランザクションを一時停止→メモリバッファの内容をディスクに書き出す→チェックポイントレコードを書き出す⇨中断したトランザクションの再開の流れ。

待ちグラフ

実行中のトランザクションを各ノード、データのアンロック待ちの様子を矢印で表現したもの。デッドロックの検出に使用。

WAL(Write Ahead Log)プロトコル

トランザクションがログを安定記憶に書き出すタイミングで、実際の操作に専攻してログの書き出しを求めるもの。更新ログ書き出し→DB更新→commit。

トランザクションの隔離性水準

• ダーティーリード
  他のトランザクションが更新したコミット前の値（ダーティデータ）を読み、その後に更新処理を行なったトランザクションがロールバックされると存在しない値を読み込んでしまうこと。
• ファントムリード
  同じトランザクションで複数回の読み込みを行なった時、前回は存在しなかった行が現れる以上。2回の読み込みの間に別トランザクションがテーブルに行を挿入することで発生。
• ノンリピータブルリード
  同じトランザクション内で再読み込みによって値が変わってしまうこと
• ロストアップデート
  読み書きを行うトランザクションが複数あるとき、一方のトランザクションの更新処理がなかったことになる異常。

DBの設定によって上記を強要するかどうかを判断する。

直列化可能性

複数トランザクションを実行しても、1つづつ順次実行した時と結果が同じになること。

NoSQL

Not only SQLはデータへのアクセス方法をSQLに限定しないデータベース管理システムの総称。キーバリュー型でのデータ格納、カラム指向、ドキュメント指向（XMLやJSONでデータ格納）。NoSQLは結果整合性という考え方に基づいてデータ処理を行う。

結果整合性とは、即座にデータが反映されることを前提とせず、結果的に一貫性が保証されていればそれで良いという考え方。（NoSQLではロックによる整合性担保はないです。）

候補キー

ある関係の1つの組みを一意に決定できる属性。または、属性の組み合わせで極小のもの。極小とは一意に決定するための必要な属性以外が含まれていない状態のことです。（関係内に候補キーが1つしかない場合は、それが主キー、候補キーが複数ある場合、その中から一つが主キーで、残りは代替キーとなります。）

体現ビュー

実表のように実際の値をもち、データベースに格納されるビューのこと。本来のビューは実値を持たない仮想的な表で、メタデータとして、データディクショナリに格納されているだけです、ビューに対する更新は、元の表に対しての更新に変換され実行されます。（ビュー合成と言います。）体現ビューは、この変換処理の負荷を小さくするために考案された手法となっています。

表の分解

2つの表が多対多の場合、中間表に二つの主キーの複合機主キーを持つ中間表を作る。
1対1の関係の場合はどちらかの表に主キーを外部キーとして登録。
1対多 多の方に1の方の主キーを登録。

データベーススペシャリスト 頻出SQL

CREATE文

テーブル作成

create table テーブル名 (id {データ型}, name データ型);

テーブル定義のデータ型一覧

制約

SQLでは下記のように設定。

create table テーブル名 
   (id int primary key, -- 主キー
    name varchar(10) default '名無し' -- デフォルト制約ー
    birthDate Date not null -- 非NULL制約ー
    tel varchar(12) unique -- 主キー
    age int check(age>19) -- 検査制約
    companyCd varchar(4) 
    foreign key (companyCd) -- 外部参照制約
    references 会社テーブル(companyCd) -- 会社テーブルの会社コードは参照元
    on delete set null -- SET NULLオプション設定（cascade、no actionも同様）
    );

表明（CREATE ASSERTION）

一つ、または複数のテーブルの列に対して制約を定義し、テーブル間にまたがる制約や、SELECT文を使った複雑な制約を定義できる。下記はid_checkという制約を作成。チェックの中身はendFlagが0のデータが存在しているか。

create assertion id_check check(not exist (select * from sample where endFlag = 0);

定義域（CREATE DOMAIN）

新しいデータ型を定義できる。下記はsampleというデータ型を定義。sampleはinteger型のデータで5より大きく10より小さい値を取ることができる。

create domain sample as int check(id > 5) and (id < 10);

制約名の付与（CONSTRAINT）

例えば主キー制約に名前をつけたい場合は、下記のように設定する。

create table sample (id int primary key ...
↓
create table sample (id int constraint test_pk primary key ...

test_pkという名前を設定した主キー制約のみを削除したい場合などはalter tableの条件で絞って対応できる。

VIEWの作成（CREATE VIEW）

各テーブルからの取得結果などを表として扱える仮想テーブル。

新しくテーブルを定義するための容量の削減、生合成確保、実テーブルのデータ誤操作や喪失リスクの低減、セキュリティ向上などの理由で利用可能。

-- サンプルテーブルのidとnameのみの仮想テーブルを指定したビュー名で作成する。
create view {ビュー名} as select id name from sample

ビューは下記条件を満たす場合、更新可能。

1. 元のテーブルが特定できる
2. 集約関数（AVGやMAXなど）を利用していない
3. GROUP BY句を利用していない
4. DISTINCTを利用していない
5. 権限がある
6. NULLが適切に処理されている
7. WITH CHECK OPTIONへの対応がされている

WITH CHECK OPTIONは、viewにデータをinsertしようとした際などに、このオプションで設定したwhere句などの条件に対応しているかをチェックできるもの。

ビューを作成するにあたって、ビュー作成元のテーブルがSELECT権限が必要。また、ビューを使用するユーザはビューの所有者の場合は、SELECTは可能で、その他データ操作に関しては元テーブルの権限に従う。所有者以外に関してはビューに関する権限に従う。

ビューの元表が削除された場合は、ビューも強制的に削除される。また、付随する権限も全て削除される。

また、as 〇〇で指定したカラムは元のカラム名ではなく、〇〇で参照する必要がある。

ROLEの作成（CREATE ROLE）

ロールとは権限のことで、ユーザに対して付与する権限をまとめてロールとして管理する。

流れとしてはロールの作成→ロールに権限を付与する→ロールをユーザに付与。

-- ロール作成
create role {ロール名}
-- ロールに権限付与
grant select on {秘密ビュー} to {ロール名}
-- ユーザにロール付与
grant {ロール名} to {ユーザ}

※grant文の説明は後述。

GRANT

grant文

create roleの箇所で出てきましたがGRANT文は権限を付与するSQL。下記が基本構文。

grant {権限} on {テーブル名またはビュー名} to {ユーザ名};

権限にはSELECT・UPDATE・DELETE・INSERT、左記を全て含む全権限はALL PRIVILEGESがある。

WITH GRANT OPTION

末尾に付けることができ、与えられた権限を他のユーザに付与できる。

grant {権限} on {テーブル名またはビュー名} to {ユーザ名} with grant option; 

REVOKE

GRANTで付与した権限を取り消す。

revoke {権限} on {テーブル名またはビュー名} from {ユーザ名};

DROP

テーブル・ビュー・ロールの削除などを実施するSQL。

drop tabel {テーブル名}
drop view {ビュー名}
drop role {ロール名}

SELECT文

データを取得。

select id from {テーブル名};

計算式

四則演算可能。（＋,-,*,/）

列連結

文字列同士の連結が可能。

select '名前は'||name from {テーブル名};

テーブル名の指定

テーブル名に別名を付けられる。（ASは省略可能）

select id from {テーブル名} as Table1;

重複を除く

select distinct name from {テーブル名};

NULL処理

coalesce(id,0,…)の形で記載でき、左からNULLでない最初の引数を返します。

select coalesce(id,0) from {テーブル名};

条件分岐

caseを利用して条件分岐を作れます。下記は20歳未満、21〜60歳、61歳以上で金額を分岐するSQL。

select 
    case when age < 20 then 100
    case when age < 60 then 500
    else 50 end
from {テーブル名};

where句

条件を指定してデータを絞る句。

基本の条件句

>、=、＜などの範囲を指定する記号。
is null、is not nullのnullを判断する記号。
部分一致ができるlike。（％を利用）
not 〇〇は否定を表す。

BETWEEN句

範囲内のものを検索。

where date between '2024-01-01' and '2024-12-31';

IN句

inで指定するもの全てを取得する。

where id in (1,2,4);

ORDER BY句

データの並び順を指定。（ASC：昇順、DESC：降順）

order by {並び順を指定するカラム} ASC

GROUP BY句

データをグループごとにまとめて取得する。group by句でselectできる項目は、group by句の後ろに記載する項目と計算系（count,avg,maxなど）で出力する結果のみです。

（データ例）
テーブル名：sample
class  point
a    |  10
a    |  20
b    |  30
a    |  30
b    |  30

select class,avg(point) from sample group by class,point;
------
a 20
b 30
------

HAVING句

group by句に条件句をつける場合に使用。group by句でグループ化したデータにはwhere句は使えない。

クラス  点数
a      10
a      20
b      30
a      30
b      30

select クラス,avg(点数) from 上のテーブル group by クラス having クラス = a
------
a 20
------

whereを使えないのはあくまでもgroup by句の後の話で、上記のような場合は、where句が使用できます。

select id,sum(cost) from Sample1 where id > 3 group by id;

上記の場合だと、whereが優先して処理される。

集約関数

COUNT()

データ件数を取得する。

select count(*) from テーブル名;
→{テーブルのデータ件数}

MAX()

項目の最大値を取得。（最小値取得はmin関数）

select max(id) from テーブル名;
→idの最大値

AVG()

項目の平均値を取得。

select avg(point) from テーブル名;
→点数の平均値

SUM()

項目の合計値を取得。

select sum(point) from テーブル名;
→点数の合計値

テーブル結合

複数のテーブルを組み合わせて結果を取得する。

内部結合（INNER JOIN）

内部結合では各テーブルに両方存在するものが出力される。

テーブル1  テーブル2
id cd     cd   item
1   1      1   ball
2   2      2   pen
3   1      3   apple
4   4

select id,name from {テーブル1} inner join {テーブル2} on テーブル1.cd = テーブル2.cd;
↓
1,ball
2,pen
3,ball

テーブル間のカラム名が同じものの場合はusingを使用できる。

左外部結合（LEFT JOIN）

テーブル1にあるデータは全て表示される。テーブル2にないデータの場合はその項目はnullになる。

テーブル1  テーブル2
id cd     cd   item
1   1      1   ball
2   2      2   pen
3   1      3   apple
4   4

select id,name from {テーブル1} inner join {テーブル2} on テーブル1.cd = テーブル2.cd;
↓
1,ball
2,pen
3,ball
4,null

右外部結合（RIGHT JOIN）

テーブル2にあるデータは全て表示される。テーブル1にないデータの場合はその項目はnullになる。

テーブル1  テーブル2
id cd     cd   item
1   1      1   ball
2   2      2   pen
3   1      3   apple
4   4

select id,name from {テーブル1} inner join {テーブル2} on テーブル1.cd = テーブル2.cd;
↓
1   ,ball
3   ,ball
2   ,pen
null,apple

全外部結合（FULL JOIN）

テーブル1  テーブル2
id cd     cd   item
1   1      1   ball
2   2      2   pen
3   1      3   apple
4   4

select id,name from {テーブル1} inner join {テーブル2} on テーブル1.cd = テーブル2.cd;
↓
1   ,ball
2   ,pen
3   ,ball
4   ,null
null,apple

その他の結合

自己テーブルとの結合も可能。（自己結合）

データの四則演算

データの行を四則計算するSQL。

UNION句（和）

テーブル1 テーブル2
id       id
1        2
2        3

select id from {テーブル1}
union
select id from {テーブル2};
↓
1
2
3

union allを使用すると重複も含めて出力

EXCEPT（差）

データが同じものを引く。

テーブル1 テーブル2
id       id
1        2
2        3

select id from {テーブル1}
except
select id from {テーブル2};
↓
1
3

except allを使用すると重複も含めて出力

INTERSECT（積）

どちらにも含まれている値が出力される。

テーブル1 テーブル2
id       id
1        2
2        3

select id from {テーブル1}
intersect
select id from {テーブル2};
↓
2

intersect allを使用すると重複も含めて出力

直積はデータの全ての表示パターンを表示すること。

DIVISION（商）

割り算を実施し、割れたところの行を出力。

テーブル1 テーブル2
id name       id
1  aaa         1
2  aaa         2

select id from {テーブル1}
division
select id from {テーブル2};
↓
aaa

division allを使用すると重複も含めて出力

exists句

こちらもほぼ頻出。条件の中にデータが存在しているかの条件句です。

select count(*) from テーブル where exists 点数 < 30 -- 30以下の点数のデータ抽出される

副問い合わせ（サブクエリ）

こちらも必ず出ます。かっこで囲ってSELECT文の結果を使います。みた方が早いです。

-- 通常のselect文
select id, name from テーブル where id in (0,1,2) ;
-- サブクエリを含むselect文（上記とやっていることは同じだがin句の中身をselect文で取得している）
select id, name from テーブル where id in (select id from テーブル where id < 3); 

-- 通常のinsert文
insert into テーブル (id, name) values (1, 'aaa');
-- サブクエリを使用したinsert
insert into テーブル (id, name) values (select id, name from 取得元テーブル where id < 100);

WITH句

SQL実行中にのみ利用できるテーブル。

with {一時テーブル名} as select id from {テーブル}

select * from {一時テーブル名};
-- 通常のテーブルのように扱えます。

INSERT文

データを追加。

insert into {テーブル名};

UPDATE文

データを更新。

update テーブル名 set {更新するカラム} = {更新データ};

DELETE文

データを削除。

delete from {テーブル名};

カーソル操作

COBOLやC言語などプログラミング言語からSQLを実行する場合に使用。

プログラムの中のSQL文

EXEC SQL 〜
　　　処理
END-EXEC

カーソルの定義

DECLARE {カーソル名} CURSOR FOR

カーソルの使用

EXEC SQL OPEN {カーソル名} : カーソルを開く
         FETCH {カーソル名} into {カーソル内で取得するデータを変数に入れる} : データを取得
         CLOSE {カーソル名} : カーソルを閉じる
         UPDATE 〜 WHERE CURRENT OF {カーソル名} : update文
         DELETE 〜 WHERE CURRENT OF {カーソル名} : delete文
         COMMIT : コミット
         ROLLBACK : ロールバック

セーブポイント

トランザクション内で変更を部分的に取り消すために設定するもの。

その他

その他は、データベーススペシャリストの過去問午前2で出題された、上記のSQLやデータベースに関連しない問題に出てくる用語をまとめたものです。

システムの透過性

• 位置に対する透過性
  利用者はそれが配置されている位置を意識せずにDBを利用できる。
• 移動に対する透過性
  データの格納サイトが変更されても、利用者のアプリや操作方法に影響なし。
• 分割に対する透過性
  一つの表が複数のサイトに分割されて格納されていても、利用者がそれを意識せずに利用できる。
• 複製に対する透過性
  同一のデータが複数のサイトに格納されていても、利用者はそれを意識せずに利用できる。
• 障害に対する透過性
  あるサイトで障害が発生しても、利用者はそれを意識することなく利用できること。
• データモデルに対する透過性
  各サイトのDBMSが扱うデータモデルが異なっていても、利用者は意識することなく利用できる。

OLAP

データウェアハウスやデータマートからデータを取り出し，多次元分析を行う。

• スライシング：多次元データベースをある断面で切り取って2次元の表にする
• ダイシング：スライシングは多次元データベースの中にある縦横軸を指定して、2次元の表にする
• ドリリング：多次元データベースの一部を集計する

割り込み

• 内部割り込み：プログラム割り込み、SVC割り込み、ページフォルト。
• 外部割り込み：タイマ割り込み、コンソール割り込み、入出力割り込み。

リバースエンジニアリング

ソースプログラムを解析してプログラム仕様書を作る手法。

ソースコード変更波及解析

ソースコードを探索し、修正箇所や影響度を調べる。

フェールソフト

リスク

リスク分析

リスクの特質を理解し、リスクの算定を行うプロセス。リスク分析の結果をもとにリスク評価とリスク対応が行われる。

リスク評価額

1回あたりの平均予想損失額にリスクの発生確率を加味して計算される。

投機的リスク

相場などのように利益と損失のどちらかが生じる可能性のある不確実性のこと

純粋リスク

損失のみが生じる可能性のある不確実性のこと。

RAID構成

ホットスタンバイ構成

待機系からは基本的にアクセスはしない。通常系から待機系へ定期的に通信を行い、途切れた際に切り替えなどを契機とする。

共通フレーム

システム要件への追跡可能性、一貫性、設計標準および施系手法、実現可能性、運用保守実現可能性

ソフトウェア開発手法

• ウォーターフォール型
  上流から下流に開発工程を進める開発手法。各工程で品質を担保しながら戻りがない前提の手法
• 成長型プロセスモデル
  ウォーターフォールモデルのプロセスを繰り返す
• スパイラルモデル
  開発工程を何回も繰り返しながら開発機能を拡大する手法
• プロトタイピングモデル
  開発初期に試作品を作成し、フィードバックをしながら開発する手法

ファイバチャネル

コンピュータと周辺機器を高速かつロスレスで接続するデータ転送規格。伝送媒体に光ファイバを利用できる。

レプリケーション

一つのノードへのレコード挿入を他のノードでも実行する。

SAN

ハードディスク装置や磁器テープ装置などのストレージとサーバなどのコンピュータをファイバチャネルやシリアルSCSIプロトコルを用いて接続したストレージネットワークです。

IPsecのトランスポートモード

送信受信ホスト間の全経路でメッセージが暗号化。S／MINEでは送信元・送信先の端末までエンドツーエンドで暗号化が行われるため、メールサーバ内でも暗号化された状態になっている。

メモリサイクルの計算

メモリサイクル80ナノ秒の場合、1秒間のデータ転送回数は1秒÷80ナノ秒となる。

情報セキュリティ基本方針

組織のトップが社内外に取るべき行動を宣言するもの。

シンプロビジョニング

ハードディスク装置などの外部装置を仮想化することで、物理的な記憶容量より多くの容量を利用者に割り当てることを可能にする仕組み。

コンソリデーション

組織内の乱立したサーバやDB、ストレージ、アプリなどを整理統合する。

SOA

業務上の1処理に相当するドフとで実現されている機器や部品を独立したサービスとし、それらを組み合わせて連携するという手法。そのため、各システムは疎結合がありがたい。

解析ツール

• 動的テストツール：構文チェッカ、コードオーディタ
• 静的テストツール：インスペクター、トレーサー、カバレージモニター

障害発生時の取り決め

RPO

障害の発生などにより、どこまでの状態に戻すかの目標値。

RTO

目標復旧時間。

ディスクストライピング

複数のディスクに分散してデータを書き込むことで、アクセス性能を向上させる技術

ディスクミラーリング

同じデータを2台のディスクに書き込むことで、信頼性を向上させる技術。

シェアードエブリシング

複数のノード間で負荷分散を行い、障害発生時にはフェールオーバで処理を引き継ぐ。

シェアードナッシング

複数のノードに処理を分散することで処理能力の向上。

AES

128/192/256ビットから鍵の長さを選択できる。

ブローカー

分散システムを構築するために利用できるアーキテクチャパターンで、互いに依存性を持たないコンポーネント群が、リモートサービスを起動することによって相互作用するという構造を持っている。

共通鍵・秘密鍵の関係

ECCメモリ

誤り訂正符号としてハミング符号や垂直水平パリティを用いることで、記録内容に発生した誤りを検知・訂正できる機能を持つメモリです。

試験でよく問われる用語をまとめた記事も記載しておりますので下記参照ください。

「【AWS】ソリューションアーキテクトアソシエイト用語一覧」

Amazon公式のソリューションアーキテクト認定資格ページは下記です。

「AWS認定 ソリューションアーキテクト アソシエイト」

ソリューションアーキテクトアソシエイト無料問題

問題1

AWSサービスを利用する上でサービスがどこで稼働しているかによって、「AZサービス」「リージョンサービス」「グローバルサービス」に分かれます。下記で正しい組み合わせはどれか？（2つ回答）

1. EC2はグローバルサービスである
2. CroudFrontはグローバルサービスである
3. AutoScalingはリージョンサービスである
4. Route53はリージョンサービス
5. VPCはAZサービスである

問題2

ある会社は同一リージョンに属する外部ベンダーの保有するAWSアカウントのVPC内で稼働しているアプリから、データを連携し、自社のAWSアカウントが保有するVPC内のアプリに連携する必要があります。可能な限りセキュアなデータ連携を実現できるにはどのサービスが最適でしょうか？

1. IAMロールでVPC間を接続するポリシーを設定し、VPCにロールを付与する。
2. IAMグループを一つ作成し、ベンダー側と自社側でそれぞれのユーザをIAMグループに登録するクロスアカウント設定を実施。アカウント共有を行うことで、VCPを共有するように設定する。
3. VPCピアリングを利用してVPC間を接続する。
4. DirectConectをお互いの企業のVPCに接続し、VPC間を接続する。

問題3

AWSに自社用のデータベースと連携するWebアプリをリリースする予定です。その際の設定として最もセキュアなものはどれか？

1. アプリケーションサーバとデータベースサーバの両方をパブリックサブネットに設置する。NATゲートウェイをパブリックサブネットに設置し、ルートテーブルをデータベースサーバのサブネットに設定する。
2. アプリケーションサーバをパブリックサブネットに設置し、データベースサーバをプライベートサブネットに設置する。NATゲートウェイをパブリックサブネットに設置し、ルートテーブルをデータベースサーバのサブネットに設定する。
3. アプリケーションサーバをパブリックサブネットに設置し、データベースサーバをプライベートサブネットに設置する。NATゲートウェイをプライベートサブネットに設置し、ルートテーブルをデータベースサーバのサブネットに設定する。
4. アプリケーションサーバとデータベースサーバを共にプライベートサブネットに設置する。VPNを使ってプライベートサブネットにアクセスするように設定する。

問題4

AWS上でドキュメント共有アプリを構築しています。このアプリにはユーザがHTTP通信でドキュメントをS3にアップロードします。社内データの取り扱いに関してよりセキュリティ強化を行うということで、ドキュメントは保存後、どんなユーザも変更も削除もできないようにすると取り決められました。この場合、最適な対応はどれに当たるでしょうか？

1. S3バケットにボールトロックを設定する。
2. S3オブジェクトロックのガバナンスモードを設定する。
3. S3バケットからGlacierにドキュメントを移動し、ボールとロックを設定する。
4. S3オブジェクトロックのコンプライアンスモードを設定する。

問題5

企業はAWSでアプリケーションをCroudFrontを使って全世界に配信しています。1週間前よりアプリのレイテンシーが高くなっていることユーザから通知され気づくことができました。原因を特定したところ、特定のIPアドレスから異常な数のアクセスがあることがわかりました。適切な対応はどれでしょうか？

1. 原因はDDoS攻撃のため、特定のIPアドレスを遮断することが必要です。CroudFlontにACLを設定し、特定のIPを遮断するルールを付与する。
2. 原因はDDoS攻撃のため、特定のIPアドレスを遮断することが必要です。CroudFlontにWAFを設定し、特定のIPを遮断するルールを付与する。
3. 原因はMITB攻撃のため、特定のIPアドレスを遮断することが必要です。CroudFlontにACLを設定し、特定のIPを遮断するルールを付与する。
4. 原因はMITB攻撃のため、特定のIPアドレスを遮断することが必要です。CroudFlontにWAFを設定し、特定のIPを遮断するルールを付与する。

問題6

企業はAWSのEC2でアプリをホストしています。このEC2インスタンスにIP制限をかける必要があり、セキュリティグループを設定することにしました。セキュリティグループを設定した際に、現在稼働しているアプリにIP制限が適用されるタイミングとして正しいものはどれか？

1. EC2インスタンスを一度停止し、再度起動させたあとに適用される。
2. EC2インスタンスはそのままで、300秒後に設定が反映される。
3. EC2インスタンスのコンソール画面で、リフレッシュボタンを押下した後に反映される。
4. セキュリティグループの反映は設定した後瞬時に反映される。

問題7

企業はAWSに高度な計算処理を実行するアプリケーションを展開予定です。その際に最適なインスタンスファミリーを選択する必要があります。下記選択肢の中で最も最適なインスタンスはどれでしょうか？

1. 高速コンピューティングインスタンス
2. 汎用インスタンス
3. ストレージ最適化インスタンス
4. メモリ最適化インスタンス

問題8

ある企業は月末に、データベースの稼働状況のレポートを取得するアプリを使用しています。このアプリをAWSのEC2インスタンスに展開予定で、タスク終了は10分程度です。このレポート取得タスクは2〜3年必要な作業で、EC2インスタンスに他のタスクはありません。最もコストが安くなるインスタンスの契約はどれでしょうか？

1. リザーブドインスタンスを契約する。
2. オンデマンドインスタンスを契約する。
3. リザーブドインスタンスを契約し、saving planを適用する。
4. オンデマンドインスタンスを契約し、キャパシティー予約を設定する。

問題9

ある企業はWEBアプリをAWS上に展開しています。このアプリは不規則的な急激な負荷上昇がモニタリングされています。そのため、負荷に応じて段階的にスケーリングを設定することにしました。この要件を満たすAuto Scalingの設定方法はどれでしょうか？

1. 簡易スケーリング
2. スケジュールスケーリング
3. 手動スケーリング
4. ステップスケーリング

問題10

企業は２つのコンポーネント間の連携をAWS上で実現する方式を検討しています。「データ登録」をトリガーとして、複数のEC2インスタンスを利用して処理サーバーでデータ処理を並列で実行予定です。この「データ登録」は多数発生する可能性がありますが、重複で実行されてはいけません。この要件を満たすためにはどの組み合わせが正しいでしょうか？

• Amazon SNSによるプッシュ通知で、リクエストをAmazon SQSキューに送信。キュー内のリクエストメッセージをEC2インスタンスがポーリングするように設定し、データ処理を並列処理。
• Amazon SQSキューにリクエストを送信。キュー内のリクエストメッセージをLambda関数により、データ処理を並列処理。
• Amazon SNSによるプッシュ通知で、リクエストをLambda関数に送信。Lambda関数により、データ処理を並列処理。
• Amazon SNSによるプッシュ通知で、リクエストをEC2インスタンスに送信。EC2インスタンスにより処理を並列処理。

問題11

ある企業はAWSで業務アプリを展開しています。インスタンスはHTTPとHTTPSそれぞれの通信を別のインスタンスで処理するようなインスタンスのグループをALBのターゲットグループに構成しています。すべての通信をHTTPSに統一したい場合、適切な対応はどれか？

1. HTTP通信をHTTPS通信に変換するALBのリスナールールを設定する。
2. HTTP通信をHTTPS通信にリダイレクトするALBのリスナールールを設定する。
3. HTTPS通信のみを許可するように、ALBのネットワークACLを設定する。
4. セキュリティグループをインスタンスに設定し、HTTP通信を遮断する。

問題12

ある企業はAWSを利用し、ファイルストレージを構築予定です。現在企業が利用しているファイルストレージサービスは、オンプレ環境のSMBプロトコルでデータ転送を行うファイルサーバです。最も構築コストが低く簡易に利用できるAWSストレージはどれか？

1. Amazon EBS
2. Amazon EFS
3. Amazon S3
4. Amazon FSx

問題13

ある企業は複数のインスタンスを起動し、インスタンス間で通信が発生するアプリを展開しています。アプリは低レイテンシーと高スループットを実現する必要があります。下記選択肢の対応としてはどれが最も適した対応でしょうか？

1. 複数のAZにまたがるAuto Scalingグループでインスタンスを起動する。
2. クラスタープレイスメントグループでEC2インスタンスを起動する。
3. パーティションプレイスメントグループでEC2インスタンスを起動する。
4. スプレッドプレイスメントグループでEC2インスタンスを起動する。

問題14

ある企業はAWSのVPC内で複数のインスタンスを稼働させ、アプリを展開している。VPCにはネットワークインターフェイスがアタッチされており、インスタンスへリクエストが到達する構成です。企業はインスタンスにアクセスするIPトラフィック情報を管理したいと考えています。
管理面を考慮し、最も適した構成を作成するにはどうすればいいか？（2つ選択してください。）

1. AWS CloudTrailを利用し、ログ取得を有効化する。
2. ネットワークインターフェースに対してVPCフローログを有効化する。
3. ネットワークインターフェイスの手前にNLBを設置し、NLBのログを有効化する。
4. インスタンスにCloudWatchをインストールする。
5. AWS Logsを対象のインスタンスに対して有効化する。

問題15

企業はAWSにアプリを構築しています。インスタンスに障害が発生した場合、別の待機インスタンスに処理を継続させる構成になっています。アプリ運用開始してしばらく経過後、インスタンス障害により、トラフィックが自動で別インスタンスに切り替えられました。しかし、アプリ処理は継続されず停止しました。IPアドレスが変更され、アプリの処理継続ができなくなったことが原因のようです。解決策はどれか？

1. Route53のルーティングレコードを書き換え、ホスト名を待機系のIPアドレスに向け直す。
2. IPフローティングで、待機系インスタンスにIPアドレスの付け替えを実施する。
3. NLBによってインスタンスのトラフィックを待機系インスタンスに向ける。
4. AutoScalingによってインスタンスのスケーリングを実施する。

問題16

企業はオンプレで稼働しているアプリをAWSに移行予定です。アプリはストレージにアップロードされたファイルを初めの1週間は低頻繁で読み込みます。低頻度ですが、アプリの使用上、データ取り出しは60秒以内に行えることが望ましいです。1週間をすぎると、アプリからの読み取りは無くなりますが、稀に監査や調査によりファイルを取り出す必要があります。この監査や調査は不定期ですが、実施の際はデータの取り出しは数分で可能なことが望ましいです。この企業はAWSに移行する点で可用性よりもコスト面を重視しております。最適な構成はどれか？（2つ選択）

1. 最初の1週間はS3ストレージのStandardクラスを採用する。
2. 最初の1週間はS3ストレージのStandard-IAクラスを採用する。
3. 最初の1週間はS3ストレージのOne Zone-IAクラスを採用する。
4. ライフサイクルルールにより1週間後にGlacier Deep Archiveにデータを移行する設定をする。
5. ライフサイクルルールにより1週間後にGlacier Flexible Retrieval（迅速取り出しモード）にデータを移行する設定をする。
6. ライフサイクルルールにより1週間後にGlacier Instant Retrievalにデータを移行する設定をする。

問題17

AWS上で稼働する配送管理アプリの伝票データを出力するアプリがあります。伝票は出荷後もしばらくの間保存しておく必要があります。伝票自体はS3ストレージに保存され、誰でもアクセス可能です。事務処理が全て完了した伝票に関しては削除しても問題ないですが、未完了の伝票は削除されてはいけません。この場合、S3にどの対応をすることが最も簡易的でしょうか？

1. S3バケットにボールトロックを設定する。
2. S3バケットのスナップショットを定期的に自動取得する。
3. S3バケットのバージョニング機能を有効化する。
4. S3にデータを蓄積し、別リージョンにもS3を作成する。その後CORSを設定する。

問題18

企業はAWSで業務用Webアプリを稼働させる予定です。このアプリは専用端末からEC2インスタンスに画像をアップロードし、APIを利用してS3バケットに保存する仕様予定となっております。セキュリティ要件上セキュアな構成が求められております。どの選択肢が最も適切でしょうか？

1. AWS VPNを利用して端末からEC2へ画像をアップロード。その後、S3エンドポイント経由でS3にファイルを転送する。
2. AWS VPNを利用して端末からEC2へ画像をアップロード。その後、APIゲートウェイ経由でS3にファイルを転送する。
3. AWS Direct Connectを利用して端末からEC2へ画像をアップロード。その後、S3エンドポイント経由でS3にファイルを転送する。
4. AWS Direct Connectを利用して端末からEC2へ画像をアップロード。その後、APIゲートウェイ経由でS3にファイルを転送する。

問題19

企業では複数のインスタンスに対してWEBアプリを展開しています。1つのインスタンスから別リージョンのS3バケットのオブジェクトにアクセスするために、VPCエンドポイントを使用する予定です。この仕様でコンテンツをシェアする場合の適切な構成はどれか？

1. S3のCORSを設定し、対象リージョンにS3バケットを共有する。
2. S3のCRRを設定し、対象リージョンにS3バケットをレプリケーションする。
3. S3 transfer accelerationを有効化し、対象リージョンにS3バケットを共有する。
4. 異なるリージョン間の対象となるVPCとVPCピアリングを設定し、対象リージョンにS3バケットを共有する。

問題20

企業はS3バケットに大量のデータを格納しています。S3バケットのデータ量増加に伴い、データを検索するソリューションを模索しています。データ検索は、簡易的に実行でき、なおかつ効率的なソリューションで、オブジェクト全体ではなく、オブジェクトデータのサブセットを取得したいと考えています。どのソリューションが最も適切でしょうか？

1. S3 Select
2. Amazon Redshift Spectrum
3. CloudSearch
4. Amazon Athena

問題21

企業はS3バケット重要機密データを保存しております。S3バケットのデータは暗号化されている必要があります。必要な対応として適切な対応はどれか？（2つ選択）

1. Cloud HSMを利用してデータを暗号化する。
2. S3バケットのデフォルト暗号化設定でデータを暗号化する。
3. AWS KSMを利用してデータを暗号化する。
4. SSL認証を利用してデータを暗号化する。
5. VPCの暗号化設定を有効化し、データを暗号化する。

問題22

企業はAWSのS3バケットを利用してデータを保存しています。アメリカにある全く別の企業とS3バケットを利用してデータを共有予定です。この際、構成として最も適切な構成はどれか？

1. S3バケットにアクセス許可を設定するバケットポリシーを設定する。
2. S3バケットにCORSを設定する。
3. S3バケットにクロスアカウントアクセスを設定し、リクエスタ支払い機能を有効化する。
4. S3バケットのCRRを有効化して、ヨーロッパ企業のS3バケットとレプリケーションする。

問題23

企業はオンプレ環境に静的Webサイトを運用しています。このサイトをAWSに移行すると決まり、構成を考えています。このサイトは全世界にユーザが存在しており、サイトを遅延なく表示させる必要があります。適切な構成はどれか？（2つ選択）

1. 静的サイトをS3から配信するよう、静的ウェブホスティングをS3バケットに構成する。
2. ユーザからリクエストがあると、EC2に作成した RestAPIを経由して静的サイトを返すアプリを構成する。
3. S3バケットを複数リージョンにレプリケートし、各リージョンにて配信設定をする。
4. Amazon CloudFrontを構成し、S3バケットをオリジンとして設定する。
5. Route53を利用して、各リージョンに遅延ルーティングするように構成する

問題24

企業はAWSでアプリを展開しています。このアプリ内ではEC2とELBで構成されています。ELBに証明書を設定し、通信をHTTPSに設定しています。証明書は有効期限があり、14日前に運用チームにメールが来るような構成を取ることを決めました。どの構成が正しいでしょうか？

1. ACM証明書の有効期限をチェックするAWS Configルールを作成し、14日後に期限が切れる証明書がある場合、Amazon CloudWatchアラートにメッセージを送信する。
2. ACM証明書の有効期限をチェックするAmazon EventBridgeルールを作成し、14日後に期限が切れる証明書がある場合、Amazon SNSメッセージを送信する。
3. ACM証明書の有効期限をチェックするAmazon EventBridgeルールを作成し、AWS Lambda関数を呼び出すように設定する。その後、LambdaからAmazon SNSにメッセージを送信する。
4. ACM証明書の有効期限をチェックするAWS Configルールを作成し、14日後に期限が切れる証明書がある場合、AWS Lambda関数を呼び出すように設定する。その後、LambdaからCloudWatchアラートにメッセージを送信する。

問題25

企業は、AWSとオンプレ環境を専用回線で接続しており、双方のリソースを共有し処理を実行可能です。そこで、双方の環境を利用して処理を実行する処理フローやデータ連携方法を構成する必要があります。最適な構成はどれか？（2つ選択せよ）

1. Amazon SQSを利用し、オンプレサーバとEC2をポーリングするキュー処理を構成する。
2. API Gatewayを利用し、APIリクエストをオンプレとAWSへ振り分けるよう構成する。
3. AWS SWFを利用し、オンプレサーバとEC2を利用したワークフローを作成する。
4. AWS Step Functionsを利用し、オンプレサーバとEC2を利用したワークフローを作成する。

問題26

企業は、サーバレスアプリを展開しています。API Gateway経由でAWS Lambda関数を呼び出す構成となっており、Lambda関数ではデータをAurora MySQLに保存する処理を実施しております。Aurora MySQLのアップグレード時を実施する必要があります。アップグレード処理が完了するまでLambda関数はDBに接続できなくなりその時間のデータ保存ができません。このデータを一時的に保存するにはどのような構成が最適か？

1. Amazon RDSプロキシを設定し、RDSプロキシをデータ登録時に使用するようにLambdaを実装する。
2. Lambdaのローカルストレージにデータを保持し、アップグレード後にローカルストレージをスキャンし、データをAuroraに保存。
3. Lambdaの実行時間を上限まで増やす。その上で、このLambda関数でデータベースへの接続に失敗した場合の再試行処理を実装する。
4. Lambdaが取得したデータをAmazon SQSキューに保存。別のLambda関数によって、キューをスキャンし、データをAuroraに保存する。

今回の記事は以上です。他にもAWS関連やその他技術系の記事を記載しています。興味ある方はサイト内見て行ってください。

頻出SQL文まとめ

SQL文に関しては午前・午後両方で問われます。午前試験では基本的にはSQLを実行した後の結果やSQLの機能や関数の意味などが問われることが多いです。ただ、かなり回数は少ないですが、SQLを空欄に当てはめるなども出題されていた（過去15年分しか確認していませんが。。）ので是非押さえておきましょう。

下記の流れで紹介していきます。

• SQL関連用語
• 頻出SQL文

SQL関連用語

ストアドプロシージャ(Stored Procedure)

一連の処理手順をプログラムとしてまとめて実行できる処理モジュールをDBMS上に用意したもの。

VARCHAR・CHAR

CHAR(10)は常に10バイトでそれ以下のバイトの場合はバイト数がその数に減る。そのバイト数は固定。VARCHARは可変長。補足：日本語は2バイト。

直積

直積はデータ操作で、2つの関係(表)に含まれる要素のすべての組合せから成る表のことです。

べき等

複数回同一操作をしても、一回しか実行しなくても結果が同じになる（selectなど）

レプリケーション

一つのノードへのレコード挿入を他のノードでも実行する

頻出SQL

SQLの組み立てはCRUD操作のSQL（select,insert,update,delete）の後ろでテーブルを指定（from句）し、条件句（where句）で操作対象のデータを絞るという構成です。

（例）
select id from テーブル1 where id = 1;

頻出SQLを順番にご紹介していきます。

CREATE文

テーブルを作成。

create table テーブル名 (id int, name varchar(10));

SELECT文

データを取得。

select * from テーブル名;

INSERT文

データを追加。

insert into テーブル名;

UPDATE文

データを更新。

update テーブル名 set {更新するカラム} = {更新データ};

DELETE文

データを削除。

delete テーブル名;

where句

where {検索対象のカラム} = {検索条件}

order by句

order by {並び順を指定するカラム}

GROUP BY句

ほぼ確実に出題されている気がします。SQLノータッチの方は答えづらいので、少しでも勉強している方はかなり簡単に回答できます。基本的にgroupごとに結果をまとめて取得するものです。

（データ例）
テーブル名：Sample
class  point
a    |  10
a    |  20
b    |  30
a    |  30
b    |  30

select class,avg(point) from sample group by class;
------
a 20
b 30
------

ちなみにgroup byしたデータを絞る場合はwhereでなく、「having」を使う。これも良く出る。

（データ例）
テーブル名：Sample
class  point
a    |  10
a    |  20
b    |  30
a    |  30
b    |  30

select class,avg(point) from sample group by class having point > 20;
------
b 30
------

最後に、group byを実行するとselect分で出力できる項目にはgroup by でグルーピングした項目と計算系（sumやavg、countなど）のみです。このルールで午前午後かなりの問題が解けます。

（データ例）
テーブル名：Sample
class  point teacher
a    |  10  |  tanaka
a    |  20  |  tanaka
b    |  30  |  sato
a    |  30  |  tanaka
b    |  30  |  sato

select class,avg(point),teacher from sample group by class,teacher having point > 20;
------
b 30 sato
------

上記のように先生を結果に出力したい場合は、group by句にそのカラムも追加する必要があります。

group by長くなりましたがかなり重要。

計算系SQL

先ほどのgroup by句でも説明に使いましたがこちらもほぼ頻出です。

select count(*) from ... -- データの個数
select max(項目) from ... -- 点数などの項目の一番上のデータを取得
select sum(*) from ... -- 点数などの項目合計を取得
select avg(*) from ... -- 点数などの項目の平均点を取得

in句

こちらもほぼ頻出。条件の中にデータが含まれているかの条件句です。

select count(*) from テーブル where 点数 in (0,1,2,3) -- 0,1,2,3の中に含まれている点数のデータが抽出される

exists句

こちらもほぼ頻出。条件の中にデータが存在しているかの条件句です。

select count(*) from テーブル where exists 点数 < 30 -- 30以下の点数のデータ抽出される

副問い合わせ（サブクエリ）

こちらも必ず出ます。かっこで囲ってSELECT文の結果を使います。みた方が早いです。

-- 通常のselect文
select id, name from テーブル where id in (0,1,2) ;
-- サブクエリを含むselect文（上記とやっていることは同じだがin句の中身をselect文で取得している）
select id, name from テーブル where id in (select id from テーブル where id < 3); 

-- 通常のinsert文
insert into テーブル (id, name) values (1, 'aaa');
-- サブクエリを使用したinsert
insert into テーブル (id, name) values (select id, name from 取得元テーブル where id < 100);

join句

こちらも必ず出題されます。テーブルを結合します。結合条件が違うという差があります。

• inner join：内部結合
• left join：外部結合

select id from テーブル1 inner join テーブル2 on テーブル1.cd = テーブル2.cd;

select id from テーブル1 left join テーブル2 on テーブル1.cd = テーブル2.cd;

ここまでがかなり良く問われる頻出SQLです。

頻出ではないがよく聞かれるSQL

カラム定義

create文が出ることまあまああり、この辺りのカラム定義で制約をつけるSQLは知っておく方が良いです。主キー、一意制約、外部キー、not Null、デフォルト値セット、参照、自動採番をカラムに設定するCREATE文です。

CREATE TABLE SAMPLETABLE
(
  no int auto_increment
  id int PRIMARY KEY,
  name varchar(50) UNIQUE NOT NULL,
  tel varchar(12) default '000-0000-0000'
  FOREIGN KEY(refNo) REFERENCES anotherTable(refNo)
);

between句

こちらもほぼ頻出。条件の間にデータが存在しているかの条件句です。

select count(*) from テーブル where between 点数 40 and 50 -- 40点以上50点以下の点数のデータ

GRANT

稀に聞かれます。GRANT文は、特定のユーザに表などのデータベースオブジェクトに対する権限を付与するSQL文です。

GRANT {権限3,権限2} ON テーブル TO ユーザ;
GRANT SELECT, UPDATE ON table1 TO user1;

REVOKEで権限削除。使用方法はGRANTの部分を置き換えるのみです。

念の為押さえておくべきSQL

CREATE ASSERTION

こちらは午前の用語で出ていたような気がします。CREATE ASSERTION文は、スキーマ内の複数のテーブルに対して制約を適用するSQL文です。テーブルAの合計がテーブルB・Cの合計になるという制約をつけるSQL。

CREATE ASSERTION totalCount
CHECK (SELECT COUNT(*) FROM TableA) = (SELECT COUNT(*) FROM TableB) + (SELECT COUNT(*) FROM TableB);

CASCADE

こちらは午前の用語で出ていたような気がします。参照データの同時削除を行う。

ALTER TABLE

出ているのをみたことはないですが、念の為。カラムの追加・更新・削除などで使用。

-- 単一カラム追加
ALTER TABLE sample ADD COLUMN addCol VARCHAR(8);
-- 複数の場合
ALTER TABLE sample ADD (addCol1 VARCHAR(8),addCol2 VARCHAR(8));

-- カラムの定義変更（複数は上記と同じ要領）
ALTER TABLE sample MODIFY COLUMN addCol VARCHAR(8);

-- カラム削除（複数は上記と同じ要領）
ALTER TABLE sample DROP COLUMN address;

以上で今回の記事は終了です。他にも応用情報関連の記事を記載しているので是非参考にしてみてください。

ソリューションアーキテクトアソシエイト出題範囲

ソリューションアーキテクトアソシエイトの出題範囲は下記です。

• セキュアなアーキテクチャの設計 30%
• 弾力性に優れたアーキテクチャの設計 26%
• 高パフォーマンスなアーキテクチャの設計 24%
• コストを最適化したアーキテクチャの設計 20%

クラウドプラクティショナーと違い、サービスを利用して顧客要望を満たす設計ができるかという観点の問題が出題されます。

そのため、各サービスに感してはクラウドプラクティショナーの用語と変わりません。それは別記事でまとめていますので、サービスの機能を抑えられているか不安な方はこちらの記事を参照ください。

【AWS】クラウドプラクティショナー用語まとめ。
【AWS】クラウドプラクティショナー無料試験問題。

クラウドプラクティショナーの知識を前提にソリューションアーキテクトで問われるポイントを今回はまとめたので順番に紹介していきます。

ソリューションアーキテクトアソシエイト資格用語まとめ

AWSサービスについて

AWSサービスには3種類あります。

• アベイラビリティゾーンサービス：EC2/RDS/サブネットなど
• リージョンサービス：VPC/AutoScaling/DynamoDBなど
• グローバルサービス：Route53/Cloud Front/S3(データはリージョンに保存)など

AWS Well-Architected フレームワーク

AWS Well-Architected フレームワークは、以下の６つの柱で構成されています。

・運用上の優秀性
・セキュリティ
・信頼性
・パフォーマンス効率
・コスト最適化
・持続可能性

可用性などは含まれない。

AZ

AZはデータセンターの集まり。リージョン内で物理的に区分され独立しています。AZは物理的に分離されているため、火災、竜巻、洪水などの極端な災害は単一AZのみに影響する。

エッジロケーション

低レイテンシーを達成するためのキャッシュコンテンツを配信するための地理的ロケーションのこと。ファイル圧縮処理などが可能。

VPC

VPCピアリング

VPCピアリングは、異なるVPCからインターネットを経由せずに同じネットワークにいるように通信ができるサービス。

VPCのAZ配置について

VPCは複数のAZに配置可能。

ACLについて

サブネット間の制御として使われます。ネットワークACLはインバウンド（中に入ってくる）設定とアウトバウンド（外に出ていく）の両方を設定する必要がある。

デフォルトの設定

インバウンド　：すべて許可
アウトバウンド：すべて許可

SSH接続をする場合、ポートは22、インバウンドのため「Egress：false」に設定されている必要があります。特定のIPのみの場合は、サブネットは「/32」にする。アウトバウンドを広範囲のPCに設定する場合は、ポート「1024~65535」に設定する。HTTPをセキュリティグループで許可は80番ポートで「0.0.0.0/0」。

ネットワークACLルールの評価方法は、低い値から高い値に順番に評価され、低い値が優先される。

セキュリティグループについて

EC2インスタンスなどに適用するファイアウォール機能で、主にVPCリソースのトラフィックを制御するのに使われます。セキュリティグループにはCIDRを指定してIPアドレス範囲を設定するか、別のセキュリティグループIDも設定可能です。

デフォルトの設定

インバウンド　：すべて拒否
アウトバウンド：すべて許可

使い方としては、DBなどに接続できるIPアドレスやEC2インスタンスを個別に指定するために使用できる。プロトコル(TCPやUDP)、ポート番号なども指定可。セキュリティグループの設定は即座に反映。

VPCの上限

1リージョンあたり5VPC。申請フォームによりAWSに申請すれば100まで上げることが可能。

セキュリティグループとネットワークACLの違い

セキュリティグループはインスタンス単位で設定するファイアウォールで、ネットワークACLはサブネット単位で設定するファイアウォールです。それぞれ、アウトバウンド（外に出る）とインバウンド（中に入ってくる）のルールを設定して利用します。

セキュリティグループはステートフル（ルールで許可された通信の戻りの通信も自動的に許可）、ネットワークACLはステートレス（アウトバウンド/インバウンドそれぞれで、ルール設定が必要）。

NATゲートウェイ

VPC内プライベートサブネットにあるEC2インスタンスからセキュアなインターネットへのアクセスが必要。その場合は、このNATゲートウェイを使用することで実現できる。プライベートサブネットのルートテーブルを更新して、インターネットトラフィックをNATゲートウェイに向ける必要あり。

トラフィックミラーリング

ミラー対象に指定したENI（Elastic Network Interface）を通るトラフィックの中身をミラーリング。ミラーリングしたパケットを、別のENIやNLB、GWLBに対して転送することができるので、パケットをモニタリングすることが可能。

Elastic Network Interface（ENI）

仮想ネットワーク。ENIはインスタンスにアタッチされているため、デタッチして別のインスタンスに付け替え可能。使い方としては、実行中のインスタンスへのアタッチ（ホットアタッチ）、停止中のインスタンスへのアタッチ（ウォームアタッチ）や起動中のインスタンスへのアタッチ（コールドアタッチ）などとしてフェールオーバ時に使用できます。

AWS Network Firewall

VPC内に配置するファイアウォール。インターネットやVPC間との通信を検査及び制御できる。

DNS hostnamesオプション

パブリックサブネットでEC2インスタンスを起動した際にインスタンスがDNS名を受け取らない場合、DNS hostnamesオプションを有効化します。

AWS WAF

Webファイアウォールは条件に基づきWebリクエストを許可・ブロック・監視するルールを設定し、Webアプリを攻撃から保護するのを助けるWebアプリファイアウォールです。

下記などがブロック例

• リクエストの IP アドレスの送信元
• リクエストの送信元の国
• リクエストの一部に含まれる文字列一致または正規表現 (regex) 一致
• リクエストの特定の部分のサイズ
• 悪意のある SQL コードまたはスクリプトの検出

CloudFrontに使用する場合は、Referer制限をすることで、拒否ルールや許可ルールを設定可能。

EC2

アンマネージドサービス。停止から起動までの時間は数分。

セキュリティグループ変更の適用

変更の適用や新規設定は全EC2インスタンスに即座に反映。

インスタンスの種類

• 汎用：A1・M5・T3
  バランスが取れたインスタンス。クラスタープレイスメントグループによる設定可能。
• コンピュータ最適化：C5・C6g
  高パフォーマンスが必要なアプリ用
• メモリ最適化：X1・R5
  メモリ内の大きいデータセットを処理するのに最適
• 高速コンピューティング：P3・G4
  高い計算能力
• ストレージ最適化：ix/dx/hx
  ローカルストレージの大規模データセットに対する高い読み取り能力

インスタンスの契約関連

• オンデマンド
  時間課金制
• リザーブド
  1〜3年間などの年単位での契約を行う場合に利用。1時間程度などの利用はできない。一度契約するとインスタンスタイプやOSを切り替えることはできない。毎日ずっと利用するサーバー向けでなければ、逆に費用が高くなってしまいます。
• スポット
  途切れてもいい場合に利用。安い。

オンデマンドキャパシティー予約

特定AZで任意時間インスタンスのキャパシティ予約可能。その間、対象インスタンスの起動が保証。

コンバーティブル

インスタンスの予約期間中にインスタンスファミリー・OS・テナンシー・支払オプションの変更可能。

ステップスケーリングポリシー

スケーリングをCPU使用率などに応じて、複数の閾値を設定。段階的にインスタンス数を増加可能。

スポットフリート

インスタンスタイプや入札価格を指定し、自動で最安値のインスタンスを選択してスポットインスタンス数を調節して、リクエストを処理します。負荷に応じた増減が適切にできます。

EC2フリート

オンデマンド・リザーブド・スポットインスタンスで構成されるインスタンスグループを作れる。それらの購入オプションを共有し、複数のAZにまたがり複数インスタンスタイプを起動可能。

EC2のバッチ処理分散

重い処理をバッチ処理として複数のEC2インスタンスに分散させる場合、Amazon SQSを使用する。

Load Balancer

LBは1つのリージョン内において複数のアベイラビリティゾーンにトラフィックを分散します。リージョン間はできません。

• Amazon ELB（Elastic Load Balancer）
  EC2に対して、Webトラフィックなどの負荷分散。
• Amazon ALB（Application Load Balancer）
  アプリケーション層のロードバランシングに特化。
• Amazon NLB（Network Load Balancer）
  レイヤー4（トランスポート層）で動作し、TCP/UDP/TLSのトラフィック分散に向いている

ELBでDBの利用率を下げるなどは無理。あくまでもEC2のみ。

ALBによるHTTPからHTTPSリダイレクト

ALBのリスナールールを使用して、HTTPリクエストをHTTPSにリダイレクトする設定をする。

ELBのConnection Draining

インスタンスをELB(CLB)から登録解除すると、処理中のリクエストが途絶え、アプリでエラーになる。Connection Drainingを利用すると処理中のリクエストが終わるまで一定期間待機するように設定できる。

ELBを利用せずに高可用性とフォールトトレランスを担保

インスタンスに仮想のElastic IPアドレスを付与し、EC2インスタンス自身の状態をチェックするカスタムスクリプトを使用します。インスタンス応答が停止している場合、スクリプトは、Elastic IPアドレスをスタンバイ側のEC2インスタンスに切り替えるなどで実現可能。

NLBでのフェイルオーバー

UDP接続を使用するVoIPサービスに対応するためには、ネットワークロードバランサ(NLB)が適切。NLBをAWS Global Acceleratorのエンドポイントとして使用することで、遅延が最も短いリージョンにユーザーをルーティングし、リージョン間の自動フェイルオーバーを実現可能です。

EC2の付与できるタグ条件

EC2インスタンスに付与できるタグの上限は50。キーの最大長はUnicode文字128文字。値の最大長は Unicode文字で256文字です。タグでは、大文字と小文字が区別されます。

このタグで開発用・本番用インスタンスを区別し、IAMのポリシーを利用して、開発者の利用範囲を区切ることも可能です。

EC2にアタッチできるストレージ

Amazon EBS(Elastic Block Store)とAmazon EFS(Amazon Elastic File System)。

EBSボリュームがインスタンスのルートデバイスである場合、ボリュームをデタッチする前に、インスタンスを停止する必要がある。

プレイスメントグループ

プレイスメントグループは、複数のインスタンスを論理的にグループ化して、パフォーマンスの向上・耐障害性を高める機能。

• クラスタープレイスメントグループ　単一AZ内でネットワーク性能の引き上げを行う
• パーティションプレイスメントグループ　同一リージョン内でハードウェア障害対策
• スプレッドプレイスメントグループ　同一リージョン内でハードウェア障害対策

DeleteOnTermination 属性

Amazon EC2のインスタンスを終了する際、インスタンスに接続されていたEBS ボリュームを存続させるかを設定する値。デフォルトでは、インスタンスのルートボリュームのDeleteOnTermination属性は有効化されているため、インスタンス削除時にEBSボリュームも削除される。ルートボリューム以外の追加したボリュームタイプではDeleteOnTermination属性は非有効化されている。

IPフローティング

EC2インスタンスにELBやRoute53を構成していると、障害発生時には稼動系からElastic IPアドレスを外し、待機系インスタンスに割り当て直すことで瞬時にトラフィックの向け先を変更できます。ホスト名を待機系IPアドレスに向け直すと、DNS情報が伝播するまでに一定のダウンタイムが発生する可能性があります。これを防止するため、IPフローティングを利用してElastic IPアドレスをフローティングすることで即時に別のEC2インスタンスへとトラフィックを切り替えることができます。

VPCフローログ

インスタンスのネットワークインターフェースに対するVPCフローログを有効化することで、EC2インスタンスのネットワークインターフェイスを介して行き来するIPトラフィック情報をキャプチャ可能。

AMI

EC2インスタンスを起動するための必要情報がまとめられたテンプレートのようなもの。AMIは、仮想マシンのイメージであり、オペレーティングシステム（OS）やアプリケーションソフトウェア、起動許可などがパッケージ化されている。AMIを使用することで、同じ設定やソフトウェアが含まれた複数のインスタンスを簡単に作成できます。また、バックアップなどにも使用できる。

AMIイメージを別アカウントに共有

複数のアカウント間でAMIを共有するには、AMIを別のアカウントと共有するための許可設定が必要。そのためにAMIのLaunchPermissionプロパティを変更する必要がある。
また、AMIはAMS KMSで作成されたキーで暗号化されているため、第三者のアカウントでAMIを利用するためには、KMSのキーポリシーを変更する必要があります。

AutoScaling

リソースが逼迫している場合自動でスケールアウト（リソースを増やす）、余剰な場合はスケールイン（リソースを減らす）を行うサービス。
起動テンプレートを利用してスケーリングを行います。

スケールの種類

• ターゲットトラッキングポリシー
  CPU平均使用率や平均ネット入力などの閾値を指定し、それを維持できる台数にインスタンスをスケール。
• 簡易スケーリングポリシー
  動的スケーリングオプションの１つ。上限と下限の閾値を設定し、その閾値を超過した場合、スケーリングを実施。基本的にステップスケーリングポリシーの方が使われる。
• ステップスケーリングポリシー
  動的スケーリングオプションの１つです。上限と下限の閾値を複数設定し、その閾値に基づいて複数回にわたって段階的にスケーリング可能。細かく定義することができる。
• スケジューリングポリシー
  時間によりスケーリング。

複数AZでのインスタンススケールアップ

複数AZを指定したAutoScalingグループを作成。それをELBターゲットグループに設定。複数AZにEC2インスタンスをスケーリングできる。ELBによって既存AZのインスタンスに異常があれば、ヘルスチェックで確認され、その後AutoScalingが停止したAZにあったEC2インスタンスの代わりに別AZにEC2インスタンスを起動できる。

EC2インスタンスのスケールイン

スケールアウトしたインスタンスをスケールインする場合、デフォルトでは下記の順で実行される。

1. インスタンス数が最も多いAZを選択する。
2. AZのインスタンス数が同じ場合は、起動設定が古いインスタンスがあるAZを選択する。
3. 起動設定が古いインスタンスが複数ある場合は、次の課金発生までの時間が最も短いインスタンスを選択する
4. 次の課金発生までの時間が同じインスタンスが複数ある場合はランダムで選択する

インスタンスのスケールアウト

複数のAZを跨いでスケールアウトすることができる。また、スケールアウトするEC2インスタンスの上限数を設定することができる。

スケーリングクールダウン

スケーリングクールダウンは、Auto Scalingが連続で実行されないようにするための新しいインスタンスが開始されるまでの待機時間。デフォルトでは300秒。
クールダウンをうまく設定できていない場合、CPU使用率が下がる前に次のインスタンス起動が始り、想定より多いインスタンスが起動してしまうことがある。スケーリングポリシーでスケーリング固有のクールダウンかAutoScalingグループ全体へ適用ができる。

ヘルスチェック

Auto Scalingは起動したインスタンスに対して定期的なヘルスチェックを実行し、インスタンスの状態を監視しています。このへルスチェックにはEC2タイプとELBタイプの2タイプがあります。

• EC2タイプ
  EC2のステータスがrunning以外の場合、またはシステムステータスがimpairedの場合に、このインスタンスを異常と判断
• ELBタイプ
  インスタンスのステータスチェック、ELBのヘルスチェックからインスタンスの状態を判断

AutoScalingの範囲

AutoScalingは別リージョンでは使用できない。

AutoScalingの対応限界時間

AutoScalingを設定しているEC2でミリ秒遅延には対応できない。

IPアドレス

インスタンス削減時に古い既存インスタンスが削除されると、IPアドレスが変更される可能性がある。

トリガーの制限

メモリ利用率をトリガーとした設定がデフォルトでは設定できない。CPU利用率に応じたスケーリングが適切。

Desired capacity

希望する容量はAuto Scalingによって現在起動するべきインスタンス数を規定するAuto Scalingグループ内の現在起動するべきインスタンス数の設定。これに従ってインスタンスが増減する。

Amazon ECSクラスターにスケーリングを設定

Auto Scaling構成としては、スケーリングポリシーを設定したAuto ScalingはECSクラスターにアタッチすることが必要です。その上で、ECSクラスターにALBをアタッチします。

インスタンスのウォームアップ

新規インスタンスのAuto Scalingのヘルスチェックが成功してInServiceになってから、Auto Scaling グループのメトリクス収集の対象になるまでの期間。

DB系のスケールアップ

性能に関してスケールアップはできないが、データベースのストレージに対して、スケールは可能。

S3

バケット形式のストレージ。デフォルトで保存データを暗号化。

ストレージクラス

コストはS3よりもGlacierの方が安い。Glacier Deep Archive<Flexible Retrieval<Instant Retrieval<One Zone-IA<Standard-IA<Standardの順。

• Glacier Instant Retrieval
  ミリ秒単位のアクセスが可能 アクセスはほとんどなし 他のGlacierよりも高い
• Glacier Flexible Retrieval
  通常データ検索で3～5時間、迅速取り出しモードで2～5分
• Glacier Deep Archive
  標準の取り出しで9時間以上〜12時間以内。7～10年以上保存が必要だがほぼ取り出しなしのデータ向け
• Standard-IA
  低頻度アクセス用ですが、読み込みはすぐ。アクセスが頻繁ではないデータ向け。
• Standard
• One Zone-IA
  アクセスが頻繁ではないデータを単一AZに保存することによってコストを節約。読み込みはすぐ。
  ログファイルのコピーを保存する典型例。即時にデータ取得可能。ただし、データ取得されないことを前提としているため、データ取得時には課金が発生する。

ボールトロック

Glacierのいづれかのストレージクラスにデータを保存した際に、ボールトへのアクセス制御をポリシーとして設定し、編集できないようできる。

S3のバージョニング機能

ファイルを前のバージョンから復旧することが可能。S3は自動で複数のリージョンに保持され、クロスリージョンレプリケーションを備えており、高い可用性と耐久性を備えている。

S3のデータ自動保存

S3は保存されたデータは、複数のAZに保存される。

S3のライフサイクルポリシー

データを◯ヶ月間保管し、その後Glacierに移動や削除などを設定できる。

S3のCRR

CRRはCross-Region Replicationの略です。S3バケット間でオブジェクトを自動的に複製（レプリケーション）するための機能を提供します。東京リージョンのバケットのデータをオレゴンリージョンにコピーしたりなどです。追加費用は発生する。

S3のCORS

CORSはCross-Origin Resource Sharingの略です。ブラウザが異なるオリジン（ドメイン）のリソースにアクセスするためのスクリプトを許可します。例えば、東京リージョン内のサイトがオレゴンリージョンのS3バケットにアクセスして、画像をダウンロードするなどです。

S3のエンドポイント接続

S3にアクセスする際にS3をインターネットからは非公開として、EC2経由でエンドポイントを通してS3のデータに接続することで、EC2はインターネットを介さずにS3データを取得できる。

S3の容量

S3に保存できるデータの容量に上限はありません。S3コンソール画面からのアップロードする上限容量はあるが、AWS CLIなどを使うことで、その上限もなくなる。

S3のマウント

同時に複数のS3をマウントすることはできない

データの一貫性

新規データ追加後に更新を行うなど、読み取り後書き込みで一貫性を常に保障している。データ更新されても、すぐに反映されます。

Application Load Balancerのアクセスログ

ALBのアクセスログをS3に保存することができる。

S3 Transfer Acceleration

海外リージョンなど、送信元から遠く離れたS3へのデータ転送をAWSのエッジロケーションとネットワークプロトコルの最適で高速化するサービスです。世界中からアップロードが行われたり、大陸間で定期的にGBからTBなどの大きなデータを転送する場合に使用します。

ゲートウェイエンドポイントとの接続

VPCのルーティングテーブルを書き換えて、ゲートウェイ経由でサービスにアクセスできるので、インターネットを経由せずに操作ができる。

S3バケットの更新・削除をできないようにする方法

S3バケットにMFA Delete機能を適用。ユーザーによるデータ削除時にMFA入力を必須化して、誤った削除を防止する。または、Amazon S3バケットの初期設定でデータが削除されないようにオブジェクトロックを設定。（このロックは初期設定でのみ設定可能。オブジェクトロック設定は変更できない）

他にもIAMポリシーで削除権限を拒否するなどもある。

AWS PrivateLink for Amazon S3

S3はインターフェースエンドポイントに2021年対応しエンドポイント経由でVPCからS3バケットインターネットを経由せずにアクセス可能。

Amazon S3 Select

シンプルなSQLステートメントを使用してAmazon S3オブジェクトのコンテンツをフィルタリングし、必要なデータのサブセットのみを取得可能。Amazon S3が転送するデータ量を削減でき、データ取得に要するコストや待ち時間を改善できる。

オブジェクトロックの種類

• ガバナンスモード
  バケット内のデータが一般ユーザーからは削除できないような設定
• コンプライアンモード
  管理者であってもAmazon S3バケット内のデータを削除することができなくなる。一般社員向きdはない

暗号化データ

S3バケット内のデータの暗号化方法は2通り。暗号化方式はバケット生成時にSSE-S3・SSE-KMS・SSE-Cのいづれかを選択。

• S3のデフォルト暗号化
  暗号の復元は自動。
• KSMのカスタマーキー
  カスタマーキーが必要。

S3の暗号化を有効化するとログの暗号化も自動で実施される。

リクエスタ支払い機能

別リージョンからの利用と支払いに関しては、S3バケットのクロスアカウントアクセスを有効化し、バケットのリクエスタ支払い機能を有効化する。これで、別リージョン企業の有するAWSアカウントからのS3バケットへのアクセスを許可した上で、データ取得コストを別リージョン企業側に支払わせる。

S3バケットの最適ストレージの見つけ方

Amazon S3 分析のストレージクラス分析により、ストレージアクセスパターンを分析し、適切なデータを適切なストレージクラスに移行すべきタイミングを判断できる。

静的WEBホスティング

S3で静的WEBホスティングを設定する流れは、ブロックパブリックアクセスを無効化→バケットポリシーでバケットの読み取り処理を設定→インデックスをバケット内に保存→静的WEBホスティングの設定画面で、インデックスドキュメントを設定し有効化する。

HTTP レスポンスコード 403が帰ってくる場合、オブジェクトの読み取りアクセス許可が付与されていない可能性がある。

Glacierのデータ移行

5GBを超える場合は、CLIを利用して移行。100GBを超える場合はマルチパートアップロードを使用。

S3 インテリジェント階層化

アクセスパターンが予測できないか、変化するオブジェクトに対して、S3 One-Zone-IAとStandard-IAストレージのコストを最小限に抑える階層化ストレージを提供する。機械学習を使ってコスト効率の良いストレージクラスに自動的に遷移させます。

静的ウェブサイトの表示

サイトのコンテンツとなるIndex.htmlをバケットにアップロード。

• s3-website ダッシュ (-) リージョン
  http://bucket-name.s3-website-Region.amazonaws.com
• s3-website ドット (.) リージョン
  http://bucket-name.s3-website.Region.amazonaws.com

上記のURLにアクセスすると、S3バケットの静的ウェブサイト用に設定したIndex.htmlを表示できる。

S3でCloudFrontを利用する場合

アクセスをCloudFrontのみに絞るために、CloudFront側でオリジンアクセスアイデンティティ（OAI）を割り当てて、そのOAIにのみS3バケット内への読み取り権限があるようにS3バケットポリシーを設定する。

これで、外部のユーザーからはS3バケットにアクセスできない。（単にIAMロールを付与するだけではだめ）

AWS Lake Formation

S3を利用したデータレイク構成を容易に実施することができる。データベースとオブジェクトストレージからデータを収集およびカタログ化して、データをAmazon S3デ ータレイクに移動して保存することができる。

パブリックアクセス設定機能

パケットレベル・アカウントレベルで、オブジェクトへのパブリックアクセスをブロック可能。この機能でブロックを有効化することでS3バケット全体に対してパブリックアクセスを拒否できる。

AWS Lambda

サーバレスアプリを作成するための関数ベースのサービス。

関数のエラー

コードエラーが発生している場合はLambda関数自体の実行ができない。

同時実行処理の限界

限界数を超えると、それ以上のLambda関数が起動できない。動いているものが停止することはない。

利用可能プログラミング言語

Java、Ruby、Python、Node.js、.NET、Go。

Event Bridgeとの連携

毎日◯時に〜処理を実行するなどが設定可能。

Step Functionとの連携

処理フローを構築して、バッチ処理のように動かす。

SQSとの連携

キューからLambda関数を実行する。

コスト

使用した分だけ。関数を定義しているだけではお金はかからない。

エフェメラルストレージ

1つのLamda関数に512MB～10240MBのエフェメラルストレージ(/tmp) を割り当てられる。

Lambda関数の最大呼び出し時間

タイムアウト制限は15分。その他サービスとの兼ね合いで、変わる可能性はあります。例えば、Amazon API GatewayはLambda関数プロキシの呼び出しが完了するまで最大29秒待機します。

Lambdaが向いていない処理

常時多数の処理が実行されるようなアプリケーションのトランザクション処理には向いてない。

Lambda Layer

複数のLambda関数でライブラリを共有できる仕組み。Lambda関数間で利用する共通機能などに適用できる。同じライブラリを利用するLambda関数などが複数あった場合便利。

Lambdaエッジ

サーバー管理を行わなくても、Webアプリをグローバルに分散可能。パフォーマンス向上。

Invocation

Lambda関数の名前空間にあるメトリクス。イベントまたはAPI呼び出し関数の回数を測定可能。

スケジュール設定

定期的にRDSなどのサービスに対して処理を行うなど可能。

Amazon EBS

ES2にアタッチできるストレージ。AmazonEFS / インスタンスストアも合わせて覚えておく。EBSボリュームはボリュームタイプやサイズを途中で変更可能。

一つのAZでEBSボリュームを作成すると、そのゾーン内でのみ自動的に複製が生成される。別のAWSリージョンには複製されません。

IPはEBSではなくインスタンスに設定する。

EBSをインスタンスにアタッチして使用する流れ

まず、インスタンスに追加でアタッチしたボリュームの利用を開始するために、最初にボリューム内にファイルシステムを作成することが必要。

Amazon EBS ボリュームタイプ

HDDよりもSSDの方が性能は良い。また、SSDの中でも「プロビジョンドIOPS SSD」と「汎用SSD」が選択できるが、プロビジョンの方が性能は良い。

HDDでいうと「スループット最適化HDD」「コールドHDD」があり、「スループット最適化HDD」の方が性能は良い。https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volume-types.html

• プロビジョンドIOPS SSD 1000Mib/s
• スループット最適化 HDD 500Mib/s
• 汎用SSD　コールドSSD 250Mib/s

I /O処理での比較

• io2 Block Express：IOPS最大256000
• io2：IOPS最大64000
• io1：IOPS最大64000

Amazon EBSとAmazon EFSの違い

• 接続台数
  EBS：１台のEC2インスタンスと接続可能
  EFS：複数のEC2インスタンスと接続可能
• 耐久性
  EBS：単一のAZ内で冗長化
  EFS：複数のAZで冗長化
• 拡張性
  EBS：手動でボリューム拡張可能
  EFS：自動でボリューム拡張可能

EFSはファイル共有用。NFSv4プロトコル。SMBプロトコルを利用するのはAmazon FSx for Windows。

EFSは標準ストレージと低頻度アクセスストレージ(EFS IA)という２つのストレージクラスがある。EFS IA は、毎日アクセスしないファイルに対して最適化されたコスト効率の料金とパフォーマンスを提供。

ファイルシステムは EFS ライフサイクル管理を有効にするだけで、選択したライフサイクルポリシーに従ってアクセスしないファイルは、自動的にEFS IAに移せる。

EBSとインスタンスストアの違い

• 接続
  EBS：EC2インスタンスストアとネットワーク接続
  インスタンスストア：ホストコンピュータのストレージを利用
• 耐久性
  EBS：単一のAZ内で冗長化
  インスタンスストア：冗長化されない
• 拡張性
  EBS：ボリューム拡張可能
  インスタンスストア：ボリューム拡張不可能
• 料金
  EBS：従量課金
  インスタンスストア：無料

バックアップ

EBSはスナップショット機能があり、データのバックアップができる。バックアップ先はS3。定期的にバックアップを取得する場合は、DLMを使用する。

EBSボリュームの暗号化

既存のEBSボリュームを作成後に設定で暗号化することはできない。EBSのデータをコピーする際にオプションで暗号化オプションを設定することで、暗号化されたスナップショットを作成することができます。その後、スナップショットを復元すれば暗号化されたEBSボリュームに変更することができる。

共有

Amazon EBSボリュームはインスタンス間で共有できません。EBSは単一のEC2インスタンスからのみのアクセスに対して、EFSは複数のリージョンとインスタンスにファイルシステムをマウントできる。

EC2の休止状態との関係

EC2 インスタンスを休止状態にすることで、インスタンスメモリの内容が Amazon EBSのルートボリュームに保存されます。インスタンスが再起動すると、インスタンスメモリの内容が再ロードされます。 これによりインスタンスを特定の期間休止させることで、コストを節約することができます。

スナップショット

EC2が起動している状態で取得できる。スナップショットはS3に保存される。取得できるデータはスナップショット開始時点のデータ。リージョンを跨いでコピーできる。

このスナップショットを復元させて、新しく作ったテスト環境用のEC2などにアタッチすることで、簡単にテスト環境を作れます。

RAID0構成

複数のEBSを使用して1台の装置のように使用することができる。

RAID1構成

耐障害性が I/O パフォーマンスより重要な場合に利用されるストレージ構成。1つのEBSボリュームが故障したとしてもデータの消失を防ぐことができ、RTO1分以内の回復が可能。    

課金

EBSボリューム課金はEC2が停止していてもアタッチしていれば課金。デタッチした場合は課金なし。

マルチアタッチ機能

Amazon EBSプロビジョンド IOPS io1・io2ボリュームのみ利用可能。単一のボリュームを同じAZ内の最大16個のインスタンスに同時アタッチ可能。

Amazon SNS

通知配信サービス。「トピック」を作成し、トピックに「サブスクリプション」という形で購読者（エンドポイント）を追加します。この購読者に対して通知を送る。エンドポイントにメールアドレスを設定するとメール送信が、HTTP/HTTPSでは指定URLにHTTPリクエストが、Lambdaを選択すると対象のLambda関数を実行できる。FIFOで配信順序を保証。

Dynamo DB

スケーラブルで高速なパフォーマンス。低レイテンシ（読み書き遅延時間が遅くない。）
Dynamoテーブルのキャパシティは、変化が予測できない場合は「オンデマンド」、予測できる場合は「プロビジョン」。IoTデータやセッションデータ管理などに用いられます。メタデータの保存にも最適。画像データは保存できない。SQLクエリを実行はできない。

Dynamo DBの自動保存

DynamoDBは３箇所のアベイラビリティゾーンに自動保存される。ただし、Dynamo DBにスナップショット機能などはない。

セッション管理

AWSでセッション管理を行う場合は「DynamoDB」「ElastiCache」のどちらか、または、両方を使うのが一般的。

ゲートウェイエンドポイントとの接続

VPCのルーティングテーブルを書き換えて、ゲートウェイ経由でサービスにアクセスできるので、インターネットを経由せずに操作可能。

TTL

過去〇ヶ月分のデータのみを必要とする場合は、データにTTL（Time To Live）を設定可能。

DynamoDB Streams 

使用するとトランザクションを他のアプリケーションと共有可能。また、DynamoDBテーブルに保存されたデータ項目の変更を記録できるようになる。

異なるリージョン間でのテーブル同期

DynamoDB Streams を有効にし、対象のリージョンとレプリケーション先のリージョンに同じテーブルを作成する。さらに、それらのリージョンに作成されたDynamoDBテーブルを同期するグローバルテーブルを設定する。これで、DynamoDB Streamsによってリージョン1のDynamoDBテーブルのデータに更新が発生した場合に、リージョン2のDynamoDBテーブルへと自動的にレプリケーションされる設定が可能。

DynamoDBグローバルセカンダリインデックス

クエリ処理の柔軟性を高めるための機能

DynamoDB Accelerator（DAX）

DAXを有効化することで、追加のキャッシュレイヤーによって最大10倍のパフォーマンス向上を実現できる。ただし、高コストなため、コスト最適を考慮する場合は向いていない。（Auto Scalingによる処理負荷に対するスケーリングの方がコスト最適）

AWS Data Pipelineとの連携

Data Pipelineは様々なAWSデータベースやストレージ間のデータの移動と変換を自動化するサービスです。DynamoDBに設定することが可能で、定期的なデータ取得タスクを設定可能。

AppSyncとの連携

リアルタイムで最新の状態に保つコラボレーションアプリを構築できます。

ポイントインタイムリカバリ

指定した日時の状態にテーブルデータを新しいテーブルとして復元します。DynamoDB ではテーブルに対して増分バックアップが実施され、これを利用して、目標復旧時点（RPO）の15分および目標復旧時間（RTO）の1時間を容易に達成可能。

整合性

• 強い整合性モデル
  データの更新の際にデータベースをロック。過去のデータが読み取られないようにしてデータの一貫性を担保。
• 結果整合性モデル
  データの更新でデータベースがロックされることはない。可用性とスケーラビリティを維持。データ更新時に読み取りリクエストが発生した場合は、データの整合性が担保されません。

DynamoDBのキャパシティ増強

処理性能は上がるが、コストが高い。

IAM

サービスの権限をロール管理するサービス。IAMポリシーで権限を定義し、IAMロールに設定する。このIAMロールを各種サービスに付与する。基本的に権限管理はアクセスキー管理よりもロール管理がセキュアで推奨されている。

AWS CLIを利用する場合

権限はロールとアクセスキーにより制御できる。（ロールが推奨されている。）操作する対象の権限を持つユーザがCLIを実施する必要がある。

開発者が不必要な権限ロールを追加するのを防ぐ

IAMアクセス許可境界で権限ロールを追加できる範囲を設定できる。

署名付きURLを利用するケース

決められた期間内に専用端末でログファイルを見る場合などに利用。S3バケットで署名付きURLを生成し、有効期限が切れる前にベンダーにログファイルをダウンロードしてもらう。仮にIAMロールを付与したアカウントを作成すると、ユーザを削除しないと常に使用できてしまうため。

IAMデータベース認証

これを使うとEC2インスタンスからIAMデータベース認証を利用してRDSのDB インスタンスにアクセスが可能。DBインスタンスに接続する際にパスワードは必要なく、認証トークンを使用。認証トークンはAmazon RDS がリクエストに応じて生成する一意の文字列で、IAM内において管理されます。そのため、ユーザー認証情報をデータベースに保存する必要はありません。

AWS IAM Identity Center（旧SSO）

SAMLフェデレーションを設定してオンプレミス環境のActive Directoryと連携することで、Active Directoryの資格情報を使用して、全ユーザーがAWSとオンプレミスの両方のリソースに対して、一元的にアクセスできるシングルサインオンを実現することができます。

Microsoft Active Directory

オンプレミス環境にあるWindowsサーバーやWindowsアプリに対するユーザー認証を実現する認証用サーバー。こちらのサービスとIAMユーザ管理両方を行うと管理が非効率。そのため、MS Active Directoryの認証情報とIAM認証情報を連携させることが必要。AWS SSOを有効にする必要あり。
Microsoft Active DirectoryとIAM側のディレクトリリクエストをするためにはAD Connectorというディレクトリゲートウェイを使用します。
SAMLを使用して、AWSクラウドへのAPIアクセス用にSAMLベースのフェデレーションを設定できる。

AWS Organizations

アカウントを一元管理するサービス。全アカウントにシングル サインオン (SSO) ソリューションを必要としている。アカウントで IAM ロールを使って、特定のAWSアカウントのリソースへのアクセス権を別の AWS アカウントに付与できますが、これはAWS Organizationsのメンバーアカウント間の連携にしか利用できません。外部ベンダーアカウントには適用できない。

デフォルトでメンバーアカウントが属するOUに対して「FullAWSAccess」（すべてのリソースの全ての操作可能）が付与される。そのため、どんな権限をつけても、この権限があると、全操作可能のまま。そのため、SCPを利用する場合は、この権限をまずは、デタッチする必要がある。

ちなみに、SCPでは明示的なDeny要素が、最初の明示的なAllowよりも優先。

サードパーティソフトの権限

AWSマーケットプレイスで購入したサードパーティのソフトウェアが必要とする権限のIAMポリシーを作成。次に、IAMポリシーを利用してクロスアカウントアクセス用のIAMロールを作成し、該当するサードパーティのソフトウェアに設定。これによってソフトが対象のEC2インスタンスに連携可能。

アカウントごとにIAMユーザを作成する必要がなくなります。

AWS アクセスキー

AWSのアクセスキーは、アクセスキーIDとシークレットアクセスキーから構成される。AWSアクセスキーは、ユーザ名とパスワードによる認証と同様の処理をプログラムアクセス時にアクセスキーIDとシークレットアクセスキーを用いて行える。メリットは更新の影響がないが、デメリットとして、権限が強いキーが存在してしまうこと。

AWS STSとの違い

AWS STSは一時的なセキュリティキーを作成し、キーを提供した信頼するユーザーへ渡すことで、AWSリソースへのアクセスを許可できる。IAMのアクセスキーとの違いは「有効期限」を設定し、一時的な許可が可能な点と、リクエストに応じてその都度動的に作成されるため、ユーザーに紐づいてキーが保存されない。AWS IDを発行しなくて良いので、一時的なアクセスが必要なユーザに対して有効。

OpenID Connect互換のIDプロバイダーを使用してユーザがサインインするには、AWS STSを利用したWeb IDフェデレーションによってアクセス認証を一時的に許可できます。

SCPとの違い

SCPはOrganizationsでAWSアカウントに対する権限の制御ができる。AWSアカウントまたは組織単位(OU)内のアカウントのグループに対してAWSサービスへの権限境界を設定できます。
SCP自体は権限を与えるものではなく「ここまでは許可できる」という境界を設定するもので、AWSアカウントまたはOUに関連付けられているSCPがある場合、許可していないAWSサービスは、AWSアカウントまたはOUへのアクセスを拒否されます。

SCPの使い方としては、組織の大枠でまず使用するサービスにSCPを設定。このSCPで許可・拒否された範囲においてIAMの方で個別ユーザに許可権限を与える流れ。

ROA

RIRを介して作成されるドキュメント。 Amazonが特定のAS番号のアドレス範囲を公開することを承認する。 これを利用して、パブリックにルーティング可能なIPアドレスの一部または全部を、オンプレからAWSアカウントに導入可能。

IAM Access Analyzer

AWSアカウントの外部からアクセスできるリソースを特定する総合的な解析を実行可能。これにより、S3の外部アカウントからのアクセス情報を分析して、不正なアカウントアクセスがないかを確認可能。

Elastic IP

EIPの課金条件

EIPはElastic IPの略です。AWSで利用するインターネットからアクセス可能な静的アドレス。課金される場合は下記です。

• EIPを関連付けているEC2インスタンスが停止している場合
• EC2に関連付いていない（= 昔は使っていたが、EC2を停止してしまって忘れられている）EIP
• 関連付いているEC2は起動しているがEIPが二つ目けれども、ふたつ目以降のEIP
• EIPの「リマップ(remap)」を、1ヶ月に100回以上行った場合

課金されない条件は下記です。

• Elastic IP アドレスが EC2 インスタンスに関連付けられている。
• Elastic IP アドレスに関連付けられているインスタンスが実行中である。
• インスタンスには、1 つの Elastic IP アドレスしかアタッチされていない

インスタンスに関連付いていて、動いている場合に課金されないので注意。

Elastic IPの上限

AWS アカウントでリージョンあたり5つの Elastic IP アドレスまでが上限。パブリック (IPv4) インターネットアドレスが数に限りがあるため。ただし、専用フォームから申請で上限を上げられる可能性。

Amazon RDS

RDSで利用できるDBはAurora・MySQL・MariaDB・Oracle・SQL Server・PostgreSQL。データは暗号化されている。（AWSでMySQLを利用する場合は、Auroraがベスト。）

バックアップ

7日間自動バックアップがある。初回のみフルバックアップで、2回目以降は差分のみバックアップ。パッチ作業自動化。

マルチAZ

RDSはマルチAZを利用可能。マルチAZ構成を利用することで、別のAZにDBを複製し、障害発生時などに切り替ることで高可用性を維持できます。

リードレプリカ

付加分散を目的として、読み取り用として、DBを複製すること。リードレプリカを作成するには新しくDBを作成するより、元のDBからリードレプリカを作るほうが効率が良い。
リードレプリカにはレプリケーションラグというタイムラグがある。

Amazon RDSからデータ自動削除

処理完了後にAmazon RDSから自動でデータを削除したい場合、Amazon Data Pipelineを使用して、指定された間隔で、信頼性のあるデータ処理や移動（ETL）を行うことができます。

Amazon RDS Proxy

RDSプロキシを利用することで、アプリとデータベース間のコネクションを管理できる。Lambda関数からRDS DBインスタンスへのコネクションプールを確立・管理し、アプリからのデータベース接続を最小限に抑えることができ、DBコネクションが非効率に乱立することを防げる。

ストレージエンジン

通常のMySQLではMyISAMをストレージエンジンとして設定することができるが、Amazon RDS MySQLではMyISAMをストレージエンジンとして使用できない。Amazon RDS MySQLにおいて、推奨されるストレージエンジンはInnoDB。

クエリ処理高速化

Amazon ElastiCacheをAmazon RDSに連携してクエリ処理高速化を可能に。

ランダムI/O遅延

ランダムI/O遅延が発生している場合は、データベース性能が不足している。したがって、RDSのデータベース性能をI/O処理に適したものにする必要がある。

拡張モニタリング

拡張モニタリングを有効化すると、RDSのDBインスタンスの様々なプロセス・スレッドのメモリ状況を常時モニタリングすることができる。

Amazon RDSイベント機能

DB更新などが発生した際にAmazon SNS通知やEventBridgeなどでメッセージ送付が可能。ただし、Amazon RDSイベント機能はAmazon S3イベント通知のようにデータ登録でのDB操作をイベントとして利用はできない。そのため、Lambda関数をデータ登録と連動させて動かすことはできません。

また、ライフサイクルポリシーなどはない。

Amazon Aurora

AuroraはMySQL、PostgreSQL互換のDB。3つのAZにまたがるクラスターボリュームを作成します。オンデマンド自動スケーリング構成によって、予測困難なアプリケーションワークロードに対応可能。

Aurora Serverless

Aurora ServerlessはDB インスタンスクラスのサイズを指定せずにデータベースエンドポイントを作成できるというサーバーを常時起動しない柔軟性の高いAuroraデータベースです。Aurora Serverlessは最小と最大のキャパシティーを設定して、その範囲でキャパシティを自動で調整することができます。

RDSとの差

Auroraは標準的なRDS for MySQLと比べて5倍のスループット、標準的なRDS for PostgreSQLと比べて3倍のスループットを実現。

可用性

Auroraはクラスターが3つのAZに分散されて構成。高い可用性を担保。

フェイルオーバー機能

フェールオーバーの実行時間はレプリカを作成している場合は開始から終了までに通常30秒以内に完了。レプリカを作成していない場合、フェイルオーバーは15分以内で完了。

Amazon ElasticCache

インメモリデータベースキャッシュ。

• Amazon ElasticCache for Memcached
  レプリカ機能なし。memcachedはシンプルを追求したデータストアです。memcachedでできることはRedisでもできる。
• Amazon ElasticCache for Redis
  プライマリの複数レプリカを作成可能。データをディスク上に保存しないため高速でのデータアクセスを実現しています。そのためリアルタイム性を追求するシステムで活用されることが多いです。機械学習などにも利用できる。ただし、データベースが停止するとキャッシュクリアされてしまうため、データが消えます。スナップショット機能でバックアップができます。

Amazon SQS

キュータイプ

Amazon SQS（Simple Queue Service）には2つのキュータイプがある。

• 標準キュー
  配信が 1 回以上行われます。そのため重複配信する場合があります。システムが重複メッセージを処理可能な設計である場合や順序が重要でない場合に使用可能。
• FIFO（First-In-First-Out）キュー
  メッセージが一度だけ配信され、送信された順で処理される。重複メッセージの配信ない。 

キューの優先順付

SQSのキューには優先順付ができます。

SQSによるスケーリング

SQSはキューによってシステム処理を分散させて負荷分散ができる。（水平方向のスケーリング）

キューの保存期間

デフォルトでは4日間。ただし、SetQueueAttributesアクションで、メッセージ保持期間の値を60秒〜14日間まで設定可能。メッセージの保持期間が終了すると、メッセージは自動削除。

可視性タイムアウト

キューが対象に受信された直後、キューがまだ残っているので、そのキューを再処理しないように設定する時間。

メッセージ重複排除ID

同一の重複排除IDが設定されたメッセージをキューへ送っても5分間は受付けない設定です。

ポーリング機能

キューに空のキューが送信されないようにする手法。SQSへメッセージを取得するポーリングリクエスト実施時に空の場合、指定数秒の間待機するロングポーリング機能を使用。一定時間待たない場合はショートポーリングを使用。

デッドレターキュー

デッドレターキューはSQSのキューの一種で、エラーが起きた際に再処理を行うためにデッドレターキューにSQSのメッセージが一旦入って、再処理が行われる。

（例）

LambdaにSQSメッセージ送信→Lambdaエラー→複数リトライ→SQSのメッセージがデッドレターキューに入る→再処理

キューサイズ

キューサイズとはメッセージ数のこと。SQSキューサイズを確認するAutoScalingトリガーを構成することでインスタンスを増加させることができる。

キューサイズが増えると処理が停滞する。この停滞はトラフィックを監視してもわからない。（トラフィックとはネットワークを流れる情報、およびその情報量）

Amazon kinesis

ストリーミングデータをリアルタイムで処理できるサービスです。

Kinesisの種類

• Kinesis Video Streams：配信
  数百万など大量のデバイスから動画をストリーミングで安全かつ簡単に配信することが可能
• Kinesis Data Streams：リアルタイム処理
  デバイスなどから送られる大量のストリーミングデータをリアルタイムに収集、処理して別のサービスに配送するサービス。IoTデバイスからリアルタイムでデータを取得し、処理を行うなど。
• Kinesis Data Firehose：取り込み変換
  データロードまで60秒必要となり、リアルタイムな処理には向いていませんが、データ変換・配信するのに向いています。
• Amazon Managed Service for Apache Flink（旧Analystics）：分析
  データ分析後に配信などの処理ができる。これを利用して、ストリーミングデータをクエリ処理によって分割し、直接Amazon S3バケットに保存などができる。

Kinesis Dataについて

シャード（ストリーム内の一意に識別されたデータレコードのシーケンス）のセット。Kinesisのストリームは複数のシャードで構成され、各シャードが容量の1単位。

シャード制限

• 読み取り：最大1秒あたり5件のトランザクション
• 読み取り最大合計レート：2MB/1秒
• 書き込み：最大1秒あたり1000レコード
• 書き込み最大合計レート：1MB/1秒 (パーティションキーを含む) 

ストリームデータ容量は、ストリームに指定したシャード数で決まる。ストリーム総容量はシャードの容量の合計です。

リシャーディング

Kinesis Data Streamシャードと言われるデータシーケンスを結合・分割することができる機能がある。

appstreamとの違い

AppStreamはアプリケーション配信を行うもので、Kinesisはデータのリアルタイム処理を行うものです。

AWS CloudFormation

JSONやYAMLで記述されたテンプレート（定義ファイル）を利用して、AWSリソースをプロビジョニングするサービス。インフラ環境のデプロイを自動化できる。

CloudFormation記載内容

• Resources：インスタンスなどのスタックリソースとそのプロパティを指定
• Parameters：テンプレートに渡す値を指定
• Description：コメントなど
• Mappings/Conditions：条件分岐を記載

RegionMap:
  ap-northeast-1:
    hvm: "ami-0792756bc9edf3e63"
  ap-southeast-1:
    hvm: "ami-0162da29310cc18f6"

この内容が、PropertiesにあるMapping関数によって引用可能。

Properties:
  ImageId: !FindInMap [RegionMap, !Ref 'AWS::Region', hvm]

この記述だと、リージョンごとにインスタンスを作成できる。

AWS SAMとの連携

サーバーレスアプリケーションをデプロイするためのツール。YAMLを使用して、サーバレスアプリケーションのLambda関数、データベース、イベントソースマッピングをモデリングできる。

費用

CloudFormation自体は無料。料金はプロビジョニングしたリソースの利用料金のみに発生。

スタックセット

CloudFormationテンプレート内にAWSリソースの設定を定義して、１つのテンプレートにより複数の AWS アカウントやリージョンにリソースを展開できます。

ドリフト

チェックする機能。

Cloudwatch

AWSリソースとアプリケーションの監視サービスで、パフォーマンスデータを収集し可視化し、リアルタイムでアプリケーションを最適化してトラブルシューティングするための補助サービス。カスタムメトリクスは有料で、通常メトリクスは無料。

標準メトリクス

ネットワーク受信料やCPU利用率、データ転送量、ディスク使用量等の標準メトリクスを提供。

カスタムメトリクス

カスタムメトリクスで下記を取得できる

• アプリやサーバーが生成したデータ（Webの読み込み時間、リクエストエラー発生率、同時処理数またはスレッド数）
• CPUやネットワーク使用率、ページロードやクエリ実行時間
• UnhealthyHostCountメトリクス：異常とみなされるターゲットの数を提供

検知・通知機能

CloudWatchはアプリケーション処理の異常正常を監視することもできる。以上を検知した場合、アラームによって通知や自動的なアクションを起動することができ、SNSなどのサービスへの連携も可能。

（使用例）

• EC2停止→イベントをトリガーとしてSNSへ通知→Eメールを送信
• 異常状態インスタンス置換
  UnhealthyHostCountメトリクスをモニタリングするAmazon CloudWatchアラームを作成。
  AutoScalingアクションを構成。
  アラームが起動した場合アラーム状態になった場合Auto Scalingに通知→異常状態のインスタンスを置換

ログ機能

CloudWatch Logsを使ってCloudWatchから取得したログを集約してログを記録できる。

共有リンク

Cloud watchのダッシュボードのみを見たい管理者がいる場合などに使用。最小特権の原則に従うとIAMロールを付与するとAWSコンソールのその他画面を見られてしまう。そのため、この共有リンクを作成し、共有することで、ダッシュボードのみを確認可能とできる。

Amazon CloudFront

Webページを外部から見る場合にレイテンシを抑えるためのサービス。また、予期せぬアクセス集中にはAmazon Cloudfrontが有効です。CloudfrontはCDNサービスであり、キャッシュサーバがリクエストに応答するため、オリジンサイトへのアクセス集中を避けることができます。Cloud FrontはUDPをサポートしていません。

Auto Scalingとの違い

Auto Scalingもアクセス集中には有効だが、CPUが90%を超えた場合など、トリガーをきっかけにスケールするため、予期せぬアクセス集中に対応ができない。

国単位のサイトアクセスの遮断

CloudFrontを使うと国単位のアクセス遮断などが可能。セキュリティグループでは実現できない。

オリジンサーバへのアクセスが増える原因

キャッシュされるべきデータがエッジロケーションにないため、オリジンサーバへのアクセスが頻発。原因として、キャッシュの保持期間が短くなっていることが考えられる。対策としては、CloudFrontディストリビューション設定において、Cache-Controlのmax-ageディレクティブの値を上げる。

CloudFrontの署名付きCookies機能

CloudFrontの署名付きCookies機能を利用すると、現在のオブジェクトURLを変更しないで、有料会員だけにプライベートメディアファイルへのアクセスを提供できる。

DDoS攻撃対応

AWS Shieldを組み合わせることで、WebアプリへのDDoS攻撃に対して最適な防御壁を設定可能。

IP遮断

CloudFrontのIPマッチ条件でリクエストの発信元のIPアドレスに基づいて着信Webリクエストを許可またはブロックできます。

CloudFrontとビューア間のセキュア通信

CloudFrontとビューア間の通信はHTTPS Comodo、DigiCert、Symantec、またはその他のサードパーティプロバイダーなどの信頼できる認証局（CA）によって発行された証明書、またはAWS Certificate Manager（ACM）が提供する証明書の両方が可能。 

CloudFrontとオリジン間のセキュア通信

CloudFrontとカスタムオリジン間のHTTPSオリジンがELB以外の場合は、信頼されたサードパーティー認証機関 (CA) (Comodo、DigiCert、Symantec など) によって署名された証明書を使用、ELBの場合はACMの証明書が必要。

Amazon Route53

Amazon Route53はAWSが提供する高い可用性とスケーラビリティを持つクラウドDNS（Domain Name System）サービス。

レコードの種類

• Aレコード：ホスト名とIPv4アドレスの関連付けを提供する
• AAAAレコード：ホスト名とIPv6アドレスの関連付けを提供する
• CNAMEレコード：ドメイン名から別のドメイン名を参照
• MXレコード：対象ドメイン宛のメール配送先ホスト名を定義するレコード
• SOAレコード：DNSサーバや管理者のメールアドレス、シリアル番号などを保持して、更新されているかの判断を行う

ルーティングポリシー

• レイテンシーベースルーティング
  レイテンシーの低いリソースへルーティング。アプリケーションの処理を高速化可能。
• 位置情報ルーティング
  接続元から地理的に近いリソースへルーティング。
• シンプルルーティング
  指定されたレコードの情報に従ってルーティング。
• 複数値回答ルーティング
  DNSクエリに対する応答として複数の値を返すように設定可能。IPアドレス単位での正常・非正常を判断してルーティングすることが可能。これはロードバランサーに置き換わるものではありませんが、ヘルスチェックした上で複数の IP アドレスを返すことができる。

フェイルオーバシステム構築

ヘルスチェック機能を使えば、EC2の状態をチェックして、異常時にフェイルオーバーできる。

• アクティブ/パッシブ方式
  常時2台が動き1台で処理を実行。もう一台は待機。route53ではこちらしかできない。
• アクティブ/アクティブ方式
  常時2台が稼働し処理を実行。障害時性能が半分に。

2台構成で性能を分けるため、1台が動かなくなると性能が落ちる。

RDSのフェイルオーバシステム

DBインスタンスのCNAMEレコードをプライマリーからセカンダリーに切り替えることで、セカンダリーをプライマリへと昇格。セカンダリーDBは最初から実行できる状態で待機されているホットスタンバイとしておく。

DDoS攻撃への対応

DDoS攻撃時にユーザが継続してアプリを利用できるように「シャッフルシャーディング」「 エニーキャスト ルーティング」という支援機能がある。

Amazon Athena

サーバーレスのインタラクティブなクエリサービスで、S3上のデータを直接SQLを使用して簡単に分析できます。機械学習向けで、通常の使用には向かない。

料金

クエリ単位にお金かかる。

AWS Data Pipeline

指定された間隔でオンプレミスデータだけでなく、異なるAWSコンピューティングとストレージサービス間でデータを処理移動するサービス。例えば、LambdaなどでDBのデータ削除処理を行なった場合、合わせてS3のバックアップも削除するなどが可能。

AWS Step Functions

AWS Step Functionsはワークフローのステップを自動的に起動してアプリケーションを順番通りに実行するサービス。

デフォルトで、状態がエラーの場合、実行全体が失敗する。アクションとフロー状態に対するエラー処理方法を設定可能。その際、リトライを実施して処理を継続するか、タイムアウトによって処理を停止できるが、再起動を実施するわけではない。

ワークフローには入力も設定でき、アクションが長時間待ちになっている場合は、人の入力作業が滞っているなども考えられる。

Amazon DLM（Data Lifecycle Manager）

各タスクをスケジューリングできる。

（例）
EBSのスナップショット作成や削除をスケジューリング。

ECS

• EC2モード
  EC2を選択した場合は各インスタンスのOSアップデートなど、EC2自体の運用が必要。
• Fargateモード
  EC2自体の運用管理を削減できる。

（ECS利用例）
そこからDynamoDBへ読み込み接続をする場合、ECSタスクにIAMロールを付与する。

AWS Fargate

FargateはECS・EKSと共に使用するコンテナクラスターを管理サービス。ECSを動かす環境として、Fargateを選択可能。AWS上でコンテナをサーバーレスで実行することが出来るようにする機能を提供してくれるサービス。

Snowball

Snowballは安全なデバイスを使用してAWS内外に大量のデータを転送するペタバイト規模のデータ転送サービス。データはGlacierに直接インポートはできないため、Glacierに保存する場合は一旦S3に保存して、ライフサイクルポリシーでGracierに保存するようにする。

デバイスの種類

• Snowball Edge Storage Optimized
  データ転送用のedgeデバイスオプションで100TB (80TB使用可能)
• Snowball Edge Compute Optimized
  機械学習、フルモーション動画など大規模42TB
• Snowball Edge Storage Optimized
  大規模なデータ移行80TB

現在SnowBall利用は推奨されておらず、AWSではSnowball Edgeの利用が求められている。

AWS VPN

オンプレミス環境とのサイト間VPN接続を確立する。サイト間VPNをAWSとオンプレミス間に構成するためには、オンプレミス側のネットワーク環境にカスタマーゲートウェイデバイスを設置して、カスタマーゲートウェイを構成します。

Acceleratedサイト間VPN

Global Acceleratorを利用したサイト間VPN。VPNの通信はAWSグローバルネットワークを経由して接続されるため、高可用性・高パフォーマンスが維持される。

Amazon Redshift

Amazon Redshiftとは、AWS上で提供されているデータウェアハウス専用のデータベースサービスです。あらゆるデータを構造化して蓄積し、高速に分析処理できることが大きな特徴です。機械学習にも利用されます。

RedShift Spectrum

RedShift Spectrumは、Amazon Redshiftと統合されており、S3のデータを直接クエリする能力を持ちます。BIツールと統合されているため、多数の同時ユーザーからの複雑なクエリの要件も満たすことができます。オブジェクト全体に対して実施するため、データの一部を分析するなどは向いていない。

拡張VPCルーティング

Redshiftクラスターに対する拡張VPCルーティングを有効にすることで、VPCに出入りするRedshiftクラスターのすべてのCOPYおよびUNLOADトラフィックを監視可能。

Work Load Management（WLM）

Redshiftのクエリ処理に対して割り当てるRedshiftのリソースを指定する機能。

Amazon EMR 

ビックデータ分析用のサービス。Hadoopフレームワーク。1秒ごとの課金。EMRとRedshiftの違いは、ツールか保管しておく場所かの違い。

膨大なデータを迅速かつコスト効率よく処理して分析するサービス。DynamoDB に格納されているデータなど大量のデータを迅速かつ効率的に処理できるが、レポート作成など向きではない。（過剰スペック）

AWS Secrets Manager

データベースやその他のサービスの認証情報を安全に暗号化してシークレットとして保存・取得する仕組みを提供します。自動回転をオンにすることで定期的に資格情報を更新可能

GuardDuty

継続的にモニタリングを行い、悪意のあるアクティビティを確認するサービス。

AWS Shield

マネージド型の分散サービス妨害 (DDoS) に対する保護サービス。standardは基本的に軽減のみ。AWS Shield Advancedでは、DDoS攻撃によって生じた可能性のある請求に関しても保証されます。

AWS Glue

データをRDSやKinesis、S3データレイクなどから集めて、変換して読み込むためのサービス。

AWS API Gateway

トラフィック管理、認可とアクセスコントロール、モニタリング、API バージョン管理などのAPI管理を実施できます。そのパフォーマンスとしては最大数十万規模の同時 API コール処理が可能。API Gateway は受信したAPI コールと転送データ量に応じて課金される従量課金制サービス。
L3/L4 DDoS攻撃に対応可能。

Lambdaと連携して、サーバレスAPIを作成できる。

処理性能を向上

高負荷に備えてAPIゲートウェイのスロットリング制限設定とキャッシュを有効化する。

レスポンスキャッシュ機能があり、実行結果をキャッシュすることが可能。

AWS Transit Gateway

複数のVPCやVPCピアリングをハブ＆スポークス方式で接続可能。中央のゲートウェイからネットワーク上にあるAmazon VPC、オンプレミスのデータセンター、リモートオフィスそれぞれに単一の接続を構築して管理することができ、管理の簡略化が可能。

VPN接続スループット向上

AWS Transit Gatewayを利用して、Equal Cost Multipath (ECMP)をこれらの接続の間で有効にできます。トラフィックを複数のパスに負荷分散できるので帯域幅を広げられる。そのため、VPN接続などで接続数が増えた場合、帯域を広げてスループット改善が可能になる。

マルチキャスト

マルチキャストは複数のデバイス（ホスト端末）に対して同一データを一斉に送信するネットワーク方法のこと。AWS Transit Gatewayでマルチキャストを有効にすると実行可能。

AWS Strage Gateway

オンプレミスから実質無制限のクラウドストレージへのアクセスを提供するハイブリッドクラウドストレージサービス。ストレージ間のデータ移行に利用できる。

ボリュームタイプ

• キャッシュ型ボリュームモード
  データ自体はS3に書き込まれる。頻繁にアクセスするデータはキャッシュとしてローカルに保持。ストレージ容量は、必要なキャッシュ容量分確保。アクセス方式も移行前と変わらない。
• 補完型ボリュームモード
  キャッシュ型と違い、ローカルに必要な分ストレージ容量を確保する必要がある。

データの暗号化

デフォルトでデータを暗号化している

AWS Database Migration Service

オンプレの各種データベースをAWSへ移行するサービス。また、Oracleなどは単純に移行するだけではなく、スキーマーの再作成なども条件次第では可能。（手作業ミスを防げる）

AWS Server Migration Service

オンプレの仮想マシン（VMware vSphereやHyper-V/SCVMMなど）をAWSへ移行するサービス。もう使われていない。Application Migrate Service（AMSに変わった）

AWS DataSync

オンプレのファイルストレージをAWSストレージサービス(S3やEFS)間のデータ移動を自動化。安全オンラインサービス。

AWS Transfer Family

Amazon S3やAmazon EFSへのファイル転送を実現するツール。SFTPやFTPを利用したファイル転送に対応しているため、小規模ファイル転送が可能。

Direct Connect

オンプレミスとAWSを繋げる回線。構築に時間はかかるがセキュリティ抜群。
Direct Connectの料金は「データ転送料金」と「ポート時間料金」の２つで従量課金制。

DirectConectで接続時、オンプレとEC2両方のサーバに対して、SQSなどでポーリング処理が可能。

AWS Import/Export

大量のデータを物理ストレージデバイスからAWSに転送するサービス。ストレージドライブをAWSに郵送し、Amazon高速内部ネットワークを利用してドライブから直接データを転送できる。

Glacierストレージクラスのデータはエクスポートがサポートされていない。

VM Import/Export

仮想マシンイメージを既存の環境から Amazon EC2 インスタンスにインポートすることや、元のオンプレミス環境にエクスポートすることが簡単にできます。

CodePipeline

CodeDeployやECSなどのサービスをパイプラインとして設定することで、コードの開発からデプロイまでを自動化することができる。

CloudHSM

クラウドベースのハードウェアセキュリティモジュール(HSM) 。AWSクラウド側で安全性の高いハードウェアベースの暗号化保存機能を利用して、暗号化キーを簡単に生成して使用できます。

Amazon WorkSpaces

WindowsまたはLinuxのデスクトップを数分でセットアップ可能。これを利用して、すばやくスケールすることで世界中のたくさんの従業員に仮想デスクトップを提供できます。

AWS Outposts

RDSをオンプレ環境にセットアップ可能にするサービス。ほぼすべてのデータセンタ・コロケーションスペース・オンプレ施設にAWSサービス、API、ツールを提供可能。

Amazon CloudSearch

ウェブアプリ向けの検索ソリューションを容易かつコスト効率良く設定、管理、スケール可能。

Amazon OpenSearch Service

Amazon S3バケット保存した大量のPDFファイルに対して、ドキュメント共有アプリケーションにフレーズ検索機能を実装することができる。

AWSサービスの上限関連

• ElasticIPの上限：5
• EC2インスタンスのタグの上限：50
• 1リージョン当たりのVPC上限：5
• 1リージョン当たりのサブネット上限：200

その他アーキテクト概念系

Design for Failure

障害が発生してもサービスを継続できるようにシステムを設計する。

メッシュアーキテクチャ

データ品質に対する責任を全社横断組織のような「中央組織」と各事業部門といった「ドメイン」に分散させることで、データ利活用におけるドメインとしてのアジリティを確保しつつ、ドメインが作成したデータやアナリティクスを他ドメがメッシュのように相互利用できるようにするもの。

ハブアンドスポークシステム

「ハブ」と呼ばれる拠点に一旦全ての荷物を集約し、拠点別に振り分けてから各拠点に向けて配送する仕組みのことです。

SDK

SDKはPerl以外は利用可能。

プロキシサーバ

クライアントからの要求をフィルターし、製品の更新に関連する要求のみを許可して、特定のソフトウェア更新以外のすべての要求をフィルタリングできます。ネットワークACLおよびセキュリティグループはURLに基づいてリクエストをフィルタリングすることができない。

CIDR

国の特定はできない。

シャーディング

データベース内の複数のテーブルにデータを分割するための一般的な概念です。リクエスト増加などで単一のマスターDBの運用で限界がある場合に、 一定のルールに従いデータを複数のDBに振り分けることでアクセスを分散させることができます。 

ingress

パケットがネットワーク機器へ入力すること。

egress

パケットがネットワーク機器から出力されること。

Swiftの座標系とは？

Swiftの座標系、特に画面描写に限定した座標は下記3つです。

• CGRect
• CGSize
• CGPoint

それぞれ順番に解説していきます。

CGRect

CGRectはX座標、Y座標、縦、横を指定する座標系です。画像で表すと下記です。

これをSiwftコードを記載すると下記のように表現できます。

// 座標をセット
CGRect rect = CGRectMake(10, 20, 100, 80);
// 各座標を出力する
print(rect.origin.x)//10
print(rect.origin.y)//20
print(rect.size.width)//100
print(rect.size.height)//80

一般的にSiwftでアプリ開発をする場合で、画面にオブジェクトを表示する場合はこちらのCGRectを使用します。

CGSize

CGSizeは対象のオブジェクトの縦と横を指定する座標系です。画像で表すと下記のようなイメージです。

これをSiwftコードを記載すると下記のように表現できます。

// 座標をセット
CGSize size = CGSizeMake(100, 50);
// 各座標の出力
print(size.width)//100
print(size.height)//50

CGPoint

CGPointは対象のオブジェクトのX座標、Y座標を指定する座標系です。画像で表すと下記のようになります。

これをSiwftコードを記載すると下記のように表現できます。

// 座標セット
CGPoint point = CGPointMake(200, 300);
// 各座標の出力
print(point.x)//200
print(point.y)//300

CGRect・CGSize・CGPointの違い

座標系の違いはオブジェクトのX座標、Y座標、縦、横をどこまで指定するかという違いを持ちます。先ほどの章でも述べましたが、一般的にSwiftのアプリ開発でオブジェクト描写を行う際に使用されるのはCGRectです。

では、今回の記事は以上です。ほかにも多数のSwift関連の記事を記載しているので、興味があれば是非サイト内見ていってください。

Dockerインストール

Docker環境がすでにある方は飛ばしてください。

まずはDockerを自身のPCにインストールします。インストールの流れは下記です。

1. PCにあったDockerをインストール（こちらの公式ページから）
2. Dockerのアカウント作成（こちらの公式ページから）

DockerはWindowsとMacなどOSの違いでインストールするものが違います。ただ、インストールは簡単でイメージファイル、またはexeファイルをダウンロードし、クリックするだけだけです。

アカウント作成では適当なIDを打ち込んで、メールアドレスとパスワードを設定するだけです。アカウント作成が終わればメールが飛んできますので承認すればアカウントが使用できるようになります。

Dockerは安心できるコミュニティなのでメール登録も安心して行ってください。

Dockerがインストールできたか確認するためには、コマンドプロンプト、ターミナルを開き、下記コマンドを実行してください。バージョン番号が出力されればOKです。

docker --version

クジラのアイコンのアプリケーションがPCに追加されていると思いますのでそちらをクリックするとDockerが起動します。

詳細なDockerのPython環境構築手順は下記記事にまとめているので気になる方は是非参考にしてみてください。（Docker上にPython環境を構築しHello World）

DockerでAnaconda起動

次にAnaconda3のDockerイメージを取得し、Dockerコンテナを立ち上げていきます。

docker pull continuumio/anaconda3

取得したイメージをビルドしてDockerコンテナを起動します。

docker run -it -p 8888:8888 continuumio/anaconda3 --name jupyter /bin/bash

これでDockerコンテナが起動し、コンテナ内のバッシュコマンドを開くことができたと思います。次はコマンド操作によってAnaconda環境に含まれているJupyter notebookを起動していきます。

DockerコンテナでJupyter notebookを起動

下記コマンドを実行してください。

jupyter notebook --notebook-dir=/opt/notebooks --ip=0.0.0.0 --no-browser --allow-root

• –notebookはJupyter notebookが保存されている場所
• –ipは0.0.0.0を指定
• –allow-rootはルート権限

（Jupyter notebookが存在しないとなった場合やPCがWindowsの場合は、Docker上の環境パスがデフォルトでは設定されていないので、cdコマンドで、「opt/conda/bin/」のフォルダ移動して、上記コマンドを実行してください。）

下記のような表示が出力されればJupyter notebook のローカルサーバがDocker上に起動しています。

To access the notebook, open this file in a browser:
        file:///root/.local/share/jupyter/runtime/nbserver-27-open.html
    Or copy and paste one of these URLs:
　　　　　　｛ここにURLが表示されている｝

URLが出力されているのでこれをPCのブラウザで開くとJupyter notebookのページを開くことができます。操作方法もローカル環境にインストールしたAnaconda版のJupyter notebookと差はないです。

今回の記事は以上です。ほかにも多数のDocker系の記事やPython関連の記事を記載しています。興味があればサイト内見ていってください。

Dockerでの環境構築について

自身のPCに環境を構築する場合は自身のPCにDocker Engineを介さず直接OSにソフトをインストールしているイメージです。そのためソフトのバージョンを変更する場合は、ソフトを都度アップデート、またはアンインストールしてから再度インストールする必要があります。

しかし、Dockerで環境を構築する場合は、自身のPCに乗っている箱のような下記のようなイメージです。

コンテナごとにソフトをインストールできるので、バージョン3.7のPython、バージョン3.8のPython両方でコードを試せるなどの利点があり、開発シーンにおいて重宝されます。

今回の流れは、このDockerのコンテナにPythonをインストールし、コンテナ内でPythonファイルを実行し、「HelloWorld」を出力します。

Dockerインストール

まずはDockerを自身のPCにインストールします。インストールの流れは下記です。

1. PCにあったDockerをインストール（こちらの公式ページから）
2. Dockerのアカウント作成（こちらの公式ページから）

DockerはWindowsとMacなどOSの違いでインストールするものが違います。ただ、インストールは簡単でイメージファイル、またはexeファイルをダウンロードし、クリックするだけだけです。

アカウント作成では適当なIDを打ち込んで、メールアドレスとパスワードを設定するだけです。アカウント作成が終わればメールが飛んできますので承認すればアカウントが使用できるようになります。

Dockerは安心できるコミュニティなのでメール登録も安心して行ってください。

Dockerがインストールできたか確認するためには、コマンドプロンプト、ターミナルを開き、下記コマンドを実行してください。バージョン番号が出力されればOKです。

docker --version

クジラのアイコンのアプリケーションがPCに追加されていると思いますのでそちらをクリックするとDockerが起動します。

では次にPythonの開発環境を構築していきましょう。

Docker上でPython環境構築

Dockerではすでによく使われるソフトのセットがDockerイメージとして公開されています。そのため、Pythonの開発環境もそのDockerイメージを使います。

コマンドプロンプト、ターミナルを開き、下記コマンドを実行してください。

docker pull python:latest

こちらのコマンドで、Pythonの最新バージョンのDockerイメージをDockerにインストールすることができます。

インストールが完了すれば、そのDockerイメージをビルドします。

docker run -it --name test0622 python:latest /bin/bash

• –name test0622がDocker環境の名前
• python:latestはビルドに利用したイメージ
• /bin/bashはDockerコンテナをビルドした最後にバッシュコマンドを実行し、Dockerコンテナ内のバッシュを開いているということです。（少し、理解しずらいかもしれませんがWebサーバにはSSH接続したようなイメージで、ここでコマンドを実行することができます。）

ビルドしたDockerコンテナのバッシュで下記コマンドを実行してみてください。

python --version
Python 3.8.3

Pythonがインストールされていることが確認できました。

このDocker環境はDockerアプリからやコマンドで一覧として確認できます。

PCをシャットダウンして再度起動した場合などはDockerが止まっていることがあります。その場合は、アプリアイコンからDockerを起動するか、コマンドで下記を実行し、Dockerを立ち上げます。

コンテナを動かす
docker start [作成したコンテナ名]
コンテナを止める
docker stop [止めたいコンテナ名]
コンテナのbashに入る
docker attach [入りたいコンテナ名]
コンテナから出るかつコンテナを止める
exit

では最後に、Pythonファイルを作成し、HelloWorldを出力しましょう。

DockerコンテナのPythonでHelloWorld

下記コマンドをDockerコンテナ内で実行します。

// 開発フォルダに移動
cd ~

// hello.pyファイル作成
touch hello.py 

// vimインストール
apt-get update
apt-get install vim

// ファイル編集モード
vi hello.py

ファイル編集モードで、下記をPythonファイルに書き込みます。vimコマンドは簡単で「i」で書き込みモード、「Esc」でモードから戻る、「:wq」で上書き保存＋終了です。

print("Hello World")

このファイルをdockerコンテナのPythonで実行するとHelloWoirldが出力されます。

python hello,py

Hello World

以上で今回の記事は終了です。Docker上でPython環境を構築し、HelloWorldを出力してみました。ほかにもDocker関係の記事を多数記載しているので是非参考にしてみてください。

今回参考にした文献は「講談社：ブロックチェーン技術概論」という書籍です。

記事の構成は以下です。

• 仮想通貨・ブロックチェーンの歴史（仕組みと歴史は密接な関係にあるため）
• ブロックチェーンの仕組み
• ブロックチェーンの信頼担保策
• ブロックチェーンの合意（コンセンサス）

では記事に進みます。

ブロックチェーンの歴史

仮想通貨・ブロックチェーンの歴史は実は古めです。

2008年に「サトシ・ナカモト」という謎の人物がネット上に1つの論文を投稿し、その論文の中に仮想通貨とそのシステムの中核を担うブロックチェーン技術について記述があったというのが原点です。

つまり仮想通貨・ブロックチェーンは2008年生まれということです。最近巷でブームのAIの誕生は1960年代のため、2008年生まれというのがかなり新しい（むしろ新しすぎる技術）ということがわかると思います。

この新しすぎるという点で仮想通貨の使い道はまだ少ないと言えます。日本で仮想通貨を利用して飲み食いができる飲食店や、物を購入できる施設はかなり少ないです。（ビックカメラは使えるとか笑。）

しかし、技術の将来性は認められ、将来性という点で価値がつき、価格が上昇しているのが現状です。

では話を戻します。

この2008年に発表された論文をもとに興味をもったエンジニアが開発を進め、論文発表から1年後の2009年に仮想通貨第1号のビットコインが誕生するのです。

ビットコインの誕生後、イーサリアムやリップルなど数々の仮想通貨が開発され現在しのぎを削っています。

「仮想通貨 ＝ ブロックチェーン」は間違いです。

• 仮想通貨は資産
• ブロックチェーンは仮想通貨を運用する上で必要な技術

この2点をよく区別して押さえておきましょう。

簡単にまとめると歴史はこんなものです。まだまだ歴史は浅いということです。次に仕組みに移っていきます。

ブロックチェーンの仕組み

今回の記事のメイン部分です。ブロックチェーンの仕組みを解説します。仮想通貨を交えた説明の方がわかりやすいので今回はビットコインで使用されるブロックチェーンを解説します。

ブロックチェーンの仕組み解説の流れは下記です。

1. 仮想通貨管理の仕組み
2. 仮想通貨で送金を行う仕組み
3. トランザクションの内部的な処理について

ではまずは仮想通貨を運用する上で最も大事な管理方法の概念を解説します。

仮想通貨管理の仕組み

ネット上の通貨なのに2重で使用されたりしないのかと不安に思う方もいると思いますが、仮想通貨の管理方法は鉄壁です。

現金の銀行振込などの管理と仮想通貨の管理方法を比較してみましょう。

• 銀行の場合：絶対的な信頼のある銀行という第3者が取引記録を管理することで信頼を担保
• 仮想通貨の場合：全員で取引履歴を管理することで信頼を担保

ここで押さえておくことは、仮想通貨の管理は銀行の場合と比較して、第3者という信頼に足るものはなく、全員で管理を行うという点が大きく違うことです。

なぜ全員で管理で信頼が担保されるのか？

よくあるネットの記事ではこの説明がなされていないため雰囲気だけの理解になってしまいます。本記事ではこういった部分も余すことなく解説します。

仮想通貨の管理は共有台帳という過去の取引を全て記録した台帳が担っています。台帳はイメージがつきやすいと思います。

家庭内では家計簿、企業ではエクセルやソフトで帳簿などといった形での共有管理は割と一般的に行われているのです。

家計簿や帳簿と仮想通貨の共有台帳の違いは共有台帳を仮想通貨を扱う全員が保有し中身を見ることができる点が違います。

例えば2人で共有台帳を管理する場合を考えてみます。

この場合、どちらが正しい記録かわからないためBさんの不正はバレません。では3人の場合はどうでしょうか？

3人で管理する場合、差異が生じている取引はAさんCさん・Bさんの間で差が発生しています。多数決の原理ではありませんが、Bさんの共有台帳がおかしいことがわかります。

先ほど説明した全員で共有台帳を管理とは、この犯人探しの原理をさらに拡大し、ビットコインを保有する全ての人（全員）と不正を働いた（今回はBさんの）共有台帳の差異が不正の証拠となり、信頼担保につながるっているということです。

つまりこれらの説明をまとめると「全員で取引履歴を管理することで信頼を担保」ということになるわけです。

紹介した共有台帳。これが「ブロックチェーン」です。

ブロックチェーンについて

ブロックチェーンをもう少し詳細に解説していきます。ブロックチェーンとは「ブロックが繋がったもの（チェーン）」したものという意味です。

ブロックという単位について踏み込んでいきましょう。下記のような取引があるとします。

共有台帳に蓄積する時間はビットコインで約10分が1周期と決まっています。全世界で起きたビットコイン取引はこの周期ごとに記録され、これが1つの「ブロック」というわけです。この「ブロック」に過去のブロックチェーンと連結させていくことでチェーンが伸びていきます。

「ブロックチェーン ＝ ブロック（10分間の取引履歴）が連結したもの」

次に、仮想通貨での送金を行う仕組みからブロックチェーンの技術を見てみましょう。

仮想通貨で送金を行う仕組み

仮想通貨で送金を行うことを「トランザクション」と言います。

この送金処理には問題点があります。

• 2重使用問題（詳しくは「ブロックチェーンの合意（コンセンサス）」の章にて）
• 金額の不正

「貨幣的価値の総量保存則」というものがあります。何らかの処理があっても入金に対して出金の価値は等価。簡単にいうと、100円の入金に対して出金は100円で等価になるということです。

このことから上図のAさんが入金した「入金4」に対してBさんが受け取る出金4は等価であります。これは正しいのでこのトランザクションは承認となります。

一方、入金と出金が合わない場合、監査に引っかかりトランザクションは承認されません。

ブロックの全てのトランザクションが承認された時過去のブロックチェーンと連結されるというわけです。

実はこれにはまだ隠された問題があるのですが、そこは本記事の「ブロックチェーンの同意（コンセンサス）」章にて解説します。

送金（トランザクション）の仕組みがわかったことで次は、この送金（トランザクション）の内部的な処理を解説していきます。ここからがブロックチェーンの真髄です。

トランザクションの内部的な処理について

ここから難しいです。

先ほどの送金の仕組みはわかりやすいように「入金」「出金」というふうに概念的なイメージで記載しました。しかし、仮想通貨はあくまでもビット（データ）です。

どの入金データが出金データに紐づくかを判断するために「秘密鍵」「公開鍵」による「デジタル署名」管理を行なっています。

秘密鍵に対応する公開鍵は唯一。秘密鍵は自身で管理するもので公開鍵はその名の通り公開している

では送金を行う際の内部的な処理を解説していきます。

送金者はまず「トランザクション」というデータを作成します。

• 入力：送金者の資金
• 出力：送金先・金額など

このトランザクションを仮想通貨ネットワーク（今回はビットコインネットワーク）のノードと呼ばれるPtoP通信のネットワークで伝播されていきます。

上図のような取引で送金者のAさんは入力に対する資金をもっていることが前提になります。この資金はもちろん仮想通貨の取引ですので、仮想通貨データになります。これを「UTXO」と言います。

UTXOについて理解するのには下記のようにAさんが過去にCさんから送金をしてもらったという設定を加えて図にしてみます。

1. 送金をされると出力には送金先のユーザの「秘密鍵」に対応する「公開鍵」が付与される
2. 送金をされる側のAさんは「公開鍵」でロックされた仮想通貨資金の「UTXO」を持つ
3. この資金をBさんに送金する際の資金とするため秘密鍵で鍵を開ける
4. Bさんに送金する入力にデジタル署名（秘密鍵）

これでUTXOについてよく理解できたと思います。最終的に下記図のようにBさんのUTXOが増え、AさんのUTXOは減るということです。

私はこの部分が前後関係を記載している記述が少なく難しさを感じていました。

トランザクションがノードによるビットコインネットワークを伝播する際の処理に関しても詳しくみていきましょう。

トランザクションの伝播

トランザクションの伝播の流れは下記です。

1. トランザクションが行われた初めのノードでトランザクションが正しいかを検証する
2. 正しかった場合：伝播、正しくない場合：トランザクションは無かったことに

トランザクションが正しいかどうかをまず初めのノードで検証され、このノードで承認された場合のみトランザクションは全てのノードに伝播します。

この検証方法はトランザクションのデジタル署名の秘密鍵が参照するUTXO（上図でいうとCさんから送金されたUTXO）の公開鍵を開けることができるかによって検証可能です。

しかし、トランザクション内に以前の取引情報はありません。ではどうやって検証を行うのか？
答えはノード内に保存されているブロックチェーンです。

ブロックチェーンには全ての過去の取引が記録されているため参照することができるのです。

では次は仮想通貨の管理で説明した不正防止法をもう少し深掘り解説していきます。

ブロックチェーンの信頼担保策

ブロックチェーンの管理のところでも概念的な信頼担保の方法を述べましたが、この章ではさらに詳しくその施策を解説していきます。それは下記3点です。

1. ハッシュチェーン
2. タイムスタンプサービス
3. プルーフ・オブ・ワーク

順番に説明していきます。

ハッシュチェーン

ブロックチェーンのブロックには「取引履歴」と「前のブロックのハッシュ値」が保存されています。

このハッシュ値は暗号学的ハッシュ関数により出力される値です。このハッシュ関数はデータに対してハッシュ値という暗号を出力する関数です。このハッシュ関数は入力が同じ場合は出力が同じになるが、少しでも値が違えば全く予想されない暗号を返します。

このため取引履歴を少しでも触るとブロックチェーン全体の整合性合わないようになるということです。

タイムスタンプサービス

先ほどのハッシュチェーンだけでは実は信頼性は担保されません。なぜなら、一部の取引履歴をいじるとそのブロックの整合性が合わなくなりますが、全ブロックのハッシュ値を再計算してしまえば整合性を合わせることは可能だからです。

これを防ぐためにある時点（上図で例えるとブロック2）で刊行物として現実世界に数値を公表する方法です。これでハッシュ値の全入れ替えは不可能になります。

プルーフ・オブ・ワーク

新しいブロックを生成するためには下記図のように一つ前のハッシュ値を見つける必要があります。

ハッシュチェーンで説明しましたが、ハッシュ値の計算には膨大な時間（プルーフ・オブ・ワーク）が必要になります。この膨大な時間は先ほどの再計算はブロックの数だけ行う必要があります。

現在マイニングを行なっている人も増えているため1回のプルーフ・オブ・ワークに勝つことでさえかなり限られています。そのため全ブロックで再計算を行い勝つことは不可能と言えるでしょう。

この3つの施作によってブロックチェーン管理は信頼担保をしていると言えるのです。

では、ブロックチェーンの合意（コンセンサス）についてです。

ブロックチェーンの合意（コンセンサス）

ブロックチェーンは先ほどの説明で完全に信頼に足るものであると述べております。しかし、最後にブロックチェーンに矛盾が発生する際に必要な合意（コンセンサス）について理解しておきましょう。

例えば2つのノードから同時に同じUTXOを資金として別の送金先に送金を行うなどです。

この場合図のように異なる履歴をもつトランザクション1と2のどちらが正しいかを判断する術がありません。

この場合ブロックは下記のようになります。

この判断する（同意する）アルゴリズムを「コンセンサス・プロトコル」または、「コンセンサス・アルゴリズム」と呼びます。

アルゴリズムの中身は大きく2つです。

No1. 最も長いブロックを正とする

これはブロックチェーンの長いほうを採用するというもの。ブロックチェーンの長さが同じ場合はNo.2の方法を使用します。

No2. 枝分かれしていない部分までを正とし、その先を切り取る

もう一つが枝分かれしていないビットコインネットワークに承認されている（全てのノードで承認されている）部分から先を切り取る方法です。

こういった方法でチェーンの枝分かれは回避されているのです。

長くなりましたが以上がブロックチェーン技術の仕組みに関してです。今後も継続して、記事を記載していくので是非興味がある方はブックマークなどに入れておいてください。

私自身、初学者のためもし間違い等あればご指摘いただけると幸いです。