2021-06-17

AWSのRDSについて調べてみた。

AWS

f:id:overworker:20210304234231p:plain:h200

利用可能なデータベースエンジン
比較
- オンプレミス/RDB on EC2/RDSの比較
  - RDSのメリット
  - RDB on EC2のメリット
RDSの特徴
料金
AmazonAuroraの特徴

RDS関連の基本を調べてみました。

利用可能なデータベースエンジン

比較

`オンプレミス`/`RDB on EC2`/`RDS`の比較

検討項目	オンプレミス	RDB on EC2	RDS
アプリケーション最適化	必要	必要	必要
スケール	必要	必要	-
高可用性	必要	必要	-
バックアップ	必要	必要	-
DBバッチ適用	必要	必要	-
DBインストール	必要	必要	-
OSバッチ適用	必要	必要	-
OSインストール	必要	-	-
サーバー管理	必要	-	-
ラッキング	必要	-	-
電源・空調・ネットワーク	必要	-	-
立地・建物構造	必要	-	-

RDSのメリット

構築時のリードタイムが短い
スナップショット機能で簡単にバックアップ取得が可能
Multi-AZ構成をとることが出来る
メンテナンスウィンドウ時に自動でパッチを当てる事も可能

RDB on EC2のメリット

OSにログインする事ができる
RDSで提供されていないインスタンスタイプ/ストレージの利用が可能

RDSの特徴

メンテナンスウィンドウ

OSのメンテナンス
- 週１回、決められた時間にを実施する。
DBのマイナーバージョンアップ
- 自動適用を選択可能

スナップショット（バックアップ）

デフォルトで7日間の自動バックアップ（0日～35日間に設定変更可能）
手動スナップショットが可能

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

※ トランザクションログが保存されていることで可能になる。（トランザクションログはRDSの起動が完了したタイミングで自動で保存され始める。） - 自動バックアップを設定している期間内であれば、秒数まで指定して特定の時点のインスタンスを復元できる。 - 直近５分前に戻すことができる。

リードレプリカ

読み取り専用のレプリケーションを作成できる機能。
読み取り用途のアクセスをレプリカ側に対して実施することで、マスター（読み書き兼用）側への負荷を軽減することができる。
これによりマスターのパフォーマンスが向上する。
読み込みが多いアプリケーション等に有効。

注意：レプリケーションラグ

非同期なので、常にマスターと完全一致しているわけではない。

Multi-AZ

RDSのマルチAZ配置を有効化すると、アベイラビリティゾーンをまたいだレプリケーションが自動的に行われます。

フェイルオーバー

マスターとスタンバイの間でレプリケーションされ、マスターに障害が発生した際には自動的にスタンバイをマスターに格上げすること。

クロスリージョンリードレプリカ

他のリージョンにリードレプリカを作成すること

料金

サーバの稼働時間（時間単位）で請求が発生する。
スペック（エンジン、サイズ、メモリクラス）によって金額が変化する。
オンデマンドデータベースインスタンス（従量課金）とリザーブドデータベースインスタンス（前払い(割引あり)）がある。
- 全額前払い、一部前払い、前払いなしを選択可能
  - 全額前払いの場合、最大63%の割引
インスタンス数に応じ請求が発生する。

AmazonAuroraの特徴

無停止のままパッチ作業が可能
バックアップが強固
- 3つのAZに渡って6つのレプリケーションを作成する
- 継続的にAmazonS3にバックアップ
リードレプリカは15個作成可能
リードレプリカをフェイルオーバー可能（リードレプリカでセカンダリーデータベースの役割を兼ねることができる）
高い性能
- MySQLに比べ最大5倍の性能
- PostgreSQLに比べ最大3倍の性能
オートスケーリング
- インスタンス作成時にストレージサイズを指定する必要がない
- データベースインスタンスごとに最大64TBまで自動的にスケール

2021-06-06

小二の娘に「『県』と『府』はどうして違うの？」と聞かれたので調べてみた

開発以外子供の疑問

　少し前から、小二の娘が日本地図に興味を持ち始めたようです。きっかけは読める漢字が増えてきたコト、そして天気予報に表示される地名に読める漢字がそれなりにあるコトだと思います。天気予報以外でも新型コロナ関連のニュースは地名が登場することが多く、小二の娘の脳にはコロナ以前に育った子供とは違う刷り込みががされていそうだと感じています。

　そんな娘から、話の流れで「『府』ってな～に？」「『県』と『府』はどうして違うの？」と聞かれた時に、はっきりとした答えが返せなかったので、自分なりに調べてみました。

『廃藩置県』から調査開始！
- 廃藩置県後の府県の統廃合
『府』『県』の始まりは廃藩置県の前
「『県』と『府』はどうして違うの？」と聞かれたら！
- 日本史が多少わかる人には、、、
- 小二の娘に説明するには、、、

『廃藩置県』から調査開始！

　まずは日本史の授業で耳にしたことがある『廃藩置県』から調査をスタートしてみました。

廃藩置県（1871年）：藩を廃止して、その代わりに新政府直轄領の「県」を置いた。

　明治4年、明治政府が誕生したものの地方の政治はまだ地域ごとに存在していた藩が実権を握っていました（政治的には分権状態）。政府は国内を政治的にも統一するために、藩を統治していた知藩事（旧大名）を罷免させ東京居住を命じるとともに、明治政府から、府知事・県令を派遣し地方を府知事・県令を通して統治することで国の政治的統一を行うことを目指しました。

　廃藩置県当初は、３府・３０２県が置かれていました（現在の北海道を入れると１使・３府・３０２県になります）。「府」は東京府・大阪府・京都府の３つです。

廃藩置県後の府県の統廃合

　廃藩置県は当初３府・３０２県という、現在の都道府県数からはかけ離れた数からスタートしていますが、これは藩をそのまま県に置き換えたたためです。県の数はその後の短い期間でダイナミックに変化したようなので簡単にまとめてみます。

西暦	和暦	府の数	県の数
1871年8月29日	明治4年7月14日	3	302
1871年	明治4年10月～11月	3	72
1872年	明治5年	3	69
1873年	明治6年	3	60
1875年	明治8年	3	59
1876年	明治9年	3	35

1889年	明治22年	3府	42県 ※

※ 沖縄、北海道は廃藩置県の対象外

後は廃藩置県の詳細として『府』と『県』の違いを調べれば調査終了かと予想したのですが、、、

『府』『県』の始まりは廃藩置県の前

　調査を進める中で廃藩置県よりも前に府と県が存在していたことを知りました。

　1868年（明治元年）、明治政府は地方行政の単位を定める制度として府藩県三治制を定めました。この制度により日本国内は「府」「藩」「県」と言う3つで区分されました。

単位	説明	統治者
府	城代、京都所司代、奉行により統治されていた土地	府知事
藩	明治維新以前も藩として置かれていた土地	大名
県	府・藩以外の土地	知県事

　当初、江戸幕府から引き継いだ直轄領のうち、江戸（東京）、大阪、京都、箱館、越後（新潟）、神奈川、長崎、甲斐、度会、奈良を「府」と定めました。そして、最終的に廃藩置県の直前には府が3つ、県が40、藩が261となっていたようです。

西暦	和暦	府の数	藩の数	県の数	備考
1868年	明治元年	10	？	？	←府藩県三治制開始
1871年8月29日	明治4年7月13日	3	261	40
1871年8月29日	明治4年7月14日	3	-	302	←廃藩置県開始

「『県』と『府』はどうして違うの？」と聞かれたら！

日本史が多少わかる人には、、、

　府藩県三治制を踏まえて、

明治政府が地方行政の単位を定めるときに、重要拠点を府としたときの名残で府が残っている。

と言えばわかってもらえる気がします。

小二の娘に説明するには、、、

上記説明だと小二の娘には伝わらない気がするので、もう少しかみ砕く必要があるかな～。

昔、「地域のことはその地域のことをよく知っている人が決めた方が良いよね～」ってなったから、日本の中に線を引いて日本を分けたんだ～。その時に「分けただけで、名前が無いと色々不便だよね～」ってなったから、場所に対して名前を付けたんだ～。名前を付けるときに「重要な場所には、名前だけで重要場所だということが分かるように名前の最後に府ってつけようよ！重要じゃない場所には県ってつけようよ！」ってことにしたんだって！その時の名残で、当時重要だと考えられていた大阪、京都には今でも府がついているんだよ～。

これじゃ絶対に伝わらないですね。

2021-06-04

小二の娘に長さの単位を教えるために、いろいろ調べた

開発以外子供の疑問

小二の娘が算数のドリルで長さの単位変換（cm⇔m）でつまずいているので、正確に・わかりやすく教えるために単位について調べてみました。

調べたコト
- 国際単位系（SI）
小２に教えるための工夫
参考文献
- 産業総合研究所

調べたコト

国際単位系（SI）というものがあるらしい。

国際単位系（SI）

国際度量衡局（BIPM）・こくさいどりょうこうきょくというところが管理しているらしい
七つのSI基本単位という基本的な単位があるらしい
七つのSI基本単位は七つの定義定数という定義が前提に成り立っているらしい
七つのSI基本単位を組み合わせて表されるSI組立単位というものもあるらしい

七つの定義定数

定義定数	数値	単位
セシウムの超微細遷移周波数	9,192,631,770	Hz
真空中の光の速さ	299,792,458	m/s
プランク定数	6.626,070,15×10^-34	Js
電気素量	1.602,176,634×10^-19	C
ボルツマン定数	1.380,649×10^-23	J/K
アボガドロ定数	6.022,140,76×10²³	1/mol
視覚効果度	683	lm/W

七つのSI基本単位

量	名称	記号	定義
時間	秒	s	セシウム133原子の摂動を受けない基底状態の超微細構造遷移周波数を単位Hzで表したときに、その数値を9,192,631,770と定めることによって定義される
長さ	メートル	m	真空中の光の速さcを単位m/sで表したときに、その数値を299,792,458と定めることによって定義される
質量	キログラム	kg	プランク定数hを単位Jsで表したときに、その値を6.62607015×10^-34で定めることによって定義される
電流	アンペア	A	電気素量eを単位Cで表したときに、その数値を1.602,176,634×10^-19と定めることによって定義される
熱力学温度	ケルビン	K	ボルツマン定数kを単位J/Kで表したときに、その数値を1.380,649×10^-23と定めることによって定義される
物質量	モル	mol	厳密に6.022,140,76×10²³の要素粒子が含まれる。要素粒子は、原子、分子、イオン、電子、その他の粒子、あるいは粒子の集合体のいずれであっても良い
光度	カンデラ	cd	周波数540×10¹²Hzの単色放射の視感効果度Kcdを単位lm/Wで表したときに、その数値を683と定めることによって定義される

SI接頭語（20個）

指数表記	記号	数字
10²⁴	【ヨタ】(Y)	1,000,000,000,000,000,000,000,000
10²¹	【ゼタ】(Z)	1,000,000,000,000,000,000,000
10¹⁸	【エクサ】(E)	1,000,000,000,000,000,000
10¹⁵	【ペタ】(P)	1,000,000,000,000,000
10¹²	【テラ】(T)	1,000,000,000,000
10⁹	【ギガ】(G)	1,000,000,000
10⁶	【メガ】(M)	1,000,000
10³	【キロ】(k)	1,000
10²	【ヘクト】(h)	100
10	【デカ】(da)	10
		1

指数表記	記号	数字
		1
10^-1	【デシ】(d)	0.1
10^-2	【センチ】(c)	0.01
10^-3	【ミリ】(m)	0.001
10^-6	【マイクロ】(μ)	0.000,001
10^-9	【ナノ】(n)	0.000,000,001
10^-12	【ピコ】(p)	0.000,000,000,001
10^-15	【フェムト】(f)	0.000,000,000,000,001
10^-18	【アト】(a)	0.000,000,000,000,000,001
10^-21	【ゼプト】(z)	0.000,000,000,000,000,000,001
10^-24	【ヨクト】(y)	0.000,000,000,000,000,000,000,001

小２に教えるための工夫

一度国際単位系（SI）のことは忘れた方が良さそう。

参考文献

産業総合研究所

2021-05-30

AWS VPCあたりを調べてみた。

AWS

イメージ図
用語

AWS クラウド上にシステムを構成する際の、ネットワーク設定の基本を調べてみました。

イメージ図

f:id:overworker:20210530083946p:plain:w500

用語

VPC（Amazon Vertual Private Cloud）

AWSクラウド内に構築する、プライベートなネットワーク環境のこと
- 標準的なネットワーク構成の設定ができる
- ネットワーク構成やトラフィックを完全にコントロールすることができる

作成

選択したリージョン内に複数のAZ（アベイラビリティーゾーン）を横断して作成することができる。
IPアドレスの範囲をCIDR（Classless Inter-Domain Routing）で定義します。

サブネット

VPCで設定したアドレス範囲をサブネットに分けて定義します。
作成するときにアベイラビリティーゾーンのIPアドレス範囲を定義する。
- IPアドレス範囲はVPCで定義した範囲内で定義する必要がある。
- 同一VPC内のほかのサブネットと重複してはいけない。

以下はAWSによって予約されているIPアドレスです

IPアドレス	用途
..**.0	ネットワークアドレス
..**.1	VPC ルーター用
..**.2	AWSで予約
..**.3	AWSで予約
..**.n（最後）	ネットワークブロードキャストアドレス

サブネットの分割基準

インスタンスなどのリソースの役割に応じて分ける
- 特別な要件がない限り、以下の二つのサブネットに分割する
  - パブリックサブネット：インターネットに対して直接ルートを持つ
  - プライベートサブネット：インターネットに対して直接ルートを持たない

パブリックサブネット

インターネットゲートウェイへのルートを持つルートテーブルに関連付けられている
内部のインスタンスなどのリソースは、外部と直接通信ができる

プライベートサブネット

インターネットゲートウェイへのルートを持たないルートテーブルに関連付けられている
内部のインスタンスは外部アクセスから保護できる

サブネット間通信

各サブネットの間にはローカル接続のルートがある
- プライベートサブネット内のリソースはパブリックサブネット内のリソースと通信できる

インターネットゲートウェイ

VPCとパブリックインターネットを接続するためのゲートウェイ。
VPC1つに1つだけ作成可能。

ルートテーブル

サブネットの経路を設定するテーブル
サブネット内のリソースがどこに接続できるかを管理する

セキュリティグループ

仮想ファイアウォール機能
- VPC内のリソースのトラフィックを制御する
- 1つのセキュリティーグループを複数のインスタンスに設定できる

セキュリティグループの作成

VPCを指定して作成する
デフォルトではインバウンド（受信）のアクセスがすべて拒否
- 許可するインバウンドポートと送信元を設定するホワイトリスト
- 送信元にはCIDRか他のセキュリティーグループIDを指定する

ネットワークACL

サブネットに対して設定する仮想ファイアウォール機能
サブネット内のすべてのリソースに対してのトラフィックに影響がある
デフォルトですべてのインバウンドとアウトバウンドが許可されている
- 拒否するインバウンドポートと送信元を設定するブラックリスト

NATゲートウェイ（NATインスタンス）

VPC内に構成したプライベートサブネットからインターネットに接続するためのゲートウェイ
プライベートサブネットに配置したシステムが、これを経由することでインターネットに安全に出れるようになる

ダイレクトコネクト

AWSとデータセンターの間でプライベートなネットワーク接続を確立する
- 帯域を確保する
- セキュリティ要件、コンプライアンス要件を確保する

VPCピアリング接続

複数のVPCを接続する

2021-05-22

DWHが必要な理由を考えてみた！

運用

f:id:overworker:20210511193455p:plain:w500

疑問
データウェアハウスとは？
データベースとデータウェアハウスの比較
データ分析時の注意点
比較表
まとめ

ふと『なぜシステムでDBを持っているのに、わざわざDWHを持つ必要があるの？』と疑問に思ったので、データウェアハウス（DWH）の必要性について調べてみました。まだ使ったことがない人間の調査ですので、お気づきの点がございましたらコメント等いただけると助かります。

疑問

データベースとデータウェアハウスはどちらもデータベースですが、あえてデータウェアハウスを特別な呼び方で区別するのはなぜでしょうか？

データウェアハウスとは？

データウェアハウスとは履歴データの検索、分析、保管に特化した性能（機能）を備えたデータベースだと解釈しました。

データベースとデータウェアハウスの比較

一般的なデータベースは、データベースが接続されているシステムの目的を迅速に達成するために機能します。例えば会員情報を管理するデータベースであれば、会員登録（氏名、生年月日、連絡先）、会員情報の変更（住所変更等）、会員情報の取得（照会等）、会員情報の削除（退会）等の処理を迅速に実施することが必要になります。通常はデータベースに対し複数人が不規則なタイミングでアクセスすることが想定されますので、アクセス数が急激に増加したときなどにユーザーが不快な待ち状態にならないように準備しておきます。

これをデータベースの観点で考えるとトラフィックの最適化を目的に選定、設計されるのが理想になります。

一方、データウェアハウスは、システムを管理する人が意思決定のための情報を収集する際に機能します。例えば会員数の変化、年齢分布や男女比の変化、アクセスする曜日や時間帯の傾向、購買履歴など、管理者が取るべき行動を選択する際のヒントとして様々な情報が収集されます。そういった経営判断のための情報は一つのデータベース上にまとまっているわけではなく、複数のデータベースにそれぞれの情報に適したフォーマットで保存されています。意思決定者はそれらの分散した情報を直接的に参照するだけでなく、複数の情報に対し総合的・横断的に分析された結果を用いて意思決定を実施します。使われる回数はユーザー向けシステム程多くない可能性がありますが、ビジネス判断に必要となる情報を生成するために、情報の検索、分析を迅速に実施する必要があります。

これをデータベースの観点で考えると時系列データの検索・分析を目的に選定、設計されるのが理想になります。

また、一般的なシステムのデータベースは最新情報の管理が中心であるのに対し、データウェアハウスは主に時間変化を分析するための履歴（時系列）情報であるため、データウェアハウスに蓄積されるデータの量はデータベース上に記録される情報量よりも膨大になります。

データ分析時の注意点

データ分析時のデータアクセスが、ユーザーシステム側のパフォーマンスに影響を与えてはいけない。

比較表

	個別システムのDB	DWH
要求機能	トランザクションをコントロールする	時系列データの検索・分析
重視する点	システムの可用性等不規則に発生するDBへの入出力に対応する	検索・分析に対する処理速度
選定基準	選定基準が状況に応じ変化する - データの内容 - データサイズ - アクセス頻度	選定基準が変化しにくい - 検索処理速度 - 分析処理速度 - 価格

まとめ

それぞれの目的で収集された複数のデータを、総合的・横断的に分析しビジネス判断に活用することが求められている状況において、様々なデータを分析に適した形に変換・保存し実際に分析を実施する際に容易に取り出せるような環境としてデータウェアハウスは機能する。

2021-05-08

システムログを活用をするためのシステムとは？

運用

f:id:overworker:20210505101442p:plain:h200

課題
- 現状
アンチパターン
- 問題点
- 課題
改善提案（一般論）
よくある形
具体的なサービス

ログ活用のための仕組みに関して調べた時のノートです。
（きっかけは稼働ログをもっと活用するにはに記載させていただきました。）

ETLツール、DWH、BIツールという単語をこの調査で初めて知った程度のレベルです。
1日しか調べていないので、根本的に間違っているかもしれません。
お気づきの点がございましたらコメント等でご指摘いただけると幸いです。

課題

f:id:overworker:20210505112959p:plain:w500

現状

様々な場所に蓄積されている
データが格納されている場所ごとにデータフォーマットが異なる
それぞれの場所に格納されているデータの種類が不明確
データの可視化がされていない
用途に合わせたデータの加工が十分にできていない

アンチパターン

f:id:overworker:20210505113443p:plain:w500

『全てのデータに対応するモニターツール（Viewer）を開発する』のは現実的ではないと判断されている。

問題点

対象データが全く同じになるシステムは存在しないため、専用ツールとなってしまう
大量のデータを扱うため、Viewerが実施しなければならない処理量が非常に大きい
- 格納されているデータがのフォーマットが、ログ活用に向かない
- 処理量が多すぎてViewerとして機能しない
Viewerの数だけデータソースを直接読み込むプログラムが必要になる。
- Viewerが動作する際にデータソースを直接読み込むため、データソースへデータ登録を行うシステム側への影響が発生する
データソース側の仕様変更が、すべてのViewerに伝搬するため、メンテナンスコストが膨大になる。

課題

データ活用処理がメイン処理（データ格納側の処理）に影響を与えてはいけない。つまりメイン処理と疎結合のシステムである必要がある
応答性に優れたシステムである必要がある。
- データが要求されてからデータを作成するのではなく、あらかじめ必要になりそうなデータを用意しておく。
データ取得に対する学習コストが低い（標準的なフォーマットでデータが格納されている）。

改善提案（一般論）

f:id:overworker:20210505113742p:plain:w500

上記の課題を解決するために、一般的にはデータ解析専用のデータベースを用意することが多い

データ解析専用のデータベースには以下の特徴が必要になる

分析しやすいデータ
検索しやすいデータ

また、蓄積されたデータは時間毎に解析されることが多いので、時系列データとして扱われることが前提

時系列

上記システムで目的を達成するためには、データ解析専用のデータベース以外に、データベースへのデータ格納処理、データベースの可視化処理が必要になる。

一般的には、 データソースのことをデータレイク、データ解析専用のデータベースをDWH（データウェアハウス）と呼び、データベースへのデータ格納処理をETLツール、データベースの可視化処理をBIツールというツールで実施することが多い。

DB	（変換処理）	DB	（変換処理）	可視化
データレイク	→	DWH	→	ブラウザ
	ETLツール		BIツール

ETLツール

ETLツールとはExtract（抽出）、Transform（変換）、Load（書き出し）の先頭を集めた言葉で、複数のシステムからデータを取り出し、DWHへ受け渡す機能をもったツール。
場合によってデータレイクへ直接アクセスする必要があるので、メイン処理側への負荷を考慮する必要がある。

DWH（データウェアハウス）

ストレージの低価格化が進み、情報活用を目的としたデータベースを保持することのコストが低下したため、「DWH（データウェアハウス）」生まれた。 DWHは最初から「活用」を意識したデータの巨大倉庫です。目的が一つ（データ活用）なので、目的達成のために有効な仕組みがあらかじめ用意されている。 DWHは目的別にデータが並べられ、明細データをそのまま時系列で蓄積する。データの削除や更新も行わないため、膨大なデータを保持し続ける。

DWHには以下の特徴が必要になる

分析しやすいデータ
- 共通フォーマット：複数のデータレイクから集められたデータであるが、共通の方法でアクセスが可能
- 詳細データ：解析処理の軽微な変更に対して柔軟に対応ができるように加工前の詳細データが残っている
- 要約データ：あらかじめ目的毎に集計したデータが格納されている
- 時系列データ：時間変化が解析しやすい形になっている。
検索しやすいデータ

BI（Business Intelligence）ツール

DWHとETLによって集約されたデータの分析を分析・可視化を行う
目的に合ったデータの加工を実施する

よくある形

f:id:overworker:20210505115008p:plain:w500

ETL、DWH、BIはそれぞれ様々な製品が存在するとともに、それぞれのツールの機能範囲が重複しているため、境界をどこに設定するかはデータ活用基盤を作成するユーザー次第

ステージング層
- データレイクに負荷をかけないために、データレイクのレプリカを用意したうえで、レプリカに対してフォーマット変換やデータクレンジングを行う。
- ストレージの低コスト化により、Extract（抽出）、Load（書き出し）、Transform（変換）の順番で処理されることも増えてきた。
データマート層
- BIツールがデータ処理を行いやすいように、DWHに格納されているデータのサマリーをあらかじめ作成、管理しておく。

具体的なサービス

AWSを利用する場合

参考文献：Amazon QuickSight（あらゆるデバイスからアクセス可能な高速BIサービス）| AWS

ETLツール（DataGlue）

f:id:overworker:20210505152328p:plain:w500

BIツール（QuickSight）

方法１：QuickSight をオペレーショナルデータベース (Amazon RDS など) のデータに接続する

f:id:overworker:20210505151533p:plain:w500

方法２：QuickSight をデータウェアハウス (Amazon RedShift など) に接続する

f:id:overworker:20210505151713p:plain:w500

方法３：QuickSight をデータレイク (Amazon S3 など) に接続する

f:id:overworker:20210505151821p:plain:w500

GCPを利用する場合

ETLツール	DWH	BIツール
Dataflow	BigQuery	Looker

その他のサービスを利用する場合

複数のIaaSを想定した場合、データ活用の基盤を一つのIaaSに限定することは得策ではない。そのような場合に備えてIaaSに依存しないツールを選択することも考えられる。

ETLツール	DWH	BIツール
Fivetran	Snowflake	Tableau

2021-05-04

「無料版はてなブログ」で【Google AdSense】に合格！

はてなブログ

f:id:overworker:20210417082736j:plain:h300

概要
準備詳細
実際の申請手続き
- 私の時のメモ
申請後の作業

「無料版はてなブログ」でGoogleAdSenseが使えることを知ったので自分のブログにも導入してみました。導入まで、多少手間がかかりましたが最初だけだと思って頑張りました。

概要

はてなブログ内に成功体験がたくさん書かれていますので、それらを参考に以下の「１～４の作業」を行いました。

準備

１．プライバシーポリシーの設置
２．お問い合わせフォームの設置
３．Google searchConsole(サーチコンソール)へ登録
申請

４．実際の申請手続き

準備詳細

１．プライバシーポリシーの設置

`プライバシーポリシー`ってなに？

プライバシーポリシーとは、収集した個人情報を、サイト運営者がどのように取り扱うか記載したもの
無くても審査に通った人がいるらしいですが、あるに越したことはないので設置しました。

`プライバシーポリシー`の必要条件

内容が適切である
わかりやすい場所に表示されている（サイドバー）

内容の例

既に審査に合格している人のプライバシーポリシーをお手本に記載（コピペ＋自分用に変更）すればOKです。
当サイトのプライバシーポリシーはこちらです。
- 名前、URL等の部分を変更することを前提に、再利用（コピペ）OKです。

工夫したところ

プライバシーポリシーのみが記載された記事を作成しました。
どの記事からも確認しやすい、かつ分かりやすい場所にプライバシーポリシーを設置したかったので、サイドバーにカテゴリーを追加しておきました。
作成した記事（プライバシーポリシー）に対しカテゴリー：プライバシーポリシーを付加しました。

overworker.hatenablog.jp

２．お問い合わせフォームの設置

`お問い合わせフォーム`ってなに？

要は、「サイトや内容に対する問い合わせ」を受けとれるようにしておくことです。

`お問い合わせフォーム`の設置作業の手順