CloudFrontについて勉強
AWS 認定ソリューションアーキテクト – アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
- Amazon CloudFrontについて
- Amazon CloudFrontのイメージ
- CloudFrontを使用した構成図
- CloudFront内、もしくは別機能と組み合わせたセキュリティ
- CloudFrontの料金体系
- Amazon CloudFrontへの監査
- Lambda@Edge
- Amazon CloudFrontのキャッシュ削除
- Amazon CloudFrontのオリジンサーバーのフェイルオーバー機能
- [~.html?language=JP]のような末尾の国コードをどのように特定するのか
- ナレッジQA
Amazon CloudFrontについて
Amazon CloudFront は、データ、動画、アプリケーション、および API をすべてデベロッパーにとって使いやすい環境で、低レイテンシーの高速転送により世界中の視聴者に安全に配信する高速コンテンツ配信ネットワーク (CDN) サービスです。
Amazon CloudFront（グローバルなコンテンツ配信ネットワーク）| AWS
CDNサービスと書いてある通り、WEBサイトの情報を取得する際のマスターのサーバ（ここでいうオリジンサーバー）がダウンしないようにするサービスのこと。
またWebサービスのコンテンツ配信に加えて、映像や音声のストリーミング配信にも対応していることも特徴。
Amazon CloudFrout(以下CloudFrout）は高可用性、高パフォーマンス、低レイテンシーを売りにしている機能。
CDNサービスなしで直接WEBサーバをホストしているEC2インスタンスを公開しているのであれば、リクエストが増加した場合にパフォーマンス低下するので、CloudFront使いましょうという感じ。
CDNサービスなしでS3を静的サイトとして公開している場合、URLはHTTPでセキュリティ面で問題あるので、CloudFrontを使用することでHTTPSで利用することが可能。
Amazon CloudFrontのイメージ
標準ログ (アクセスログ) の設定および使用 - Amazon CloudFrontより引用
これはログに関してのページから取ってきたものだけど、これが一番分かりやすかった。
登場人物は主に3人。
- エッジロケーション
- ディストリビューション
- オリジンサーバー
エッジロケーション
コンテンツをキャッシュしておくキャッシュサーバーのことで、閲覧者がコンテンツにアクセスした際に最初に接続されるサーバーがここ。コンテンツがキャッシュされている場合はこのサーバーから配信することで、オリジンサーバーへの負荷を減らすことができる。
閲覧者は自分の一番近い場所（地理的ロケーション）エッジロケーションからしかデータが取れない。
エッジサーバーに情報がない場合は、オリジンサーバーから取得することになる。
地理的ロケーションでデータを取ってくるだけなので、位置情報でルーティングとかそういう機能はない。
また、エッジロケーション上にデータが存在しない場合は上で書いた通りオリジンサーバーからデータを取るので、404を返したり、処理を待ったりとかはしない。
接続ポイントは149か所。
リージョン別エッジロケーション
エッジロケーションにキャッシュされていない場合は、リージョン別エッジロケーションに接続される。
エッジロケーションよりも大容量データをキャッシュ可能なキャッシュサーバー。
ここでもだめならオリジンサーバーに接続して情報を取得する。
接続ポイントは11か所。
ディストリビューション
エッジロケーションとオリジンサーバーとをつなげる要素がここ。エッジロケーション側にオリジンサーバのどこに情報があるかを伝えるのが役目。
ディストリビューションには大きく分けて2つ存在する。
ウェブディストリビューション
通常使われるディストリビューション
RTMP（Real Time Messaging Protocol）ディストリビューション
RTMP (Real-Time Messaging Protocol)という形式でのストリーミングによるVOD動画配信が可能。
S3をオリジンとし、S3に格納している動画ファイル（mp4やflv）をRTMPでストリーミング配信できたりするらしい。
ちなみにRTMPはどういうものかというと
Real Time Messaging Protocol (RTMP) とは、Adobe が開発している、Adobe Flash プレーヤーとサーバーの間で、音声・動画・データをやりとりするストリーミングのプロトコル。 元々は Macromedia が開発していて、Adobe に買収された。
Real Time Messaging Protocol - Wikipedia
なので、
Flashのサポート終了するので、このディストリビューションもなんかどうやら廃止になるっぽい。
ディストリビューションから地域制限が可能
特定の国からアクセスされたくない情報がある場合、ディストリビューションから地域制限を行うと、アクセスすることができなくなる。
地域制限 (地理的ブロッキング) を使用すると、CloudFront ウェブディストリビューションを通じて配信しているコンテンツについて、特定地域のユーザーによるアクセスを回避できます。地域制限を使用するには、次の 2 つの方法があります。
地域制限は次のような仕組みになっています。
1.仮に、コンテンツをリヒテンシュタインでのみ配信する権限を持っているとしましょう。自分の CloudFront ウェブディストリビューションを更新して、リヒテンシュタイン王国のみを含むホワイトリストを追加します。(または、リヒテンシュタイン王国以外のすべての国を含むブラックリストを追加することもできます。)
2.モナコ王国に住むユーザーがお客様のコンテンツをリクエストすると、DNS はそのリクエストをイタリア、ミラノにある CloudFront エッジロケーションにルーティングします。
3.ミラノのエッジロケーションはお客さまのディストリビューションを検索し、モナコ王国のユーザーはコンテンツをダウンロードすることは許可されていないと判断します。
4.CloudFront は HTTP ステータスコード 403 (Forbidden) をユーザーに返します。
コンテンツの地理的ディストリビューションの制限 - Amazon CloudFront
エッジロケーションが地理的ロケーションから場所を特定するのを利用して国を特定しているとのこと。
ただここで設定できるのはあくまで国単位。
オリジンサーバー
CloudFroutへキャッシュするコンテンツの提供元であるオリジンとして、ELBやEC2、S3などを指定できる。
オンプレサーバーも指定可能。
カスタムエラーページ
オリジン側がエラーコードが返却された場合、あらかじめ設定したエラーページを表示することができる。CloudFrontを使用した構成図
主に以下ような構成が主流
AWS WAFを利用してCloudFrontのELBオリジンへ直接アクセスを制限してみた | Developers.IOより引用
Cache Distributionパターン(CloudFront+S3)を一撃で設定する | Developers.IOより引用
クラウドデザインパターンはほかにもあるけどとりあえず今は、CloudFront→S3orEC2と、CloudFront + AWS WAF （ウェブアプリケーションファイアウォール）の構成をベースに記載。
キャッシュされていないコンテンツの問い合わせ先として、静的コンテンツはS3、動的コンテンツであればELBでルーティングするように構成することで、フロントエンドの高い可用性を維持しつつ、バックエンドのELBやEC2の負荷を軽減することができる。
CloudFront内、もしくは別機能と組み合わせたセキュリティ
セキュリティとしてセキュアな通信をするためには以下があげられる。
・HTTPS 接続を設定する
・特定の地理的な場所にいるユーザーがコンテンツにアクセスできないようにする
・CloudFront 署名付き URL または署名付き Cookie を使用してコンテンツにアクセスするようにユーザーに要求する
・特定のコンテンツフィールドのフィールドレベルの暗号化を設定する
・AWS WAF を使用してコンテンツへのアクセスを管理する
コンテンツへのセキュアなアクセスとアクセス制限の設定 - Amazon CloudFront
ディストリビューションで地域制限の話を書いたのでそれ以外のセキュリティ要素について記載する。
署名付きURL・署名付きCookieを使用する
S3ってなんじゃ？（CloudFrontでアクセス制御：Origin Access Identity × 署名付きURL） | cloudpack.mediaより引用
一時的にユーザにアクセス権を与えたい場合に使用する。
署名付きURL
- 個別ファイルに対してアクセス制限をかけたい場合に使用する。
- RTMPディストリビューションを利用できる。
- URLが変更されてしまうのが難点。
主に個のファイルに対して何かしたい場合に使用する。
署名付きCookie
- URLを変更したくない。
- 複数のメディアへのアクセス制限をかけたい
主に複数のファイルに対して何かしたい場合に使用する。
AWS WAFと組み合わせる
CloudFrontで永続的に外部リンクを利用させたくない、あるいは特定のリクエストのみ利用させたいという意図がある場合、WAFのreferer制限を使用することで実現可能。ブロックされている場合、403エラーが返却する。
指定したリクエスト以外のすべてのリクエストを許可する
特定の攻撃者からのリクエストを排除するときに利用します。
指定したリクエスト以外のすべてのリクエストをブロックする
制限されたウェブサイトを作りたい時に利用します。
例 : 日本国内以外からのアクセスは出来ないようにしたい。
AWS WAF Referer制限ってなに？ - Qiita
上記の通り、発信先IPに基づき着信Webリクエストの許可拒否を設定することができるが、この仕組みを移行ツールとして使用する！みたいなことはできない。
問題傾向としては、CloudFront周りの回答で「WAF」のワードがない状態でreferer制限があった場合は間違っているので除外していい。
referer制限はWAFの機能なので。
オリジンアクセスアイデンティティ（OAI）の利用
S3やに保存している静的コンテンツで普段全ユーザに公開していないものに対して、特定の閲覧者（IPアドレス)にだけ公開したい場合に使用する。CloudFroutからプライベートサーバにアクセスしたい時に使うケースになる。
この場合、CloudFront経由でアクセスしてほしく、直接S3にアクセスしてほしくないため、バケットポリシーでを変更する。
Amazon S3 バケットから配信するコンテンツへのアクセスを制限するには、次のステップに従います。
・オリジンアクセスアイデンティティ (OAI) と呼ばれる特別な CloudFront ユーザーを作成し、ディストリビューションに関連付けます。
・CloudFront が OAI を使用してバケット内のファイルにアクセスし、ユーザーに提供できるように S3 バケットのアクセス許可を設定します。ユーザーが S3 バケットへのダイレクト URL を使用して、そこにあるファイルにアクセスできないようにしてください。
これらのステップを実行すると、ユーザーは S3 バケットから直接ではなく、CloudFront 経由でのみファイルにアクセスできます。
オリジンアクセスアイデンティティを使用して Amazon S3 コンテンツへのアクセスを制限する - Amazon CloudFront
[CloudFront + S3]特定バケットに特定ディストリビューションのみからアクセスできるよう設定する | Developers.IOより引用
SSLによる通信の暗号化
SSL証明書を利用したSSL暗号化通信が可能。AWS Certificate Manager（ACM）を使用することで、ACMの証明書や、信頼できるサードパーティーの証明書をACMに取り込んで使用することで可能になる。
AWS Certificate Manager は、AWS のサービスとお客様の内部接続リソースで使用するパブリックとプライベートの Secure Sockets Layer/Transport Layer Security (SSL/TLS) 証明書のプロビジョニング、管理、デプロイを簡単にします。
AWS Certificate Manager（SSL/TLS 証明書のプロビジョン、管理、およびデプロイ）| AWS
CloudFront↔ELB(Elastic Load Balancing)間の証明書もACMを使用して使用できるが、一部注意が必要な点がある。
それはCloudFront↔ELB(Elastic Load Balancing)以外の機能間での証明書について。
通常のCloudFront↔ELB(Elastic Load Balancing)間の証明書
https://recipe.kc-cloud.jp/archives/11355より引用
通常はこのように、ACMが提供する証明書と、信頼できるサードパーティーの証明書をACMに取り込んで使用することで暗号化通信を可能とする。
エッジロケーション側とオリジンサーバー側両方に設定する。
CloudFront↔ELB(Elastic Load Balancing)以外の機能間の証明書
ここが問題になる。
CloudFront + EC2インスタンスでACMで発行した証明書を適用したら、結局他の証明書も必要になった話。 | ハックノートより引用
上のように、ELB経由せず直接EC2インスタンスを参照している場合（オリジンサーバーがELBを経由しない）、ACMが提供する証明書は使用できない。
したがって、ACMを使用せずに信頼できるサードパーティーの証明書を使用しなければならない。
SSL/TLS 証明書は、カスタムオリジンの次のソースから使用できます。
・オリジンが Elastic Load Balancing ロードバランサーの場合、AWS Certificate Manager (ACM) が提供する証明書を使用できます。信頼されたサードパーティー認証機関が署名して ACM にインポートされた証明書を使用することもできます。
・ELB ロードバランサー以外のオリジンの場合、信頼されたサードパーティー認証機関 (CA) (Comodo、DigiCert、Symantec など) によって署名された証明書を使用する必要があります。
CloudFront とカスタムオリジンとの間の通信に HTTPS を必須にする - Amazon CloudFront
Amazon Cognitoを使用した認証
ユーザ認証したユーザ（ログインできた）にだけ情報を閲覧させたい場合に使用。
CloudFront + S3 + Cognito + AWS Amplify + Vue.js で会員制サイトをサーバーレスで構築 | ハックノートより引用
AWSサーバレスアーキテクチャでSPA（シングルページアプリケーション）を構築したい場合のテンプレート構成になる。
https://academy.gmocloud.com/know/20160201/1529
AWSサーバレスアーキテクチャでSPAを実装する（1）～SSLを経由してブラウザからLambda APIへアクセスするまでの下準備 (1/9)：CodeZine（コードジン）
CloudFrontの料金体系
このあたりで決まる。
トラフィックの分散
コンテンツのエッジロケーションの場所によって値段が異なる。
エッジロケーションの数ではなく、場所で値段が違うことに注意。
リクエスト数
これは単純にリクエスト数（HTTP/HTTPS）
データ転送量
エッジロケーションやオリジンサーバーから転送したコンテンツのデータ量。
当然だけどオリジンサーバーからデータを転送すると料金が高くなる。
転送量が高い場合は、エッジロケーション側でコンテンツを圧縮して単純にファイルサイズを小さくして転送することでディスカウントすることができる。
Amazon CloudFrontへの監査
CloudFrontへのアクセスログを知りたい場合は、CloudFront内のアクセスログを有効にする。そうするとS3に1時間で数回、ディストリビューションへのリクエストに関するアクセスログを格納するようになる。
コンソール画面や、CloudFront APIでログ記録設定を変更できる。
なおCloudFrontへの監査にあたって、VPCフローログや、CloudTrailは使用できない。
Lambda@Edge
名前はLambdaの1機能のように見えるが、CloudFrontの機能のひとつ。その言葉の通りでCloudFrontでLambdaを使用しようというもの。
エッジロケーション側にLambdaと同様なコードを構築することで、地理的ロケーション別で表示させるコンテンツを変更させたい場合や、アクセス元のIPによって表示させるコンテンツを変更したいなどが可能となる。
Amazon CloudFrontのキャッシュ削除
キャッシュクリアをしたい場合は、CloudFrontのコンソールを開いてInvalidationsタブを選択し「Invalidate」ボタンを押す。これは手動でしか方法がないのかな？
Amazon CloudFrontのオリジンサーバーのフェイルオーバー機能
CloudFront の Origin Failover の機能を使用すると、プライマリオリジンが利用できないことを CloudFront が検出した場合、セカンダリオリジンからコンテンツが提供されるように、プライマリとセカンダリの 2 つのオリジン を設定できます。
CloudFront では、カスタムエラーページを設定したり、オリジンを利用できない場合に Lambda @ Edge でリダイレクトを生成したりすることができるようになっています。
今まではRoute53でコントロールしなければならなかったけど、CloudFrontでも対応できるようになった。
プライマリとセカンダリに対して情報を設定して、プライマリがダメだったときにセカンダリを利用するようにできる。
[~.html?language=JP]のような末尾の国コードをどのように特定するのか
クエリ文字パラメーターの設定で可能。
ユーザが選択した言語に基づくクエリ文字パラメーターがセットされる。
クエリ文字パラメーターを使用することで、特定の言語ページをオリジンサーバーに転送して閲覧者に返すことが可能になる。
ナレッジQA
キャッシュしたファイルがエッジロケーション側にない問題
キャッシュしようとしたけど、全然エッジロケーション側にキャッシュされず毎回オリジンサーバーからデータを取ってきてしまう問題になる。
Cache-Control max-age ディレクティブが低すぎることが原因。
Cache-Control ヘッダーまたは Expires ヘッダーに設定したディレクティブが互いに矛盾していないことを確認してください。ベストプラクティスとして、Expires ヘッダーの代わりに Cache-Control max-age ディレクティブを使用してください。両方に値を指定した場合、CloudFront は Cache-Control max-age に設定した値のみを使用します。
CloudFront キャッシュ時間に関する問題のトラブルシューティング
オリジン側のS3を更新したのに古いバージョン使われちゃう問題
キャッシュコントロールヘッダでのキャッシュ保持期間がデフォルトの可能性がある（24時間）。
そのためオリジン側の情報を更新してもキャッシュの情報が変わっていない。
次のいずれかの方法で、CloudFront の更新された S3 コンテンツを CloudFront にプッシュできるようになります。
・S3 オブジェクトを無効にする。
・オブジェクトのバージョニングを使う
更新した Amazon S3 コンテンツを CloudFront からプッシュする
・S3 オブジェクトを無効にする
キャッシュからレスポンスを削除。キャッシュが削除されたので、次のリクエストではオリジンから取得するようになる。
・有効期限切れになる前に CloudFront エッジキャッシュからファイルを削除する場合、以下のいずれかの処理を行うことができます。
・エッジキャッシュからファイルを無効にします。ビューワーが次にファイルをリクエストしたときに、CloudFront はオリジンに戻ってファイルの最新バージョンをフェッチします。
ファイルの無効化 - Amazon CloudFront
ただしRTMPディストリビューションは無効にできない。
オブジェクトの無効化を完了するには、通常 60～300 秒かかるので注意。
・オブジェクトのバージョニングを使う
コンテンツを頻繁に更新する場合は、 オブジェクトバージョニングを使用して、CloudFront ディストリビューションのキャッシュをクリアすることをお勧めします。
頻繁にキャッシュを更新する場合、オブジェクトのバージョニングを行うことで、無効化するよりコストがかからない場合があります。
更新した Amazon S3 コンテンツを CloudFront からプッシュする
カスタムキャッシュがうまく機能しない問題
・ディストリビューションにそのカスタムキャッシュありますか？設定おかしくないですか？
例えば、キャッシュ動作の パスパターンが test/ に設定されていると、example.com/test/file1.jpg へのリクエストはデフォルトのキャッシュ動作に従います。
このリクエストは test/に指定された動作に従いません。 末尾のワイルドカード (test/*) が含まれていないパスパターンだからです。
CloudFront ディストリビューションがカスタムキャッシュ動作に追従しない場合のトラブルシューティング
ちゃんと設定しないと機能しない。
・大文字と小文字区別するよ
特定のファイルをキャッシュしたくない問題
カスタムオリジンウェブサーバーアプリケーションで、CloudFront にキャッシュさせたくないオブジェクトに Cache-Control no-cache、no-store、または private ディレクティブを追加します。または、CloudFront にキャッシュさせたくないオブジェクトに Expires ディレクティブを追加します。
CloudFront が特定のファイルをキャッシュしないようにする
http接続はうまくいくのにhttps接続はうまくいかない問題
オリジンがALB（CLB）を使用している。
CloudFront←→ALB間のHTTPS通信が失敗する。HTTPはうまくいく状態。
関連付けている証明書、セキュリティグループ、ネットワークアクセスコントロールリスト（ACL）の設定ミスによるものの可能性が高い。
HTTPS 通信の失敗は、関連付けられている SSL 証明書、セキュリティグループ、またはネットワークアクセスコントロールリスト (ACL) に関する問題が原因である可能性があります。使用しているディストリビューションとロードバランサーが次のセキュリティ要件を満たしていることを確認してください。
・ロードバランサーに有効な SSL 証明書をインストールしておく必要があります。SSL 証明書をインストールしてもまだ HTTPS エラーが発生する場合は、CloudFront とカスタムオリジンサーバー間の SSL 接続をトラブルシューティングします。
・CloudFront ディストリビューションがポート 443 でロードバランサーに接続する場合、ロードバランサーに関連付けられているセキュリティグループは、CloudFront IP アドレスのポート 443 でトラフィックを許可する必要があります。セキュリティグループの更新の詳細については、Classic Load Balancer のセキュリティグループの設定または Application Load Balancer のセキュリティグループを参照してください。
・ロードバランサーの Amazon Virtual Private Cloud (Amazon VPC) に関連付けられている ネットワーク ACL は、HTTPS ポート (通常はポート 443) で CloudFront からのトラフィックを許可する必要があります。
CloudFront ディストリビューションとロードバランサーオリジン間の HTTPS 通信の問題を解決する
有効なSSL証明書をインストールしている？、ポート443空けてる？
AWS Certificate Manager (ACM) でSSL証明書を更新したけど、反映されない問題
証明書の更新や再インポートのプロセスがまだ完了していない場合、CloudFront が引き続き以前の証明書を使用し続けることがあります。
また、証明書の更新や再インポートは非同期的に行われるため、CloudFront に新しい証明書が表示されるまで数時間かかることがあります
ACM と CloudFront で認証の有効期限切れの問題を回避する
Amazon CloudWatchについて勉強
AWS 認定ソリューションアーキテクト – アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書
- 作者: ??部昭寛,宮?光平,菖蒲淳司,株式会社ソキウス・ジャパン
- 出版社/メーカー: インプレス
- 発売日: 2019/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
- Amazon CloudWatchについて
- 監視間隔と収集データの保持期間
- CloudWatchのアクション系機能
- 監視関連サービス
- CloudTrail ログファイルを複数のリージョンから受け取る
- CloudWatch Logs
Amazon CloudWatchについて
AWS上で稼働する様々なシステムやAWSリソース情報を収集・監視・可視化するサービス。具体的にはCPU使用率が高くなったらAuto Scalingを起動してインスタンスを増やすなどができる。
AWSサービスに閉じるので、AWSサービス外の場合はZabbixなどで監視するのが良い。
CloudWatch上で取得・監視する項目をメトリクスという。
メトリクスには大きく分けて2種類存在する。
- 標準メトリクス
- カスタムメトリクス
標準メトリクス
AWSが提供しているデフォルトのメトリクス。主に以下4つ。- CPU使用率
- インスタンスストアボリューム（EC2に接続される揮発性のストレージ）からの（指定された期間での）読み取り回数
- インスタンスストアボリュームから読み取られたバイト数
- 全てのネットワークインターフェースから受信されたバイト数
カスタムメトリクス
標準メトリクス以外のメトリクスを独自に定義する。よく使われそうなメモリ使用量やディスク使用率は標準に存在していないので、カスタムメトリクスで定義する必要がある。
監視間隔と収集データの保持期間
無料課金の基本モニタリングと、追加料金が必要な詳細モニタリングが存在する。大きな違いは、EC2を監視する間隔。
- 基本モニタリング：5分間隔
- 詳細モニタリング：1秒間隔
ただし、EBSやELB、RDSは無料でも1分間隔が使えたりとまちまち。
収集データの保持期間はともに最大15ヶ月。
CloudWatchのアクション系機能
CloudWatchで監視している項目で何かが起きたときアクションする機能は大きく分けて2つ存在する。
- CloudWatchアラーム
- CloudWatch Events
この二つの大きな違いは監視対象。
CloudWatchはメトリクスだが、CloudWatch Eventsは状態変化などのイベント。
つまり、リソースを監視するのは同じだがトリガーとなるものが「ある閾値を超過するか」、「ある状態に変化した」で異なる。
CloudWatchアラーム
「CloudWatch」で監視している項目がある一定の値になった場合に、アラームとアクションを起動することができる。事前に指定した閾値を超えた場合に「SNSでメール通知」「AutoScaling連携」「インスタンスの動作（停止、再起動など）」が可能。
CloudWatch Events
「CloudWatch Events」で設定しているあるイベントをトリガーにアクションを実行する機能。EC2のインスタンス状態変化をトリガーに、主に、「Lambda関数の実行」や「SNSでメール通知」、「Kinesisストリーム」、「SQSキュー」などが可能。
スポットインスタンスが強制停止の状態に変化した場合、Lambdaで新しいスポットインスタンスを起動するなどが可能。
監視関連サービス
CloudTrail
AWSアカウント上で利用された操作（APIコール）をログとして記憶するサービス。AWSアカウントを取得した時点で有効化し、過去90日間のサービスに対する操作を表示する。
デフォルトで有効になっている。
VPCフローログ
VPC内のネットワークインターフェース間で行き来する通信の内容をキャプチャするサービス。CloudTrailとVPCフローログの違い
CloudTrail ログファイルを複数のリージョンから受け取る
複数のリージョンのログファイルを、1 つのアカウントの 1 つの S3 バケットに配信するように CloudTrail を設定できます。たとえば、S3 バケットと CloudWatch Logs ロググループにログファイルを配信するよう設定された証跡が、米国西部 (オレゴン) リージョン にあるとします。この証跡をすべてのリージョンに適用すると、CloudTrail はその他すべてのリージョンに新しい証跡を作成します。
CloudTrail ログファイルを複数のリージョンから受け取る - AWS CloudTrail
CloudWatch Logs
CloudTrailやVPCフローログなどのAWS上のログを統合的に収集するサービス。エージェントをインストールすることでAWS上のログだけではなく、LinuxなどのサーバーOSのログも収集することが可能。
CloudWatch Logs上のログの中からあるキーワードをフィルタし、存在する場合はCloudWatchアラームでSNSでメール通知を行うこともできる。
セキュリティグループとネットワークACLについて勉強
AWS 認定ソリューションアーキテクト – アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書
- 作者: ??部昭寛,宮?光平,菖蒲淳司,株式会社ソキウス・ジャパン
- 出版社/メーカー: インプレス
- 発売日: 2019/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
セキュリティグループとネットワークACL(アクセスコントロールリスト)の違い
共にファイアウォール機能だが、適用範囲やデフォルト動作などが違う。
セキュリティグループ
インバウンド・アウトバウンド別で以下3つの観点にて最大60まで生成可能。複数のセキュリティグループをひとつのEC2インスタンスへ適用できる。
セキュリティグループとネットワークACLを両方使用している場合の注意点
上記表の適用範囲上、ネットワークACLのほうがセキュリティグループより適用範囲が大きい。そのため気づかず接続できない場合がある。
接続できない場合は、セキュリティグループとネットワークACLのアクセス制御が以下になっているかを確認すること。
ステートレスとステートフル
以下サイトがわかりやすかった。
ステートレス
セッション情報を保持しないため、INとOUTで明示的に指定してあげないとINはOKだが、帰ってこれないみたいな状態になる。(サーバー側が)Stateをlessする（失う）みたいな覚え方をすることにする。
・メリット
・クライアントのリクエストは状態に依存せず、常にリソースに対する操作に必要十分な情報となる
・よってサーバーが増えてもそのままのリクエストでいつも同じリソースに対する操作ができる
・このためスケールアウトに向いている
・また処理がクライアントの状態に依らないので処理がシンプルになる
・デメリット
・やり取りが冗長になりがちである
・またリソースへの操作が必要になる度にそのやり取りを繰り返す必要がある
・これによりネットワークの帯域を消費し、処理も遅くなる
・サーバーが状態を保持していないのでエラーが起きたときのハンドリングが複雑になりがちである
ステートフル ステートレスとはどういうことか - Sojiro’s Blog
ステートフル
セッション情報を保持するため、明示的に指定しなくてもOK(サーバー側が)Stateをfullで持つみたいな覚え方をすることにする。
・メリット
・やり取りが完結に済む
・それによりネットワークの帯域を節約できる
・デメリット
・クライアントの状態を都度把握しておかなければいけないのでクライアントが増えると負荷も増える
・サーバーを複数台設置する場合にはそれぞれのサーバー間でクライアントの状態を同期しなければいけない
・これらの理由によりスケールアウトには向かない
ステートフル ステートレスとはどういうことか - Sojiro’s Blog
Amazon VPCについて勉強
AWS 認定ソリューションアーキテクト – アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
この本を一読したうえで機能単位で勉強していく。
- VPC(Virtual Private Cloud)とは
- VPCの作成イメージ
- CIDR(Classless Inter-Domain Routing)
- VPCエンドポイント
- VPN vs DirectConnect
- VPCピアリング接続 vs AWS Transit Gateway
- VPCエンドポイントを使ってS3に接続できない場合
- 踏み台サーバを使用したセキュアなリモートアクセス
- オンプレミス側との接続
- オンプレミス側との接続冗長化した高可用性を担保する
VPC(Virtual Private Cloud)とは
- AWS上にプライベートネットワーク空間を構築することが可能できる。任意のIPアドレスの範囲を選択することで仮想ネットワークを構築することができる。
- 論理的なネットワーク分離が可能。必要に応じてAWS内との接続やオンプレミスとの接続を実施することが可能。
- プライベートネットワーク空間内で細かく設定・制御できる。サブネットやルートテーブル、ネットワークゲートウェイ設定など。
- 様々な接続オプションを利用できる。インターネット経由 or VPN/専用線(Direct Connect)
冗長性や、セキュアな接続を担保しつつ、様々なところへ接続するために使用される機能という感じ。
VPCの作成イメージ
以下のような形でVPCを構築し、VPCの中にそれぞれ設定を実施していく。
AWS入門者向け 初心者が最初に理解すべきEC2とVPCの基本的な用語解説 | Avintonジャパン株式会社 より引用
手順としては以下のような形。
- VPCを作成
- Subnetを作成(Public or Private、もしくは両方)
- Subnetの中にEC2などのインスタンスを起動させる
- Internet GatewayをVPCにセットする（VPC←→インタネットができるように）
- ルートテーブルにPublicのIPを追加
- Private Subnetを作っている場合、NAT Gatewayを作成し、privateのインスタンス→インターネットができるようにする
ひとつのリージョンに対して、複数のVPCを設定できる（上限5）
ひとつのVPCに対し、複数アベイラビリティゾーンを設定できる。
また、ひとつのVPCに対し、複数サブネットを設定できる。
複数のアベイラビリティゾーンに対し、ひとつのサブネットがまたぐことはできない。
アベイラビリティゾーンは地域（リージョンよりも細かい）なので、1拠点につき1サブネットサブネットということか。
関連機能としては以下
サブネット
VPC内に構成するネットワークセグメント。サブネットは大きく分けて２つで構成することが可能。片方だけでも可。
- パブリックサブネット
- プライベートサブネット
この二つの違いはルーティング。
ルートテーブル内のデフォルトゲートウェイ（0.0.0.0/0）へのルーティングにインターゲットを指定したものがパブリックサブネット。
なければプライベートサブネット。
RDSなどマルチAZ機能があるものを利用する際には、異なるアベイラビリティゾーン上でサブネットを作成する必要がある。
パブリックサブネットはインターネットからの接続を許容する場合、フロントの画面などが該当する。
プライベートサブネットはインターネットからの接続は許容しないが、プライベートサブネットからパッチの入手などでインターネットへ接続したい場合に使用する。DBなどの情報がそちらに存在される。
インターネットゲートウェイ
VPCからインターネットへでるためのゲートウェイ。ルートテーブル
サブネット内の静的ルーティングを定義するもの。設定単位はサブネット。NATゲートウェイ
プライベートサブネットからインターネットに出るために実施する設定。サブネットにも記載したが、サブネットに紐づくルートテーブルにインターネットゲートウェイのルーティングが存在しないものが、プライベートサブネット
つまり単独ではインターネットに出ることができない。
プライベートサブネットにはDBサーバがあったり、誰かにアクセスされると非常に困るため。
プライベートサブネットからインターネットに出たい場合に使用するのが、NATゲートウェイ。
AWS側が用意しているNATゲートウェイの代わりにEC2インスタンスを代わりに使用することができる。（NATインスタンス）
高可用性なのはNATゲートウェイ。
CIDR(Classless Inter-Domain Routing)
同じネットワークとして扱うIPアドレスの個数を調整する。
https://wa3.i-3-i.info/word11989.html
172.31.0.0/16 の場合、
2進法で10101100 00011111 11000000 00000000となるが、16はネットワーク部をどこにするのかということを決められる。（この場合10101100 00011111 ）
これを実施することで、同じネットワークに所属するものが何かというものを決めることができる。
つまり、172.31.0.0/16と172.31.1.0/16は同じネットワークにいるといえる。
CIDRの数によって設定できるIPアドレスの数が異なるが、冗長性を考えて設定する必要がある。
VPCのCIDRは16が推奨されている。サブネットは24。
CIDRが16が65,536のIPを設定できる。
24は256、23が512、32が1。
VPCエンドポイント
VPCからリージョンサービス（S3など）を利用したい場合、VPCの外に存在するサービスに対し接続を行わなければならないので、インターネットの外に出てしまう。
それだとセキュアな接続にはならないので、インターネットに出ないようにするためにVPCエンドポイントを使用する。
https://devlog.arksystems.co.jp/2018/05/11/4896/ より引用
VPC エンドポイントでは、PrivateLink を使用する AWS サービスや VPC エンドポイントサービスに VPC をプライベートに接続できます。
VPC エンドポイント - Amazon Virtual Private Cloud
つまりインターネットを経由せずに接続することが可能。
デフォルトではIAM ユーザーにはエンドポイントを使用するためのアクセス権限がないので、IAMポリシーに権限追加する必要がある。
具体的には２つのつなぎ方が存在。
ゲートウェイ型
ネットワークレイヤー層のVPCエンドポイント。
ルートテーブルに指定されたターゲットを追加することでインターネットを経由せずにプライベート接続できる。
エンドポイントのIDと接続したいサービスのIDを設定することでアクセス制御が可能（
VPC エンドポイント - Amazon Virtual Private Cloud）
料金は無料で、AWS側にて冗長性を担保してくれているものとなる。
以下が使用できる対象。
- Amazon S3
- DynamoDB
S3とDynamoDBだけなので、SAAの試験でVPCエンドポイントの問題が出た場合、S3とDynamoDBのワード出てたら確実にゲートウェイ型。
インターフェイス（AWS PrivateLink）型
アプリケーションレイヤー層のVPCエンドポイント。AWS PrivateLinkとも呼ばれる。
APIコールに対してインターネットを経由せずにプライベート接続できる。
具体的にはVPC内サブネットのDNSに対して問い合わせを行うとプライベートIPアドレスで回答される。その情報でVPCエンドピントからAPIに対し転送が行われる仕組み。
ゲートウェイ型とは、Elastic Network Interface（ENI）を使用する点で違うので、そもそも転送する場所が違う（ゲートウェイはVPCからだが、privateLink型はサブネット）。
ENIのためアクセス制御はセキュリティグループを使用できるが、ENIを使用するために料金がかかる。
以下が使用できる対象。APIが存在する系のものには大体あるイメージか。
- Amazon API Gateway
- Amazon CloudWatch
- Amazon CloudWatch Events
- Amazon CloudWatch Logs
- AWS CodeBuild
- Amazon EC2 API
- Elastic Load Balancing API
- AWS Key Management Service
- Amazon Kinesis Data Streams
- Amazon SageMaker ランタイム
- AWS Secrets Manager
- AWS Service Catalog
- Amazon SNS
- AWS Systems Manager
- 他の AWS アカウントによってホストされるエンドポイントサービス
- サポートされる AWS Marketplace パートナーサービス
VPC エンドポイント - Amazon Virtual Private Cloud
VPN vs DirectConnect
VPCとの接続として、VPNを使用した接続と、DirectConnectを使用した専用線接続の2種類が存在する。VPN接続：バーチャルプライベートゲートウェイを利用したサイト間VPN
専用線接続：DirectConnectを利用した接続。安定しているので本番環境向け。日本では閉域性という点で利用される傾向がある。
VPCからオンプレミスを接続する場合は、必ずサブネットのルートテーブルに設定が必要。
VPN接続と専用線接続の違い
専用線接続は物理的に接続する準備しなければならないので、リードタイムがかかる。
データ移行などでリードタイムを気にする場合はVPN接続をするのが良い。
VPN接続は障害時の切り分けが難しかったり、ネットワーク品質に難がある。
それぞれの特徴については以下に記載。
VPN接続
いわゆるサイトtoサイトVPN（サイト間VPN）を指す。
単一および複数の Site-to-Site VPN 接続の例 - AWS Site-to-Site VPNより引用
ひとつのVPN接続はふたつのIPsec暗号化プロトコルで冗長化している状態。
専用線接続
AWSとオンプレミス側で専用線契約を結び専用線接続を実施する。
AWS Direct Connect とは - AWS Direct Connectより引用
接続はVPCに向けたプライベート接続と、S3やDynamoDBなどのAWSサービスへの接続としてパブリック接続がある。
サイト間VPNよりも一貫性があり、帯域のパフォーマンス向上、ネットワークコストも削減できる。
AWS Direct Connect Gateway は中国を除くAWSのすべてのリージョンにおいて、グローバル IP ルートを受信するパブリック仮想インターフェイスを作成することや、エンドポイントへのアクセスの有効化機能が提供されます。
また、複数の AWS リージョンに渡り Virtual Private Cloud (VPC) で接続性を確立することができ、それぞれ複数の BGP セッションを確立する必要がないので、管理作業を減らしネットワークデバイスへの負担も軽減することができます
AWS Direct Connect の AWS Transit Gatewayサポートが東京リージョンに対応しました | Amazon Web Services ブログ
AWS Direct Connect の AWS Transit Gatewayサポートが東京リージョンに対応しました | Amazon Web Services ブログより引用
複数のオンプレミスから複数リージョンのVPCに接続するためにはAWS Direct Connect Gatewayを使用することで可能。
ただし、VPC側は同一アカウントでなければらない点と中国には接続できない。
VPN接続と専用線接続の冗長化
VPNとDirectConnectを同じVGWに接続することができる。その場合はDirectConect側が優先される。
そのため、DirectConectはアクティブ、VPNはスタンバイにさせて、DirectConectが障害が起きた場合にVPNにするのがよい。
VPNにフェイルオーバーする際の注意事項として、接続回線が違うのでパフォーマンス懸念が発生する可能性がある。
VPCピアリング接続 vs AWS Transit Gateway
VPN間を通信する手段として、VPCピアリング接続 と AWS Transit Gatewayのふたつが存在する。似たような機能だが、若干違う。
VPCピアリング接続
異なるVPC間をプライベート接続するサービス。無料のサービスとなる。
VPC ピア機能とは - Amazon Virtual Private Cloudより引用
VPC ピアリングの基本 - Amazon Virtual Private Cloudより引用
通常はVPC間はそれぞれ独立したプライベートネットワークのため、通信を行えない。
VPCピアリング接続を行うことで、インターネット経由せずにAWSプライベートネットワーク内で直接通信することが可能。
リージョンをまたぐことも可能。日本<-->北米。
ただし、VPC-A<-->VPC-B<-->VPC-Cの場合、VPC-AはVPC-Aとだけ接続しているので、VPC-Cにアクセスすることができない。
ピアリング先のVPCを使ってインターネットに出ることはできない。
VPC-A<-->VPC-Bの場合、VPC-Aの中のサブネットがVPC-Bのサブネットからインターネットに接続しようとしてもそれはできない。
AWS Transit Gateway
VPCピアリング接続と大きく違うのは、オンプレミスとの接続も使用できるという点。ただし、VPCピアリング接続とは違い有料サービス。
VPC同士の接続のほかに、
という構成も可能。
DirectConnectGatewayのイメージは以下。
Direct Connect ゲートウェイへのトランジットゲートウェイアタッチメント - Amazon Virtual Private Cloudより引用
同じリージョンにある複数の VPN または VPC に対して 1 つの接続をAWS Transit Gatewayで管理する形。
VPCエンドポイントを使ってS3に接続できない場合
ネットワークアクセスまたは Amazon VPC から Amazon S3 への接続を許可するセキュリティルールが原因で、ゲートウェイ VPC エンドポイントとの接続問題が発生している場合があります。
VPC エンドポイントから S3 への接続問題のトラブルシューティング
- VPCでDNS設定が有効になっているか確認
- ルートテーブルをS3に設定（上記ゲートウェイ型の設定がされているか確認）
- 対象インスタンスのセキュリティグループのoutboundがS3を許可しているか
- ネットワークACLのinbound側がS3からのトラフィックを許可しているか
- VPCエンドポイントやS3へのIAMポリシーが許可されているか。（S3のバケットポリシー権限も含め確認）
テストの観点だと、ルートテーブルとセキュリティグループ、ネットワークACL、IAMポリシーが正しくないという理由で問題がでそう。
踏み台サーバを使用したセキュアなリモートアクセス
VPC内のEC2インスタンスに対し、リモートからセキュアにアクセスするために踏み台サーバを使用することができる。
踏み台サーバーを利用する理由はそれぞれの環境により異なりますが、以下が挙げられます。
1. セキュリティ的な観点
– 各サーバーに直接アクセスできないため外部から侵入されるリスクを軽減できる2. 運用的な観点
– パブリックIPを各サーバーに割り振る必要がないため運用不可を軽減できる
– 外部通信に対するアクセス制御の対象を踏み台サーバーに限定できるため運用不可を軽減できる
http://awsinfra.site/2018/05/17/post-14/
踏み台サーバ構成のポイント
- SSHやRDBなどリモートアクセスが必要な場合のみ、踏み台サーバを起動
- 踏み台サーバはパブリックサブネット上に設置し、パブリックIPを設定する
- 踏み台サーバのセキュリティグループはSSH・RDBからのアクセスを許可。アクセス元は不特定多数(0.0.0.0/0)ではなく、特定のIPにする
- 踏み台サーバから接続されるインスタンスには、必要に応じて「踏み台サーバからのSSHやRDBのみ許可」の設定をセキュリティグループにする
オンプレミス側との接続
Direct Connectと仮想プライベートゲートウェイ
Direct Connect
オンプレミス環境とAWSの間を専用線で接続するサービス。構想句なネットワーク帯域で安定した通信を実現可能。
オンプレミス側<-->接続ポイント<-->AWSで接続する。
接続ポイント<-->AWS側の可用性はAWSが提供するが、オンプレミス側<-->接続ポイントはユーザ側が考慮する。
オンプレミス環境とAWSの間をインターネットプロトコルセキュリティ (IPsec) VPN 接続するサービス。
各メーカーのルータに最適化された設定ファイルをAWSコンソールからダウンロードし、設定ファイルを元にオンプレミス側のルーター設定を行う。
専用線ではなく、あくまでインターネット回線を使用するので、速度や安全性がDirect Connectには劣る。
以下Direct Connect vs 仮想プライベートゲートウェイ
オンプレミス側との接続冗長化した高可用性を担保する
Direct Connect冗長化パターン
Direct Connectを2回線分用意することで、速度・安全性を維持したまま冗長化することが可能。ただし、コスト面が高くなる。
Direct Connect+仮想プライベートゲートウェイ複合パターン
Direct Connect側に障害が発生した場合、仮想プライベートゲートウェイに切り替える。仮想プライベートゲートウェイへフェイルオーバーした場合、通信品質やパフォーマンスに影響が発生する可能性がある。
なぜ自分は商品を購買してしまうのか『デジタルマーケティングの教科書―５つの進化とフレームワーク』を読んだ
主にデジタルマーケティングに関するプロジェクトにいることが多く、マルチチャネルなどのワードに触れることが多かったので、勉強のために読んだ。
この本はデジタルマーケティングについて、「環境分析」「消費者理解」「セグメンテーション」「チャネル」「プロモーション」などのワードをデジタルマーケティング前後でどう変わったのか、その変遷を記載してくれているので分かりやすく読み進めることができる。
今まで経験していた仕事でもよくチャネルが出てきていたので、チャネルとは何か、マルチチャネルとは何かということを理解できたし、購買行動についてよく話に出てきていた観点だったので勉強になった。
- 作者: 牧田幸裕
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2017/09/15
- メディア: 単行本
- この商品を含むブログ (1件) を見る
ただ、序章のこの先のデジタルマーケティングの未来想像に関するページは、最初に読むと敷居が高すぎるしポエムなので飛ばしていいと思う。
目次
序 章 20XX年のマーケティング―デジタルテクノロジーが実現する近未来第１章 デジタルマーケティングとは何か
第２章 従来型マーケティングの戦略策定プロセス
第３章 デジタルマーケティングの5つの進化とフレームワーク
第４章 マーケティングのキープレイヤーはどう変遷するか
第５章 デジタルマーケティング実践に求められる能力
デジタルマーケティングとは
デジタルマーケティングとは「データドリブン」と「オムニチャネル」。データドリブンとは、消費者理解と消費者へのアプローチを「勘」や「経験」ではなく、データに基づいて行う。
オムニチャネルとは、消費者と企業の接点であるECチャネルとリアル店舗をシームレスに統合し、消費者への購買の場を提供し、一方で、消費者購買行動データ取得の場とすることである。
シームレスとは、消費者から見てECチャネル（AMAZONなど)とリアル店舗の違いを認識・意識せずに一体的に利用できる状態。
このサイクルがデジタルマーケティングの根幹となる。
データドリブンによって商品やサービスをターゲット消費者へ認知させる
↓
消費者の購買前の行動データに基づいているので、興味・関心・欲求が醸成される
↓
購買
↓
購買データと購買後の消費者の評価データをもとに製品開発やサービス（新しい施策）開発の示唆を得る。
デジタルマーケティングの最終目標は消費者との関係性を深め、最終的に消費者のエージェント（代理人）になること。
評価データは、オムニチャネルとして、ECチャネルとリアル店舗から取得する。
じゃあどうやってデータドリブンする、つまり「勘」や「経験」ではなく、データに基づいて行うかというのかというと、ビッグデータだったりする。
仕事柄ビッグデータ分析用のデータレイク基盤を作っていることが多いが、大体はPOSデータが存在していることが多く、データ件数が一番多い。
1レシート単位で何を買ったかを1商品単位でレコードになっているからそりゃそうなんだけども。
POSデータには会員情報と紐づいていないものも多い。紐づいていないとそもそも上のサイクルに結び付けられないので、いかに会員情報とPOS情報を紐づけるのかというのが重要。
大体は会員カードだったりするんだけど、ECチャンネルで住所氏名年齢など消費者情報を入力していたり、購買履歴を持っていたりするので、それを使っている。
またGoogle Analitycsの情報などで、どこからアクセスしてきたのか、どのページに遷移していったのかなどを行動データをして持っている。
購買前の行動を分析いかに分析するのかというのがデジタルマーケティングのキモになってくる。
オムニチャネル
消費者と企業の接点であるECチャネルとリアル店舗をシームレスに統合ということだが、どこまでシームレスかっていうと、通常のユーザとして買い物している観点外の、在庫管理等のテクノロジーやサプライチェーン、ロジスティクスまで包含される。普段自分たちが、とりあえずアマゾンでポチるという行為がオムニチャネルの典型的パターンで、「消費者のエージェント（代理人）」となって商品を持ってきてくれる。
これをいかに自分の会社でやらせるかというのが、イオンでもセブンイレブンでもみんな同じようなサービスをやっている大本の理由だったりする。
サービスを利用してくれればしてくれるほど、会員の購買前行動を取得できるので、新しい製品やサービス（施策）開発がはかどる。
マーティング戦略の変遷
「環境分析」プロセス
⇒ターゲット消費者はだれなのか、製品・サービスの訴求ポイントの明確化
↓
「戦略立案」プロセス
↓
「戦略実行」プロセス
↓
「戦略管理」プロセス
⇒ターゲティングは適切だったか、競合製品・サービスの違いを消費者に適切に伝えられたか
このプロセスをPDCAのように回し続ける。
その中でも「戦略立案」プロセスは、さらに以下定義順で進んでいる。
セグメンテーション（市場細分化）
↓
ターゲティング（標的市場の選定）
↓
ポジショニング
↓
マーケティング・ミックス（製品戦略、価格戦略、チャネル戦略、プロモーション戦略）
従来型マーケティングの歴史
市場成長期（1960年、1985年）は需要量＞供給量。消費者へ製品を届けることが重要視されていた。この時期の買い物は、休日みんなデパートに出かけるというハレの日という扱いだった。
そこからコンビニエンスストアが誕生して、ユーザと店の距離感が近くなっていく。
市場成熟期（2004年、2007年）になると、需要量＞供給量となり、需要が伸び悩むようになる。
そこから顧客との関係性を重視し、需要を作り出すことがメインとなってくる。
〇「環境分析」プロセス
従来型の現状分析はPEST分析とSWOT分析がメイン。
PEST分析
政治的要因(Political)、経済的要因(Economical)、社会的要因(Sociological)、技術的要因(Technological)の頭文字を取ったもの。
マクロ環境の変化を網羅的に検討し、その変化が「自社の所属する業界」にどのような影響を与えるのかを明らかにするフレームワークであり、「変化」→「影響」→「成功要因の変化」となる。
上に書いている通り、あくまで「自社の所属する業界」に影響がありそうな事象をピックアップして分析する。
「変化」→「影響」→「成功要因の変化」を明らかにすることで、市場の脅威、機会を明らかにすることが、マーケティング環境分析の目的。
強み(Strengths)、弱み(Weaknesses)、機会(Opportunities)、脅威(Theats)の頭文字をとったもの。
SWOT分析を使うことにより、マーケティング戦略立案における環境分析ステップで、自社の環境要因を考える視点を提供できます。SWOT分析のやり方としては、SWOT=強み、弱み、機会、脅威の4つを組み合わせて分析することで、自社にとっての、市場機会や事業課題を発見します。
SWOT分析のやり方とコツ:環境分析から戦略目標を引き出す方法 | 英数字 | マーケティング用語集 | 株式会社シナプス
SWOT分析を行うことで自社が参入を検討すべき魅力的な市場を見つけることができる。
〇「戦略立案」プロセス
①セグメンテーション
セグメンテーションは同質と見なしうるセグメントに分解することを言う。ある市場をMECE（抜けもれなく）に、適正規模に分解する。
だが、MECEにとはいえ、完璧に同質に分解することはできない。
セグメンテーションの目的は競合企業としのぎ合いをしながら、それでも、その特定市場（セグメント）でビジネスを成長させること。
あくまで、自社がビジネスを継続、成長できるだけの規模ではければならない。
②ターゲッティング
セグメンメンテーションで分割しなかで、将来成長する・測定可能・達成可能なものを選択して、ターゲッティングする。
先細りの市場に目を向けてもだめだし、消費者のニーズが測定できなければ、競争力のある製品やサービスが提供できないし、成長しそうなセグメントでもハードルが高すぎて達成できなければ意味がない。
③ポジショニング
ターゲット消費者に自社の製品・サービスと競合企業の製品・サービスの違いを理解してもらい、自社の製品を選んでもらうための工夫である。
ターゲット消費者のニーズを把握し、そこから自社の製品サービスの強みを訴求ポイントを明確にするのが重要。
〇「環境実行」プロセス
マーケティング戦略が正しいのか、まずは仮説を検証する。
期間限定や店舗限定の商品を出すことでテスト・マーケティングを行う。ターゲット消費者に適切にプロモーションが届いているのか、それが理解されているか、購買されているか、想定していたチャネルに来店しているのか、価格、製品・サービス満足度など多岐にわたるテスト項目で検証をされる。
従来型のマーケティングの限界
消費者理解にしてもセグメンテーションにしても、消費者属性を把握するためにデータが限られていた。それは、消費者購買行動をデジタルデータで取得できず、アナログデータで取得していたから。
セグメンテーションにしても同質だろうという曖昧な状態でセグメンテーションするしかなかった。
そこから個々の消費者購買行動をデジタルデータでビッグデータとして取得できるようになって、消費者理解やセグメンテーションは変わっていく。
デジタルマーケティングでの変化
変化とはいえ、デジタルマーケティングは従来型マーケティングと別物ではなく、従来型マーケティングを包含するものである。環境分析の変化
マーケティング環境分析では、未来を定義することから環境分析を行う重要性を検討する。
従来型ではPEST分析とSWOT分析をフレームワークとしていた。
ただこれらは自社に関わる因果関係の太さを持つ根拠を元に結論を導き出していく。
つまり従来型は、「過去」の変化を重視して未来予測をするということになる。
行楽時期はいつもおにぎりが売れているから、今後も売れているだろうみたいなノリ。
現在のような世の中の技術的変化が大きかったり、連続性がない場合、過去の変化がないのでPEST分析とSWOT分析が機能しなくなる。
ではどう未来予測するのかというと、まずは未来を定義するという考え方。そのうえでどうしたらその未来に対して因果関係が強くなるのかを考えるのがデジタルマーケティングの環境分析となった。
消費者理解
従来型のAIDMAから、AISASやZMOTに移り変わる。
AIDMA（アイドマ）とは1920年代にアメリカ合衆国の販売・広告の実務書の著作者であったサミュエル・ローランド・ホールが著作中で示した広告宣伝に対する消費者の心理のプロセスを示した略語である。日本語圏において「AIDMAの法則」として、2004年に広告代理店の電通等により提唱されたAISASとの比較等で日本では知られる
AIDMA - Wikipedia
購買決定プロセスとして以下の流れで購買させるフレームワーク。
注目(Attention)
⇒顧客はまだ知らないので知ってもらう
↓
興味(Interest)
⇒知っているが興味を持っていないので、評価を育成する。
↓
欲求(Desire)
⇒興味はあるがほしいと思っていない。
↓
記憶(Memory)
⇒欲しいと思ったことを忘れている。記憶の呼び起こし。
↓
行動(Action)
⇒購入動機はあるが購入機会がない。機会を提供する。
このプレームワークはまだデジタル環境が存在しない1920年代に提唱されたものなので、検索→即購買という即時性が想定されていない、心理の変化と購買行動にタイムラグのあるフレームワークとなっている。
〇AISAS
AIDMAが登場したのは1920年代ですが、そこから70年以上が経過して新たなプロセスが誕生します。それがAISAS（アイサス）です。AISASは日本の広告会社である電通によって提唱されたモデルで、AIDMAをインターネットが普及した時代に適用できるよう発展させたモデルといわれています。
AIDMA・AISAS・SIPS｜マーケティングにおける購買行動モデルをおさらい | リクナビNEXTジャーナル
購買決定プロセスとして以下の流れで購買させるフレームワーク。
注目(Attention)
⇒顧客はまだ知らないので知ってもらう
↓
興味(Interest)
⇒知っているが興味を持っていないので、評価を育成する。
↓
検索(Search)
⇒購入前にgoogleなどで検索して商品やサービスについて事前調査を行う。
↓
行動(Action)
⇒購入動機はあるが購入機会がない。機会を提供する。
↓
共有(Share)
⇒購入した商品・サービスをブログやSNSなどで感想を投稿して情報共有する。
ここからわかるのが、製品やサービスに係る情報の入手が、検索サービスによって一瞬で可能になり、消費者が発信する口コミ情報が消費者の意思決定に大きな影響を与えているということ。
情報をどのようにして手に入れるかというのが、井戸端会議からインターネットへ。情報ソースの非属人化へ変化していった。
〇ZMOT
また、Gooleが提唱した意思決定プロセスのフレームワークとして、ZMOT（Zero Moment of Truth）もある。
「Moment of Truth(真実の瞬間)」が語源。
Moment of Truth（モーメント・オブ・トゥルース）とは直訳すると「真実の瞬間」で、顧客が企業と接点を持ち、購入の意思やブランドへのイメージを決定する瞬間のことを指します。
この「真実の瞬間」は誰もがインターネットを利用する現在では、顧客が来店などのファーストアクションを起こす前、つまりゼロの段階で起きているというのがZMOT理論です。
ZMOTとは？ GoogleのWebマーケティング理論をわかりやすく解説！
セグメンテーション
従来型マーケティングは市場に存在する不特定多数の消費者を、ニーズや特性別の集団に分ける。
具体的な手法は、地理的変数、人口動態変数、心理的変数、行動変数の4つである。
デジタルマーケティングでは、消費者をある程度の集団ではなく、「個」としてみる。
なぜなら、消費者それぞれで興味は別でその行動（購買）と心理（Google Analytics等での回遊情報）を、ユーザIDに紐づけて理解しようとするから。
プロモーション
従来型マーケティングはセグメンテーションでも書いたようにニーズや特性別の集団に分けていた。
つまりテレビ等でのマスプロモーションが主体だった。
需要＞供給の状況の時は、製品やサービスを市場に流すことが重要であり、視聴者に対しては認知が重要だった。
今は、供給＞需要のため、認知だけでは消費者は購買行動に移さない。
「興味、関心、欲求」の情勢をプロモーションすることが重要になった。One to Oneプロモーションに移り変わってきている。
どのように実施しているという点もセグメンテーションと同様、行動（購買）と心理（Google Analytics等での回遊情報）を、ユーザIDに紐づけている。
どうすれば組織で心地よく生きれるのか『Effective DevOps ―4本柱による持続可能な組織文化の育て方』を読んだ
DevOpsというワードを聞くときにいつも「DevOpsツール」という、CI/CDツールの話ばかりしているように思える。
だが、DevOpsは便利ツールであるというのは、枝葉のひとつでしかない。
仕事に対する個人の考え方を変え、仕事の多様性を尊重し、ビジネスが価値を実現するスピードを加速させる意識的なプロセスを支援し、社会的および技術的変化の効果を計測しようとしている。
DevOpsは思考の方法であり、仕事の方法である。
個人と組織が持続可能な作業習慣を生み出し、維持していくことを可能にするためのものだ。
今でいうところの働き方改革というワードの考え方に対してのひとつと考えても読める。
この本に書いていることはエンジニアに限った話ではないなと思えることが結構あった。
Effective DevOps ―4本柱による持続可能な組織文化の育て方
- 作者: Jennifer Davis,Ryn Daniels,吉羽龍太郎,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/03/24
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
個人の考え方という点でいうと、ミスした人が非難されて懲罰を受けるという環境は明解なコミュニケーションや透明性を阻むので、やるべきではない。
求められるのは、ミスした時に人が非難されるのではなく、失敗する何か原因（盲目的に守られている手順など）があるだろうシステムのもっと深いところにある問題としてとらえるかということ。
確かに、能力があってもミスはするし、失敗してしまうのは残業時間が多かったり、手順書などの不備などがある。
起こった問題を新しい学習機会、ヒューマンエラーをスタート地点とみて、どうしたらこの問題が突破できるのかをちゃんと共有されることによって、全体の意識が変わっていく。
- チーム内の透明性が増し、チーム内に信頼が生まれる
- 実際にダメージの大きいミスをする前に、それを防ぐ方法を同僚に伝えられる
- 新しい問題の解決に使える時間が増え、イノベーションが促進される
互いの信頼や、理解を求める人たちあろうというのがDevOpsで、それが構成されるチームがDevOps共同体となる。
結局DevOpsとは人に優しく、お互い（いろいろな職種や生活を超えて）に協力・協調しながら、仕事していこうということだと思う。
それだけどだと、当たり前なことを言っているわけだが、実際のところは仕事での立場や、その人が社会人になったときの当時の文化性などで変わっていく。
ドラマ『わたし、定時で帰ります。』であった、新人と就職氷河期の人間のすれ違いをDevOpsとしてはナンセンスとしている。
とはいえ実際問題、そういう話は文化として当人の知らぬ間に当たり前になっているので、意識の差は発生してしまう。
DevOpsのアンチパターン
非難文化
ミスが発生したときに、個人レベルでも組織レベルでも、人を非難し処罰しようとする傾向のこと。犯人探し。俺も遭遇したことがあるし、俺が新人だった時にテストの証跡取りは犯人探しが発生した際の対抗手段と聞いた。このマインドがそもそも非難文化を知らず知らずのうちに生んでいた。
非難されるのは誰だって嫌なので、ミスしないような動きがメインとなる。
そんな状態でみんな協力しようとか言われても、いやいやといってもミスったらディスって来るんでしょ？って言われて意に介してくれない。
サイロ
サイロとは- 同じ企業のほかのチームと知識を共有する気がないチームの空気を表している。
- サイロ化されたチームでは、目的や責任を共有せず、それぞれバラバラの役割を重視する。
- これに非難文化が結び付くと、自分の安定のための情報の抱え込みが起きる。
これはつまり自分のことしか考えない状況だと思っていて、チームや組織だけじゃなくて個人でもこのマインドになってしまうよなと。
自分の安定、自身の席を譲らないために情報をシャットアウトしてしまう考え。仕事をしていてちょいちょいいる人だと思う。
あなたが、仕事を辞めず永遠にその席に座り続ける気でいるのなら、それでいいのかもしれないけど……。
周りの人は結構困る考え方で、他の人が苦労しているのに傍観してる、嫌な奴だったりする。
DevOpsの４本柱
コラボレーション
コラボレーションは、複数で対話したり、教え合ったりすることを大切にしながら、特定の結果に向かってものを作っていくプロセスである。人間いろいろなバックボーンを持っている人がいるし、技術力だって違う。その違いを尊重しようという考え方。
そのいろいろな人の中で、共通のビジョンや目標も設けてそれに突き進んでいくのが共感や信頼を築くために必要。
じゃあ共感ってどうするのかっていうと、「話を聞く」、「質問する」、「他者の視点を想像する」、「個人的な違いを尊重する」の4点。
俺はあまり人の話を聞かず自分の意見を言う傾向があるので、以下は意識したい。
自分を落ち着けて強いて話に耳を傾けるように仕向け、相手が話し終わるのを待って、自分の返事を考えるようにしよう。
アクティブリスニングも優れたスキルだ。他の人が言ったばかりのことを反芻し、言い換えたり要約したりすることで、聞いて理解したことをがその人の意図にあっていることを確認するのだ。
こうすうと両者が同じ土俵に立って同じテーマについて話せるようになる。
信頼を育てるためには、「迅速な信頼」、「自己開示」、「信頼しつつ確認」、「公平と感じる環境」の４点が必要らしい。
迅速な信頼とは、最初から他人を信頼することが前提で、時間とともにその信頼が確かであったことを答え合わせする状況。
アフィニティ
個人の協力関係を育てて維持するに加えて、組織のチームや部門や業界全体でも関係の強さが必要になる。アフィニティとは、チーム間の関係を構築し、組織の共通目標を念頭に置いて個々のチーム目標の違いを乗り越え、共感を育て、他のチームの人たちからも学習するプロセスである。
ツール
DevOpsを加速させるためのツールエンジニアなので、outputはソースだったり製品だったりする。
開発、リリース、デプロイのリスクを低下させることができれば、もっとDevOpsを有効にすることができること。これが主軸ではない。
それが、リソースのバージョン管理だったり、テスト駆動開発だったり、継続的インテグレーション（CI）だったり、継続的デリバリー（CD）だったり継続的デプロイだったりする。
スケーリング
スケーリングは、組織がライフサイクル全体で導入しなければいけないプロセスや軸に重点を置いている。スケーリングでは、単に大企業でDevOpsに取り組む意味を考えるだけでは不十分だ。
組織の成長や成熟、縮小にあわせてほかの柱をどう適用すればよいのかも考える。
要は組織やチームが巨大化等スケールする場合に考えるべきことということ。
どうやれば社員が定着するのかっていうのもスケーリングの要素のひとつ。
報酬だったり、ワークライフバランスだったり、有給休暇だったり。ここが日本で言われている働き方改革の要素なんだろうなと思う。
燃え尽き問題
読んでいて一番気になった個所といえばこの問題。俺もちょいちょいあるんだけど、仕事の不安感や極度の疲労、自分自身に対する満足度の低下などから燃え尽きる、バーンアウトしてしまうことがある。
もう何もしたくない。自分を守る（下手したらサイロ化）してしまう行動を多くとってしまう。
短期的な対策としては
- 仕事関係のメールやチャットを見ない時間を確保する
- 事後とを人に任せたり、断ったりする
- プロの助けを借りる。精神的な健康は、肉体的な健康と同じくらい重要である
長期的な対策としては
- 個人の責任について、そこからくるストレスを軽減するためにできることを考える
- 燃え尽きかかっているときには、全体的なストレスや不快感といった形の兆候が出ている場合がある。自分で思っている以上にストレスや不安の大きな要因がないかどうかを考えてみるとよい
いい意味で自分の持ち物を整理して、自分でなくてもできるものは相手にお任せる考えが必要ということ。
そのためにはコラボレーションの「迅速な信頼」でこの人は信頼すると最初から決めてしまわないと、信頼できるかわかんねえしで自分の荷物でつぶれてしまう。
俺も自分の荷物を誰かに譲らない性格なので、誰かを信じるということが大切。
じゃないと、「仕事を辞めず永遠にその席に座り続ける気でいるのなら、それでいいのかもしれないけど……。」な感じになる。循環が必要。
小学生向けプログラミングコーチ感想
2月16日土曜日にボランティアで小学生向けプログラミングのコーチをしてきた。
今回の内容としては、以下のキットを使ったロボット作りがメインで、プログラミングはGUIで組み合わせる形。
GUIとはいえifやforを使うので、基本的な考え方を学べるかなと思った。
アーテック (Artec) アーテックブロック うきうきロボットプログラミングセット 076677
- 出版社/メーカー: アーテック
- 発売日: 2015/02/28
- メディア: おもちゃ＆ホビー
- この商品を含むブログを見る
事前に触らせてもらったけど、センサー類も結構あったり使いかたも簡単だった印象。コードをつなげて基盤にはめ込むだけ。
細かいところではつかえるアクチュエータが少なかったりするが子供に向けたツールとしては十分。
プログラミングのGUIもなかなかちゃんとしていて、実装を基盤に転送する際に、処理が通っていない実装をビルドしないようになっていた。
使っていて使いにくいなと思ったのは、センサー類の処理実装が、一度基盤とUSB接続しないと有効にならないこと。
使わないセンサーの処理を実装させないようにするってことなんだろうけど、分業できないので複数人で実施するにはちょっとつらいかなと。
当日の感じ
当日、俺が担当する子供は中学年2人と高学年1人の多学年混成チーム。3人は知り合いだったようだけど、知らないおっさん一人いるととっつきにくいかなと思って、アイスブレークとして積木式自己紹介を実施。
これで打ち解けてノーヒント好きなもの当てクイズみたいな、ハイレベルすぎるクイズが出題されて、これが小学生かーみたいな感じを受けた。
中学年の子供がちょっと落ち着きがなくて、キットのブロック遊びに終始してしまい、小学校の先生のドライブ力ってすごいなというのを理解した。
高学年の子は、もともと適正値が高いのかプログラミング的な思考や考える力がちゃんと備わっていて、if文に入らないのはなぜだや、やりたいことをどう実装するかをしっかり考えられている印象だった。
中学年と高学年たった数年の差だけどかなり違うんだなという感じだった。
成果物
うちのチームの最終成果物は、中学年の子供がどうしてもブロック遊びをやめなかったので、デザイン先行型のなんだがよくわからないオブジェが完成しただけだった。要件や設計をデザイナーが全部ひっくり返してくるチームビルディング失敗パターンな感じだったが、子供受けはすごくよかった。
人だかりはすごかったが、これは何を目的に作られたのという質問に何も返せない産物ではあった。芸術。
感想
別チームの人と話しても高学年は考える力がしっかり身についているという話だったので、高学年からプログラミングを勉強していっても考えられるし、論理的思考をしっかり学べるしいいなと思った。自分の子供が小学生になったときはプログラミング必修になるのでこういうツールを買い与えて色々触らせてあげるのも面白いかもしれないなー。
今はブロック遊びしかしないだろうけども。
