AWSのサービスを理解するーブロックチェーンカテゴリ編ー（前半）
AWSサービスを理解しよう！
何か久しぶりなような？AWSの製品一覧も日々更新されているようなので、それも見つつ１つ１つ書いて行こうと思います。今回は"ブロックチェーン"です。
カテゴリ：ブロックチェーン
AWSが提供するブロックチェーンサービスになります。今後なんですが、一度に書く分量も段々と増えて来ていることから前後半と分けて前半は其の物の内容説明、後半はAWSサービスの内容説明として行きたいと思います。今回は前半ということで、プロックチェーン自体についてまとめた内容を書いていこうと思います。では改めて、ブロックチェーンとは何なんでしょう？自分もいまいち分かってないので改めて調べてみました。
ブロックチェーンとは
取り合えずWikipediaの引用を載せときます。
ブロックチェーン（英語: Blockchain、ブロックチェインとも）とは、分散型台帳技術、または、分散型ネットワークである。ビットコインの中核技術（サトシ・ナカモトが開発）を原型とするデータベースである。
また、技術的概要でこんなことが書かれています。
ブロックチェーンは、「ブロック」と呼ばれるデータの単位を生成し、鎖（チェーン）のように連結していくことによりデータを保管するデータベースである。
正直、上の引用だと全然ピンとこなかったので、さらに調べたところ自分の理解は下のような感じでした。
- 分散型台帳技術＝ブロックチェーンではない
- ブロックチェーンは、分散型台帳技術を使った手法の一種
- ブロックチェーンは、データの持ち方としてブロックという単位でデータを持ちチェーンと言われるものでブロックを結んでいるのがブロックチェーンの特徴
文章で書くと分かり辛いので図に頼るとこんな感じです。
データの持ち方部分が、”手法の一種”として細分化されたところなのだと思います。
あとWikipediaの引用には『または、分散型ネットワーク』とありますが、分散型システムのネットワークは分散ネットワークなので紛らわしいからこの文章いらない感じがしました。
ここでは、分散ネットワークの話はちょっと置いといて、分散型台帳技術とブロックチェーンの仕組みの話を記載して本題のAWSサービスの話をして行きたいと思います。
分散型台帳技術
Distributed Ledger Technology (DLT)。データを不特定多数の場所で保管し特定の管理者なしに参加する人達が同じデータを共有する、分散して台帳（データ）を管理する技術。台帳と書いてあるのでついつい紙の売り買い帳簿を連想してしまうのですが、台帳＝データですね。もうちょっとイメージしやすいように例を箇条書きしてみました。
- まず、あるルールで定義した台帳*1を不特定多数の参加者が用意する
- 各参加者が台帳にデータを書き込む
- 各所にある台帳をPeer to Peerネットワークを使い共有
雑な言い方をすると、データを分散して持ちネットワークで共有すれば分散型台帳技術かなと。
ブロックチェーンの仕組み
『データをブロックという単位に分けてチェーンというもので繋ぐ技術』なんですが、ビットコインを例に少し具体的な内容で理解していこうと思います。
ビットコインは大きく分けて下の３つで構成されています。
ナンス値とは？
また新しい用語が出てきました。これはワンタイムトークンともいうんですが、簡単にいってしまうと”１回限定の使い捨てな値”です。ビットコインの場合は、ブロックが作られるたんびに毎回発行される３２ビットの半角数字となります。
この３つの要素（取引履歴＆前のブロックのハッシュ値＆ナンス値）からそのブロックのハッシュ値が生成され、そのハッシュ値が次のブロックに反映されてチェーンができ上がる。この仕組みがビットコインのブロックチェーンになります。
ビットコインには、もう１つ"マイニング"という重要なワードがあります。
マイニングとは？
マイニング（mining）直訳すると採掘ですね。この作業をして１番最初に正解にたどり着いた人には報酬が与えられることから、まさにお宝を採掘するという作業（処理）になります。具体的にどんなことを行うかを下に書いていきます。
マイニングは、新しくブロックを作成する権利を得るために、１番新しいブロックにあるナンス値がどんな値かを見るける作業になります。マイニングを行う人をマイナーと言いますが、マイナーはそのブロックのナンス値を世界で１番速く見付けるという作業をし、それが成功したら次の新しいブロックを作成して報酬をもらうという流れになります。
ナンス値はどうやって見付ける？
上の"ナンス値とは？"の部分でも書いたんですが、ビットコインは、３つの要素からハッシュ値が生成されます。そのハッシュ値には、"ある条件"がありマイナーはその"ある条件"になるようなハッシュ値を生成するためにナンス値をいろいろ組み替え、条件を満たすようなハッシュ値を世界で１番速く生成することができれば、成功となります。では、その”ある”条件"とは何でしょう？
"ある条件"＝採掘難易度
採掘難易度（Difficulty）とは、ビットコインの場合はナンスを見付ける難易度になります。この採掘難易度の計算方法については、数種類の方法があるようですがビットコインではPOWというアルゴリズムを使っています。
閾値の条件は、マイニングの作業が１０分に１回成立するような閾値を設けて、過去２週間の平均グロック生成時間が１０分より長いと閾値を下げて簡単にし、１０分より短ければ閾値を上げて難しくする。ということをしていて世の中のPCスペックが上がっても担保できる手法をとっているようです。
マイニングざっくりまとめ
ざっくりまとめると『マイニングの作業とは、この採掘難易度の閾値より小さい値のハッシュ値を探し出す作業』で、『成功すると報酬がもらえる！』となります。
条件に合うハッシュ値になるまでナンス値を組み換えまくる単純作業をPCは行っているわけです。
余談
もっと深掘りしたい人のためにちょっとキーワードを載せておきます。
コンセンサスアルゴリズム
上で、採掘難易度のアルゴリズムと書きましたが、正しく表現するとコンセンサスアルゴリズムと言うらしいです。そこでもうちょっと勉強したい人のためにキーワード情報を載せておこうと思います。
Consensus algorithm。直訳すると合意方法です。分散型台帳技術などのデータを分散させるような技術は、基本データを管理する管理者がいないため全体のシステムを担保するためそのデータが問題ないか合意を取る仕組みが不可欠になります。
管理者がいて管理者が「OK！」と言えばそれが"正しい行い"とみなされるんですが、この技術では管理者がいないので『これだけやれば、それは"正しい行い"だ！』と立証する方法を編み出した感じです。
手法は複数あるので、代表的なものを記載しておきます。
| 手法 | 利用している仮想通貨（抜粋） |
|---|---|
| PoW | BTC/BCH/LTCなど |
| PoS | ETH/ADAなど |
| PoI | XEMなど |
| DPoS | LSK/EOSなど |
| PoC | XRP/ZIPなど |
各種ブロックチェーン
ブロックチェーン自体にもいろいろあるみたいです。少し情報を載せておきます。
| 種類 | 管理者 | 承認権限 | 代表サービス |
|---|---|---|---|
| パブリック | なし | なし | Bitcoin |
| プライベート | 単独組織管理 | あり※ | mijin |
| コンソーシアム | 複数組織管理 | あり※ | Ripple |
承認権限とは、承認する人（団体・会社など）が存在するということで、プライベートは１人、コンソーシアムは複数人の承認者が存在するという意味です。パブリックの"承認権限：なし"は、参加するすべての人が承認者となります。
※．"承認権限：あり"のブロックチェーンは、パーミッション型ブロックチェーンと呼ばれています。
最後に一言
毎週アップが難しくなりつつある＆ちょっと長ったらしくなって来た感もあるので、今回みたいに切り分けられるところがあれば切り分けてアップしたいと思います。なので、次はブロックチェーン後半です。
それでは、今回はここまで！
ShiftItアプリをmacOS Mojaveで使用する方法
ShiftItで警告みたいなのが出るようになった
皆さんmacでウィンドウ分割って何を使っていますか？最近（OS X EI Capitan以降）は、Split Viewなんて機能も標準装備されているんですが、Split Viewは3分割・4分割できないので自分は時と場合によってShiftItとSplit Viewを使い分けています。ただどうも32bit版を使い続けていたようでこの前OSをアップデートした中で『これ64bitツールじゃないよ！』といった感じの警告が出るようになり気持ち悪かったので、64bit版を入れ直したんですがちょっと手順が必要だったのでここに残しておこうと思ったしだいです。
ShiftItとは
macで一番有名（だと思ってる）ウィンドウ分割ツールです。以前使っていた"公式版"はいつの間にか終了しているらしく今はMike's Versionさんがその後を引き継いでるとのこと、引き継がれたソースはgithubにて公開されているので、こちらを使わせていただく形で最新化したいと思います。
ShiftIt導入手順
導入自体は、サクッといけるんですが、"アップデートの確認"を使う場合ちょっとした対応が必要になるので、そこも含め記載して行こうと思います。
１. shiftItをダウンロード
Mike's Versionさんのgithubサイトから"Latest release"のzipファイルをダウンロードします。
上のリンクからgithubのreleasesページを開きます。開いたら"Latest release"を探します。2019年4月16日現在1.6.6が"Latest release"になります（①の部分）。
"Latest release"を見つけたら②の部分のShiftIt-1.6.6.zip（バイナリファイル）をダウンロードします。（時期によってバージョンが違うので"Latest release"下にあるShiftIt-X.X.X.zipをダウンロードして下さい。）下の"Source code"はソースをそれぞれzip圧縮とtar.gz圧縮*1で用意されているのですが、アプリを使用したいだけであれば関係ないので無視して貰って大丈夫です。
２. shiftIt-X.X.X.zipを解凍
ダウンロードしたshiftIt-1.6.6.zipを解凍します。（ダブルクリックすれば解凍できると思います。）解凍するとShiftIt.app（
）ができます。
３．アプリケーションフォルダに移動
解凍してできたShiftIt.app（）をアプリケーションフォルダに移動させます。
４. 起動の前にロックを解除
移動させたShiftIt.appをダブルクリックすると下のようなメッセージが出ると思います。（でない場合は問題ないので５に進んじゃって下さい。）
ShiftIt.app”は、開発元が未確認のため開けません。
メッセージが出てしまった場合、前に"Caffeine"の時にも書かせて貰った理由と同じ理由で"ShiftIt"もロックを解除しないと使用することができません。
"Caffeine"時と同じ操作になりますが、"ShiftIt"のロック解除手順も記載しておきます。
メニューバーのリンゴマークから"システム環境設定"を開きます。開いたら"セキュリティとプライバシー"を選択します。
③の"プライバシー"タブを選択、④の"アクセシビリティ"を選び⑤の鍵を外して⑥の"ShiftIt.app"にチェックを入れて⑤の鍵を戻して完了です。
それでもメッセージが出て実行できない場合は"セキュリティとプライバシー"の一般タブ（⑦）も確認してみて下さい。
⑨の"ダウンロードしたアプリケーションの実行許可"を見て、もし"App Store"が選択されていた場合は⑧の鍵のロックを外し"App Storeと確認済みの開発元からのアプリケーションを許可"を選択して⑨の鍵をロックして完了です。
５．常駐設定
移動させたShiftIt.appをダブルクリックするとメニューバーに登録されるので、これで起動完了です。そのまま常駐させたい場合はメニューバーにあるShiftItアイコン（
）をクリックするとメニューが表示されます。
そのメニューから環境設定を選ぶとShiftItの環境設定画面がでるので、その中にあるログイン時に開くにチェックを入れておくと再ログインしてもログインしたタイミングで起動されるので常に常駐されるようになります。
ShiftItアップデートの確認でエラーがでる方へ
新しいShiftItはアップデートの確認ができるようになりました。（昔からだったらごめんなさい。）
ただ自分の場合、”アップデートの確認”をクリックしたところエラーになってしまいうまくアップデート確認できなかったので、その時自分が解決した対応方法を記載しておきます。
ShiftIt.appの属性を確認
まず、ShiftIt.appの属性を調べたいのでターミナルアプリを立ち上げます。
control + space
上のショートカットを実行すると"Spotlight検索"が立ち上がるので、そこに"ターミナル"と打ち込んで、ターミナルアプリを立ち上げて下さい。
ターミナルアプリを使いcdコマンドを実行してShiftIt.appの置いてある場所に移動します。（今回の場合、アプリケーションフォルダに移動想定で話を勧めます。）
cd /Applications
cdコマンドにて移動したらlsコマンドでShiftIt.appの属性を確認します。
ls -ld ShiftIt.app
drwxr-xr-x@ ShiftIt.app
@が付いていれば自分が対応した方法でエラーがでなくなると思います。
属性の@って何？
自分も知らなかったので調べました。拡張属性らしいです。似たもので"+"があってそれは拡張セキュリティ情報（ACL*2）とのこと、今回は拡張属性を掘り下げます。
拡張属性とは
extended attribute（EA）。通常の基本属性（種別*3+パーミッション、所有者、所有グループ、ファイル名など）とは別に拡張された属性で名前空間識別子という名前空間に情報を付与することができるようです。
名前空間識別子
拡張属性には、user, trusted, security, systemという名前空間があり、それぞれ下に書いた内容でルール化されているようです。
| 識別子 | 内容 |
|---|---|
| user | ユーザー用（自由に設定可能） |
| trusted | スーパーユーザーのみが利用可能 |
| security | カーネルが使用 |
| system | カーネルが使用 |
使用用途として、通常ユーザーはuserの領域を使用して例えばFinderに表示されないように設定など、基本属性ではできない設定を行い使用しているみたいですね。
本題に戻るんですが、拡張属性*4はxattrにて確認や属性の付与、削除ができます。今回の場合はこんな感じで確認できます。
xattr ShiftIt.app
すると、com.apple.quarantineと表示されるんですが、どうもこの設定が悪さをしているようなのです。この設定はセキュリティの一貫で、何気なくファイルを実行してしまってウィルスやマルウェアに感染するのを防止するため『開いてもよろしいですか？』と注意喚起してくれる設定になります（だいぶザックリ(^^; ）。なので通常であれば悪いことは無いんですが今回のような一度信用したアプリの最新確認をするのに一々この設定に引っかかりエラーになるというのもちょっとな感じがするので、今回はこの設定を消してしまいます。
拡張属性（user空間の情報）を消す方法
だいぶ長くなってしまいましたが、これを実行することで今回の"アップデートの確認"ができない問題は解決です（自分はこれで解決しました）。
xattr -dr com.apple.quarantine ShiftIt.app
オプションについてディレクト内を再帰的に削除したいので-drを指定しています。
上の拡張属性削除コマンドを実行後、もう一度ls -ld ShiftIt.appを実行してみて@が消えていればOKなので、この状態で"アップデートの確認"を実行してみて下さい。
これがでれば成功です。
余談 xattrのオプション
-l で詳細情報も表示
xattr -l ShiftIt.app com.apple.quarantine: 0081;5cb4bdb2;Chrome;4BCF018E-A807-45C7-A6C5-57402FB69627
-p + <拡張属性名>で詳細情報のみ表示
xattr -p com.apple.quarantine ShiftIt.app 0081;5cb4bdb2;Chrome;4BCF018E-A807-45C7-A6C5-57402FB69627
最後に一言
どうでしたか？ShiftItを新しくするだけだったんですが、いろんな情報てんこ盛りで自分も意外に勉強になりました。次回はそろそろAWSサービスの続きを書こうと思ってます。
それでは、今回はここまで！
HTTPとHTTPステータスコードのお話
- HTTPとHTTPステータスコード
- 1xx Informational 情報
- 2xx Success 成功
- 3xx Redirection リダイレクション
- 4xx Client Error クライアントエラー
- 5xx Server Error サーバエラー
HTTPとHTTPステータスコード
前回、リダイレクトとHTTPステータスコードの話を書かせて貰いましたが、改めてHTTPとHTTPステータスコードとは、という内容も残して行うと思います。
HTTP
Hypertextとは、"テキストを超えた文章"らしいです。今更なんですが、なんじゃそりゃ(^^;という感じなのでもうちょっと具体的な例を上げると、リンクや画像表示・映像などを結び付ける。ただ文章を表示するだけじゃなく別の所にある"何か"を文章内に表示（結び付ける）ことができるものはHypertextらしいです。そして"相互に結び付ける"には通信（転送）する必要があり、その通信にはお約束ごとが必要になるんですがそのお約束ごとがHTTPというルールになります。
- HTTP(Hypertext Transfer Protocol)
- ハイパテキスト転送プロトコル
- Hypertext
- 複数の文章や画像・映像などを相互に結び付けるテキストの仕組み
- Protocol
- 手順、規約、お約束ごと、ルール
HTTPステータスコード
ハイパテキスト転送のルールに沿っているか？沿っていないか？の状態をお知らせしてくれる値です。前回のリダイレクトの時にも書いたように3桁の数字でその時の状態をお知らせしてくれます。
- ステータス (status)
- 動作状態。その時の状態をお知らせしてくれる値ですね。
- コード (code)
- 符号。ルールに基づいた値です。HTTPステータスコードの場合は、3桁固定の数字。
HTTPステータスコードの分類
このステータスコードにはもちろんなんですが、ちゃんとルールがあって大分類として3桁数字の先頭数字が1〜5で分類されています。具体的にはこんな感じです。
- 1から始まるステータスコード：1xx Informational 情報
- 2から始まるステータスコード：2xx Success 成功
- 3から始まるステータスコード：3xx Redirection リダイレクション
- 4から始まるステータスコード：4xx Client Error クライアントエラー
- 5から始まるステータスコード：5xx Server Error サーバエラー
1xxは継続して処理させる時に返すステータスコードなので自分的にはあまり見かけない印象です。それ以外はプログラムに詳しくない方でもホームページ上に表示されちゃっている（よろしくない！）のをたまに見かけることがあったりするんじゃないでしょか？
大分類の中にそれぞれ具体的なルールとそれに対応する3桁数字が割り振られているので、抜粋になってしまうんですが、それぞれの詳細情報を下に載せて行こうと思います。
1xx Informational 情報
リクエストは受け取られた。処理は継続される。
何かしら送信して貰った時に、受けてが『処理中なのでちょっと待って！』という時や『こっちにして！』という時に返すステータスコードです。
| コード | 用語 | 内容 |
|---|---|---|
| 100 | Continue | 継続。クライアントはリクエストを継続できる。サーバがリクエストの最初の部分を受け取り、まだ拒否していないことを示す |
| 101 | Switching Protocols | サーバがリクエストに対してプロトコルの切替えを要求している |
| 102 | Processing | リクエストは受理されたが、処理は完了していない（処理中である） |
2xx Success 成功
リクエストは受け取られ、理解され、受理された。
何かしら送信して貰った時に、それが成功した『ちゃんと表示された！』『ちゃんと処理された』時に返すステータスコードです。
| コード | 用語 | 内容 |
|---|---|---|
| 200 | OK | リクエストは成功 |
| 201 | Created | リクエストが完了し、新たに作成されたデータのURIが返される |
| 202 | Accepted | リクエストは受理されたが、処理は完了していない |
3xx Redirection リダイレクション
リクエストを完了させるために、追加的な処理が必要。
自分的な解釈になってしまいますが、"あっち"から"こっち"に移動する時のステータスコードだと思ってます。
| コード | 用語 | 内容 |
|---|---|---|
| 301 | Moved Permanently | リクエストしたリソースが恒久的に移動されている時に返される |
| 302 | Found | リクエストしたリソースが一時的に移動されている時に返される |
| 307 | Temporary Redirect | リクエストしたリソースは一時的に移動されている時に返される*1 |
| 308 | Permanent Redirect | リクエストしたリソースは恒久的に移動されている時に返される*2 |
4xx Client Error クライアントエラー
クライアントからのリクエストに誤りがあった。
クライアントとはこっち側。即ち自分が送っている情報が間違っている場合に返ってくるステータスコードです。（ありえないURIとか指定すると403とか404とかブラウザ上で見れちゃうページが結構あるので、これが一番分かりやすいかも）
| コード | 用語 | 内容 |
|---|---|---|
| 400 | Bad Request | クライアントのリクエストがおかしい場合に返される |
| 403 | Forbidden | リソースにアクセスすることを拒否された*3 |
| 404 | Not Found | リソースが見つからなかった*4 |
| 405 | Method Not Allowed | POSTが許可されていない場所でPOSTすると返される |
5xx Server Error サーバエラー
サーバがリクエストの処理に失敗した。
サーバとありますが、アプリケーションサーバがアプリケーションの処理を解釈できずに失敗として返すと書いた方が理解しやすいですかね。どんなWebサービスでもいいんですが（ECでもブログでもSNSでも）表示させるためにhttpサーバがあり、処理する（書き込んだ物を登録して表示させたりなど）ためにappサーバがあります。5xxは、処理が失敗した時に返ってくるステータスコードです。
| コード | 用語 | 内容 |
|---|---|---|
| 500 | Internal Server Error | サーバ内部(アプリケーション)にエラーが発生した場合に返される |
| 502 | Bad Gateway | ゲートウェイ・プロキシサーバが拒否した場合に返される |
| 503 | Service Unavailable | アクセスが殺到して処理不能に陥った場合に返される |
| 504 | Gateway Timeout | ゲートウェイ・プロキシサーバが相手サーバからのレスポンスがなかった場合に返される |
| 505 | HTTP Version Not Supported | リクエストがサポートされていないHTTPバージョンである場合に返される |
どんなものがあるか何となく感じとって貰えたでしょうか？上に書かせて貰ったのは本当に一部なので詳しくはWikiをご確認ください。
書いてみて改めて思うこと
正直、基礎の基礎なんですが改めて確認してみると分かっていない部分が結構あり自分がいかに中途半端な情報でここら辺のコードを扱って来たかが分かった気がします。実はRestAPIを自前で作成する時のレスポンスコードなどを考える時に重要になってくるので、『こんなの』とは思わず皆さんも今一度見返してみて貰えたらと思います。（おろそかにしてたの、自分だけかも (｡>﹏<｡) ）
ということで今回はこの辺で！
リダイレクトとHTTPステータスコードのお話
リダイレクトでの注意点を書き残す！
前回、AWSの費用まわりであまりの複雑さに知恵熱が出そうだったので、ここで少し骨休みを！ちょっと前にリダイレクトとHTTPステータスコードで「へー」と思ったことがあったのでここに残しておこうと思ったしだいです。
リダイレクト
ご存知リダイレクト。どっかのページに転送する時は皆さん使っていると思います。意外にどこにでも書けるので、使い勝手がいい半面あっちゃこっちゃで使うと想定と違う動きをしてしまいハマりまくるという経験をするので注意が必要だったりします。
こんなところに書いて飛ばしますよね。
- httpサーバ (apache, nginxなど)
- appサーバ (tomcat, unicornなど)
- view (html, javascript,など)
HTTPステータスコード
HTTPステータスコードは3桁の数字でその時の状態をお知らせしてくれます。
リダイレクトとHTTPステータスコードの注意点
さて、こっからが本題です！HTTPはリダイレクト用として3xxのステータスコードを用意していて、リダイレクト設定する時は、この3xxを指定してリダイレクトを使います。ただこのステータスコード何も考えずに指定すると後々厄介な目にあったりするのです。ここではそれぞれの特徴と"何が厄介か？"として注意点を載せて行こうと思います。後おまけで、雑な感じなんですがnginxの設定例も載せときます。
301リダイレクト
HTTPステータスコード301を使用しリダイレクトを行う方法です。特徴と注意点はこんな感じでしょうか？
301の特徴
- 恒久的に移動したい場合に使用します
- GETにてリクエストを行う
完全に別の場所に移住する時に使用するリダイレクト方式です。
301の注意点
- 転送先がindexされやすいです
- 転送先のページがブラウザにキャッシュされます
上の注意点はやっかいなのでコード指定は慎重に、何が厄介かというと一定の期間だけ転送先にリダイレクトしたい時に301を使ってしまうとその一定期間が終わってリダイレクトの設定を解除してもGoogleなどの検索には転送先が引っかかり、転送元を表示しようとするとブラウザキャッシュで転送先が表示！なんて現象がおきてしまいます。
一応Chromeだけですが、キャッシュクリアの方法も載せときます。
- Ctrl + Shift + Delete
- 期間：全期間
- キャッシュされた画像とファイルにチェック（それ以外はチェック外しとく）
- 『データを削除ボタン』を押す
nginxの設定
rewriteを使うとこんな感じですね。www.example.comが転送元で、www.redirect.comが転送先です。
server {
listen 80;
server_name www.example.com;
rewrite ^(.*)$ http://www.redirect.com$1 permanent;
}
公式ではreturnを推奨しているとのことなのでそちらも載せときます。
server {
listen 80;
server_name www.example.com;
return 301 http://www.redirect.com$request_uri;
}
302リダイレクト
HTTPステータスコード302を使用しリダイレクトを行う方法です。こちらも特徴と注意点を書いていきます。
302の特徴
- 期間限定（一時的）に移動したい場合に使用します
- GETにてリクエストを行う
一時的な移動の場合は、302を使用します。
302の注意点
- 転送元がindexされやすいです
- ブラウザにキャッシュされないようです
恒久的な移転なのに302を指定していたりするといつまで経ってもGoogleなどの検索に転送元が引っかかったり毎回ブラウザの読み込みに時間がかかったりといった悲しい現象がおこったりします。
nginxの設定
301リダイレクトと大差ないんですが、こちらもrewriteとreturn二通り載せておきます。
server {
listen 80;
server_name www.example.com;
rewrite ^(.*)$ http://www.redirect.com$1 redirect;
}
公式ではreturnを推奨しているとのことなのでそちらも載せときます。
server {
listen 80;
server_name www.example.com;
return 302 http://www.redirect.com$request_uri;
}
その他のリダイレクト
自分は正直全然意識していなかったんですが、HTTPも常にバージョンが上がっていて2019年4月現在の最新はHTTP/3とのこと各種ブラウザもこのプロトコルを吸収していく形になるんだと思います。そんなHTTPですがステータスコードも着実に増えていて、現状は303, 307, 308なんてものが存在します。正直どんな時に使用するのかまだ想像できていませんが、特徴を記載して今回は終わりにしたいと思います。
303リダイレクト
HTTP/1.1から導入- 意味合い：他を参照せよ
規格の説明として上のような内容が書かれていたんですが、分かるような分からないような？という感じでモヤモヤします。こんな説明もありました。
新しいURLにはGETアクセスすることが決められたリダイレクト。
いろんな説明サイトを見て自分なりにこんな解釈になりました。
まず、掲示板サイトがあるとします。
『掲示板サイトで書き込み投稿する時のよくある例として書き込みフォームに何かしら"発言"を書き込んで、登録ボタンを押すと登録完了ページに飛んで登録完了！なんていうのがあるけど、その仕組として"発言"を書き込んで登録ボタンを押すタイミングでその情報がPOSTされて登録完了ページにリダイレクトされる。そんな時のステータスコードはPOSTで返しても意味ないので、GETでURIを返して貰った方がいい。』
こんな例の時に303リダイレクトを使うそうな。
307リダイレクト
HTTP/1.1から導入- 一時的リダイレクト
これ定義自体は302と同じです。どうも302が想定と違う使い方をされまくっていることから『POSTでリクエストした場合はPOSTで返す！』という縛りがキツイステータスコードを用意したみたいです。
308リダイレクト
HTTP/1.1から導入- 恒久的リダイレクト
これも定義は301と同じです。これも理由は307と同じで『GETで送ったらGETで、POSTで送ったらPOSTで！』というルールが追加されてます。
ちなみにその他のリダイレクトnginxでもちゃんと対応していてreturnでそのステータスコード書いてあげるとちゃんとそのステータスコードでリダイレクトしてくれるのでお試しあれ。
総括
現状リダイレクトは中々面倒くさいことになっている。というのも、そもそも各ブラウザがHTTPの約束ごとに準拠していないようなのです。特に307,308はPOSTでリダイレクトしてもほとんどのブラウザがGETで返しているとのこと、しかも携帯やスマホなどのモバイル端末はブラウザのバージョンが古くHTTP/1.1とか知りません！というブラウザがゴロゴロしている状態なので、新しいステータスコードが使いづらいという選別も面倒くささに拍車をかけてます。Windows10みたいに最新化をごり押す気概が必要なんだなと思いました。（Microsoftさん、早くIEを取り除いて下さい。m(_ _)m ）
そして言い訳
先週結構大きめなリリースがありまして、休日なんかも出勤なんかしてしまいブログ更新ができませんでした。AWSのサービスもコンスタントに書いていかないと終わりゃしないので頑張っていきたいと思います。
ではでは、今回はここまで！
AWSのサービスを理解するーAWSコスト管理カテゴリ編ー
- AWSサービスを理解しよう！
- カテゴリ：AWSコスト管理
- AWS Billing and Cost Management
- AWS Cost Explorer [グラフでのコストの分析]
- AWSの料金体系について
- AWS Budgets [予算]
- AWS Cost and Usage Report [AWS のコストと使用状況レポート]
- Reserved Instance Reporting [リザーブドインスタンスレポート]
AWSサービスを理解しよう！
今回は"AWSコスト管理"です。やっと４つ目、残り１９カテゴリ。ゴールまでまだまだ道のり長いですが少しずつ書いていこうと思います。
カテゴリ：AWSコスト管理
名前の通りAWSにかかるコストを管理するサービスカテゴリです。改めてAWSにかかるコストとは何でしょう？
コストってなに？
辞書には『商品を生産するために必要な費用・原価・生産費』『物の値段』とありました。
AWSを利用するにあたってのコストってなに？
なんと言っても費用ですね。
そしてその費用を把握するには何が必要なのか？
下の項目を数値やグラフで見えるようにする必要があるのかなと思ってます。
- 何（どんなサービス）に対して？
- いつ？
- どれぐらい使ったか？
上の"費用を把握"という面を管理するサービスがこのカテゴリになるかなと思ってます。ではいつも通り以下AWSコスト管理カテゴリにぶら下がっているサービス一覧です。
とその前に、これから書いていくAWSコスト管理のサービスは"AWS Billing and Cost Management"の機能として内包されているようなので整理の意味も込めてそこから書いていきます。
AWS Billing and Cost Management
カテゴリ（トップメニューの製品欄）にはなかったんですが、このサービスがAWSコスト管理の各サービスを管理しているサービスになります。"AWS Billing and Cost Management"から各サービスを呼び出す感じですね。"AWS Billing and Cost Management"が親サービスで、これから記載する各サービスは子サービスと言う関係性でしょうか。この親サービスは別のカテゴリサービス（例えば、AWS Identity and Access ManagementやAWS Organizationsなど）と連携してコストを管理する役割を持っているようです。
各サービス（自分流だと子サービス）
AWS内の"AWS Billing and Cost Management"にある説明では機能として説明されていて、カテゴリ（製品欄一覧）ではサービスとして扱ってます。
下ではこの各サービスについての概要を書いていこうと思います。
AWS Cost Explorer [グラフでのコストの分析]
各サービスの費用はもちろん利用状況についてもグラフで分かりやすく表示してくれるサービスです。AWSに契約したアカウントで、"請求とコスト管理"メニューからCost Explorerに入って有効化することで利用することができます。
- 当月データは約24時間後に反映
- その後は最低でも24時間一回更新されるようです
- 過去分は最大13ヶ月分のコストグラフを見ることが可能
- フィルターやグルーピングを利用して状況分析することが可能
- 可能の利用状況から今後3ヶ月間のコストを予想
サービス別にコストを分析するためのビュー（表）を用意
コスト分析のためにサービス別に４つのビューを用意してくれているようです。
Monthly costs by service
サービス毎の月別使用量を表示します。過去分の表示は、月単位で過去90日間まで表示できるようです。
Monthly costs by linked account
アカウント毎の月別使用量を表示します。"AWS Consolidated Billing"で請求をまとめている場合アカウント間のコスト分布を表示します。
Daily costs
日別の使用量を表示します。
- 過去30日の各日の総コストを表示
- 月末までの予約を表示
Monthly EC2 costs and usage
EC2の月別使用状況とコストを表示します。過去3ヶ月の利用時間とコストを表示します。
AWS Consolidated Billing
複数アカウントで契約していても請求は一本化したいという場合にこのサービスを使って複数アカウントを親アカウントと子アカウントの関係性にして親アカウントが子アカウントの分もまとめて一括支払いができるサービスです。
- 全アカウントの利用料にボリューム割引が適用されるようになります
- 複数アカウントで無料枠を使用していても１アカウント分しか無料枠を適用されません
どうも各アカウントの利用料を親アカウントにまとめてから１つにし、そこに特典を適用しているように感じました。
AWSの料金体系について
知らなかったんですが、AWSには料金体系が３種類あり用途によって使用者が選択できるようになっているようです。
オンデマンドインスタンス
ようは従量課金です。使った分だけ課金されます。これが一番分かりやすいですね。
スポットインスタンス
AWS上にある使っていない余剰インスタンスを割安で利用できる方式のようです。費用はオークションのように入札で決まります。
費用は入札
事前に金額を設定しておき、その金額がAWS側が提示するサーバ価格より上だった場合サーバを起動することができる。ちょっと怖いのが設定した金額がAWS側の提示価格より下だった場合は、サーバが落とされるとのこと。提示価格の更新タイミングがよく分からなかったんですが一時間に一回更新されているような感じでした。（間違っていたらすみません。m(_ _m）
その時のインスタンス使用率にもよるらしいんですが、タイミングよってはオンデマンドに比べ８０％OFFなんていうのもあるみたいなので、上手く利用できればコストは大幅に削減できるかと思います。スポットというぐらいなのでやっぱりピンポイント（バッチや解析処理など）で利用する想定なのかなという感じです。（金額変動の感知をアラート機能を駆使して長期利用している強者もいるようですが(^^; ）
リザーブドインスタンス (RI)
AWSを利用する期間をあらかじめ決めて契約するプランみたいです。予約（リザーブ）ですね。AWS内では略してよく"RI"と書かれています。
- 期間：１年間又は３年年間
- 支払い方法（"前払いなし"から順に割引率が高くなります）
- 前払いなし
- 一部前払い
- 全前払い
提供タイプ
契約するにあたり下の２タイプがありスタンダードの方が自由度ないんですが、割引率が高くなっているようです。
スタンダードタイプ
契約する時に指定するインスタンスより大きなものへの変更はできないタイプです。（小さいものへ分割することはできるようです。）
コンバーティブルタイプ
契約後もインスタンスの変更が可能なタイプです。インスタンスを大きくする場合は差額分の費用が発生します。（小さくする場合は費用も削れるんだろうか？）
尚、契約後のキャンセルはできないようです。
AWS Budgets [予算]
大雑把ですが、予算を設定し閾値を超えたらアラートを上げて通知してくれるサービスです。フィルタを使ってサービス別や料金体系別などいろいろ条件で設定することができるようで便利そうです。あと予算というとお金を連想しますが、AWSでは予算タイプというタイプ別に設定することができるみたいです。
予算タイプ
タイプは下の４つでそれぞれのタイプで設定した値になったらアラートを上げる仕組みです。
コスト
費用ですね。分かりやすいです。例えば予算の80%を超えたらアラートとかですね。（実際はもっと細かく月別・サービス別などの設定がフィルタで設定できるようです。）
使用量
各サービスの使用量でアラートを上げることができるタイプですね。容量だけなのかCPUやメモリの使用率とかでもアラート上げられるのかちょっと謎です。ごめんなさい分かり次第更新します。
RI 使用率
リザーブドインスタンス契約で設定した使用率未満だった場合にアラートを上げることができるタイプのようです。確かにリザーブドの場合はもう支払う金額は決まっているので後は今後スペックを上げるか下げるかでこのタイプが参考になるんだと思います。
RI Coverage
"カバレッジ"これも難しい用語ですね。日本語だと"網羅率（カバー率）"といいますがこれで少し分かりやすくなったでしょうか？これは利用している現状のインスタンスに対してどれだけリザーブドインスタンスでカバー出来ているかをカバー率でアラートを上げる設定になります。書いてる自分が良く分かんない感じなんですが(^^; カバー率が少なすぎる場合はもうちょっとリザーブドインスタンス契約を進めた方が良いし、カバー率が高すぎる（過剰）な場合は減らした方が良いしというという形でアラート設定するんだと自分の中で飲み込みました。(--; これももうちょっと使用方法が分かったら更新します。
通知の種類
通知下の２つに対して閾値以上か以下だった場合通知するという設定ができるようです。
- 現行の値（費用だったり使用量だったり）
- 予測の値（AWSが想定した予測値の費用や使用量など）
通知先の種類
これもメール以外でも選択肢があって便利そうです。AWS Lambdaを使ってSlackにも通知できちゃうみたいです。（自分もやってみたいので、やってみたらブログ書きます。）大きく分けると下の３つでしょうか？
AWS Cost and Usage Report [AWS のコストと使用状況レポート]
定期的にレポートティングしてくれるサービスになります。具体的には"AWS Cost Explorer"から設定した情報をもとS3にレポートファイルを出力してくれるみたいです。
使用状況や費用の情報は毎月の月末に確定されて確定されたレポートファイルにはブレンドコストと非ブレンドコストの情報とその月の使用状況が記録されるようです。
ブレンドコストと非ブレンドコスト(unBlended Cost)
よく分からない用語が出てきたので、調べてみました。まずブレンドコストですね。
ブレンドコストって何？
"Blended Cost"と書きます。ブレンドコストを語るにはブレンドレートが必要になるようなので、まずそこから。
ブレンドレート
"Blended Rate"と書きます。請求金額を利用時間で割った平均値とのこと。"AWS Consolidated Billing"の設定によると思うんですが、請求金額をインスタンス別ではなく全インスタンスでの平均値で出しているとこのとです。具体的には一部をオンデマンドで契約し残りをリザーブドで契約している場合でも（両方の請求金額の合算金額）をインスタンスタイプごとの利用時間で割る感じで算出するようです。*1これでその月の毎時いくらかかっているかが分かりますね。
ブレンドコスト
さて本命のブレンドコスト。これはブレンドレートとインスタンスタイプごとの利用時間を掛けた値になります。なのでブレンドレートで毎時単位の費用が分かってブレンドコストからその月の費用が分かるということです。
非ブレンドコストは？
"unBlended Cost"と書きます。これも非ブレンドレートから説明していきます。
非ブレンドレート
"unBlended Rate"。元々の予測や設定した利用金額をインスタンス別に割った平均値になります。
非ブレンドコスト
非ブレンドレートとインスタンスタイプごとの利用時間を掛けた値になります。
AWS的には『ブレンドと非ブレンドのレートとコストを見比べて乖離が大きい場合はプランやスペックを考えて直して見てね』という感じで用意したのかと思ってます。
各サービスとの連携
このレポートは下のサービスに連携して各自カスタマイズが可能とのことなので一応それも載せておきます。
- Amazon Redshift
- ファイルを"Redshift"へアップロードすることで使用可能
- Amazon QuickSight
- これもファイルを"QuickSight"へアップロードすることで使用可能
- Amazon Athena
- S3に出力されているレポートファイルにクエリを発行して条件別にデータ抽出が可能
Reserved Instance Reporting [リザーブドインスタンスレポート]
リザーブドで契約した部分の使用率やカバレッジ（カバー率）をレポートしてくれるサービスになります。このサービスでも上で書いた各サービスとの連携は可能です。リザーブドの位置付けとしてリザーブドインスタンスは一定期間費用が固定なので、リザーブド特有のレポーティングサービスになっているようです。
- RI 使用率
- RI カバレッジ
如何でしたでしょうか？正直ちゃんと書けているか自身がないんですが、できるだけ分かりやすいように噛み砕いて書いてみたつもりです。できればここでなんとなく「こうゆうサービスなんだなー」と感じて貰って他でちゃんとした専門知識を得て貰えたらと思ってます。m(_ _)m 調べてて改めて思い知らされたんですたAWSさん費用まわりもいろいろニーズに答えようとしてくれているんですね。ここら辺は自分の使用した例なんかも書いていけたらと思ってます。
一旦今日はここまで！
AWSのサービスを理解するーAR と VRカテゴリ編ー
AWSサービス解説！
今回は"AR およびバーチャルリアリティ"です。
カテゴリ：AR と VR
今回は分かりやすい、今回のカテゴリは下のサービスを提供するカテゴリのようです。（なんでカテゴリ名のVRはカタカナなのかは、AWSサイトがそうなっているのでそのまま載せた感じです。他意はありません(^^; ）2019年3月17日：カテゴリ名が更新されてカタカナからVRに変わっていたのでこちらも更新！
- AR(Augmented Reality)：拡張現実
- VR(Virtual Reality)：仮想現実
拡張現実
現実を拡張させる技術。実在の風景に仮想な情報を重ねて表示させて先頭に書いたように"現実を仮想で拡張させる"技術と自分は理解しています。今のところ専用ゴーグルやスマホ越しに再現させている状況です。（そのうち脳にある周波を送ると何かが見えるとかできたらSFホラーちっくですね。）現状で有名どころは"ポケモンGO"などのゲームが大半といったところでしょうか？
仮想現実
仮想な(現実ではない)別世界を展開する技術。想像上のものをコンピュータを使って現実にあるかのように体感させる技術だと思ってます。体感と書いたのは見る（視覚）だけじゃなくて、味覚・聴覚・嗅覚・触覚の五感がすべて当てはまるります。映画の"マトリックス"とか有名ですね。
ARとVRの違いって何？
現状ARはVRを利用してARを表現しているので、結構ごっちゃになっちゃうかなと思っているんですが自分は下のような感じかなと考えています。
- ARは現実世界に現実ではない情報を重ねて表現させる
- VRは想像してものを五感に感じられるように表現させる
だいぶ余談が長かったんですが、こっからが本題です。毎度同じように以下AR およびバーチャルリアリティカテゴリにぶら下がっているサービス一覧です。（だた今回は一覧と言いつつひとつしかないみたい（^^; ）
Amazon Sumerian
ARやVRコンテンツを作成することができるサービスになります。類似の開発環境として有名どころとしては"Unity"や"Unreal Engine"とかでしょうか。"Unity"や"Unreal Engine"はローカルに環境を用意してコンテンツを作成する形になりますが、"Amazon Sumerian"はブラウザ上で開発ができるサービスになっているようです。
特徴
- AR、VR、3Dアプリケーションの作成・ビルド・起動を提供
- WebGLとWebVRをサポート
- マルチプラットフォームサポート（下のプラットフォームをサポート）
- Oculus Rift
- HTC Vive
- iOS
- Android
- AWSサービスとの連携（代表的なもとして下のサービスと連携できる）
今回は１サービスだけだったので、特徴とかも載せてみました。プログラム要らずでAR、VRを展開させる意欲サービスみたいです。（まープログラムが完全に要らなくなるような事はないと思いますが）Unityインポート機能みたいな物も用意されているようなので最終的にはこのサービスに集約される日が来るかもです。 次は、コスト管理カテゴリ編ですかね。その前に何か挟むかもです。
今回はここまで！
AWSのサービスを理解するーアプリケーション統合カテゴリ編ー
- AWSのサービスを理解して行きたい！の続き
- カテゴリ：アプリケーション統合
- AWS Step Functions
- Amazon MQ
- Amazon Simple Notification Service (SNS)
- Amazon Simple Queue Service (SQS)
- AWS AppSync
- Amazon Simple Workflow (SWF)
AWSのサービスを理解して行きたい！の続き
前回からの続きでAWSのカテゴリ別サービスの簡単解説行っていきます。今回はアプリケーション統合です。
カテゴリ：アプリケーション統合
アプリケーションとアプリケーションを結びつけるサービス郡といった感じのようです。分析カテゴリと同じように以下アプリケーション統合カテゴリにぶら下がっているサービス一覧です。
AWS Step Functions
AWS LambdaやAmazon EC2 Container Service (ECS)で作成した処理やサービスを繋げて一つのワークフローを構築できるサービスです。昔の感覚で自分流に書いてしまうと、各ジョブ管理システムの拡張版という感じでしょうか？
使用方法としは、Amazon States Language (ASL)*1を使って各Task*2を制御（例えば処理が成功したらTask'A'を実行など）するフロー図を作成し実行することができるようです。
Amazon MQ
前回"Amazon Kinesis"のところでも少し書きましたが、Apacheから出しているActiveMQをAWSとしてサービス化したものが"Amazon MQ"になります。昔からのMQを使用したい人はこちらを利用する感じでしょうか。
Amazon Simple Notification Service (SNS)
小難しくいうと"pub(Publish)-sub(Subscribe)メッセージング"を仲介するサービスだそうな。噛み砕くと"出版-購読仲介サービス"。モバイルプッシュ、Short Message Service (SMS)、Eメールの配信や送信タイミングを管理・調整するサービスです。なんですが"出版-購読仲介サービス"なんで、「システムから人へ」だけでなく「システムからシステムへ」にも使用できるとのこと、ただ個人的には「システムからシステムへ」の場合はキューやストリーミングサービスを使用した方が幸せにあれる感じがするのでやっぱり用途は、人への配信かなと思ったしだいです。
Amazon Simple Queue Service (SQS)
これも前回"Amazon Kinesis"のところでも少し書きましたが、MQという規格をもっとシンプルにすることで、"SQS"を使用するサービスをよりスケーラブルな（拡張性のある）システムにすることができるというのが"Amazon MQ"との違いのようです。なので新規でMQを使用したい場合は、"SQS"を使用した方が幸せになれるみたいです。
AWS AppSync
GraphQLをより簡単に利用しやすくした管理サービスです。ではGraphQLとは何でしょう？
GraphQLとは？
『APIへの問い合わせ言語』だそうな。そしてこれを利用したAPIがGraphQL APIとなります。同列には皆さんご存知REST APIがあります。仕組みとして、REST APIはAPI側で設定した定義をもとに値を返すのに対してGraphQL APIはフロント側で設定した定義をAPIが解釈して値を返す言語らしいです。なのでREST APIの場合｢今回はこの情報要らないんだけどなー」という時でも全部取り込んで必要なものだけ表示をするんだけど、GraphQL APIは、「今回はこれだけ必要」とか定義するとそれだけ抽出してくれるそうな。
AppSyncの場合、下のデータソースとのやり取りがやりやすいように準備されているみたいです。
- Amazon DynamoDB
- Amazon Elasticsearch Service
- AWS Lambda
ちなみにモバイルカテゴリにも存在している(？)
Amazon Simple Workflow (SWF)
これもワークフロー管理サービスみたいです。SWFの特徴は、『スケーラブルで分散したワークフローを提供することが可能』で、『リージョンをまたいだワークフローやAWSとオンプレとの連携も実現することが可能』とのことです。AWSには他に"AWS Step Functions"というワークフローを管理するサービスがあるので、ここで違い（使い分け）をザックリ書いておこうと思います。
この２つのサービスの使い分けとしてタスク間でより細かな制御をする場合は"Amazon Simple Workflow"。ある程度シンプルな制御で済む場合は"AWS Step Functions"を使った方がいいようです。では複雑な制御って何なのかという話なんですが、"Amazon Simple Workflow"では"ディサイダー"というタスク間の連携を制御する機能が必要でこれは各自で自作して用意する必要があるようです。自作の内容によってはオンプレサーバに繋ぐことやクライアントからの返答待ちなど自由な制御が可能となっています。（自作プログラムは、サービスAPIとの通信ができれば何でもよいとのこと）なので、こんな自前制御なんて必要ないという話であれば"AWS Step Functions"を使った方が幸せになれるようです。
ドキュメント一覧には"AWS AppSync"が無くこちらのサービスがあったので、載せておきます。（どちらにせよ製品リスト、ドキュメントどちらか間違っているかと(^^; ）
今回も公開までに時間がかかってしまいました。見た目同じ様なサービスで違いを調べるのに結構時間がかかる。。。
次回こそ休憩がてら軽いものを書こうと思います。その後次のカテゴリ"AR およびバーチャルリアリティ"とい流れで、行こうかなと思ってます。
それでは今回はここまで！
