Hatena::ブログ(Diary)

FAT47の底辺インフラ議事録

2017-02-23

日本初のVRサイクルスタジオに行った話

1年ぶりの更新になってしまいました

VRサイクルとは

f:id:fat47:20170223094716j:image:w640

先日2/21にプレオープンしたCYCLE & STUDIO R Shibuyaに行ってきました。

(グランドオープンは3/19予定)

そもそもVRサイクルとは何なのかはこちらの動画を見るとわかりやすいと思います。

D

よくあるVRゴーグルを装着するわけではなく、目の前に湾曲した大型スクリーンがあり

そこに仮想の道が表示されていて、暗闇の中全力でバイクを漕ぐプログラムになります。

なので、景色を見渡せるわけではないので、VRにそこまで期待していくと拍子抜けするかもしれません。


体験してきた

3/17まで体験レッスンがWebサイトから申し込めます。(3000円)

体験レッスンではタオル・ウェア上下・シューズのレンタルと水一本がついていたので、

手ぶらで行けました。

場所は渋谷109前の交差点にある本屋のブックファーストが入ってるビルの5Fです。

f:id:fat47:20170221224331j:image:w640

入り口にある券売機で3000円の券を購入してスタッフに渡します。

入り口で靴を脱いだら、タオルや着替えを受け取りロッカールームで着替えます。

着替え終わったら、ロッカールームの外でバイク専用のシューズを受け取ってバイクルームへ。


スクリーンがデカい!中で写真は撮れなかったので、公式の画像を。

f:id:fat47:20170223094716j:image:w640

プログラムの時間は45分間で、インストラクターと一緒に全力でひたすらバイクを漕ぎます。

バイクの負荷は自動でかわるわけでははく自分で調整するので、上り坂の映像になったら負荷を増やすというかんじです。

最前列を確保できたら没入感は結構ありそうです。後ろのほうだとスクリーンが遠くなってしまうので、

気楽にやりたいときは後ろかなぁ。

ディズニーランドのスターツアーズの中でバイクを漕いでいる感覚がちかいですね。

とにかく45分間で尋常じゃないほどの汗をかくので水分補給が大事です。

プログラム後はロッカーにあるシャワールームで汗を流して、最後に入会するひとは手続きして終了です。

入会への勧誘はほぼないんじゃないかってぐらいあっさりした説明だけだったので、

気軽に体験できそうなかんじでした。

最近渋谷にVRのゲーセンができたり、渋谷のVR熱が高まってますね。

とりあえず私は入会してみることにしたので、グランドオープン後に通ってみようと思います!

では!

2016-03-17 引っ越しして自室にプロジェクターを導入した話

最近少し広めの部屋に引っ越しをしたので、自室にプロジェクターを導入してみました。

賃貸マンションでプロジェクター導入する人の参考になれば・・・。

f:id:fat47:20160304230811j:image:w640

購入したもの

プロジェクターはエプソンのTW5350を購入しました。

9万を切る価格で2200ルーメンの明るさとフルHDの解像度をもつコスパの良さがいいですね。

↓製品

スクリーンはオーエスのSMH-100HNを購入。

100インチの吊り下げタイプで13000円弱という安さ。

スクリーンはどうせ下げっぱなしにする予定だったので、巻き上げ機能もないシンプルなものにしました。

↓製品

オーエス 掛図スクリーンHD100型 マスクなし SMH-100HN-WG107

オーエス 掛図スクリーンHD100型 マスクなし SMH-100HN-WG107

最初カーテンレールに固定しようと思っていたんですが、ちょっと重さが不安だったので

窓枠に突っ張り棒タイプの物干し竿を設置しました。

↓製品

スクリーンのひっかける部分と物干し座を結束バンドで固定します。

f:id:fat47:20160317152449j:image

プロジェクターに台形補正機能ついていますが、

どうせなら中央付近から写したかったので、天井つっぱりのメタルラックを設置しました。

f:id:fat47:20160317152531j:image

↓製品

プロジェクターと天吊り用金具を固定します。

純正品は異常に高価なので、以下のものを使用しました。TW5350でも問題なく固定できました。

↓製品

メタルラック最上段の板と天吊り金具を固定します。

適当にホームセンターで購入してきた穴あきメタルプレートを4枚使用しました。

板と天吊り金具を固定するネジは付属していないので、ネジとワッシャーとナットも購入しておきましょう。

たしかM5サイズのネジセットを購入したとおもいます。

f:id:fat47:20160317152538j:image

賃貸マンションということもあり、あまり低音が強いスピーカーを求めていなかったので

パナソニックのシアターバーを購入しました。テレビの手前とかに置くものなのでスッキリおけます。


失敗した点

プロジェクターのTW5350とスピーカーのSC-HTB170を接続するときに、

Bluetooth接続でやれば線もなく綺麗にできると思っていたんですが、

実際に接続してみると若干音の遅れが気になりました。映画とかだとあまり気にならないのですが、

音楽ライブ映像とかを見ると口の動きと音声がほんの少しずれているのが気になりました。

なので有線で接続しようとしたのですが、TW5350の音声出力はステレオミニジャックで、

SC-HTB170の入力はHDMIか光デジタルオーディオしかないので、直接接続することができません。

ですので、

TW5350のステレオミニジャック→オーディオ変換機(アナログ→デジタル変換)→SC-HTB170の光デジタルオーディオ端子

に変換して接続しました。使用したのは以下の製品です。

エレコム オーディオケーブル_ステレオミニ-ピンX2 2m DH-MWR20

エレコム オーディオケーブル_ステレオミニ-ピンX2 2m DH-MWR20

ランサーリンク オーディオ変換機(アナログ→デジタル変換) DCT-4

ランサーリンク オーディオ変換機(アナログ→デジタル変換) DCT-4



プロジェクター買ってよかった!!

臨場感がすごいので、ライブのブルーレイを買いまくってしまいます。

f:id:fat47:20160317192807j:image

Amazonプライムビデオも捗る

f:id:fat47:20160315210739j:image


みなさんも買いましょうプロジェクター。

2015-08-14

S3+CloudFrontの期限付き認証URL発行機能でコンテンツ配信

概要

S3+CloudFrontで認証付きURL発行して、認証なしのアクセスを弾きたい。


設定手順

S3バケットの作成

コンテンツ格納先のS3の作成をします

マネージメントコンソールからS3をクリック

f:id:fat47:20150814162823p:image:w360


バケットの作成をクリック

f:id:fat47:20150814162953p:image:w360


任意のバケット名を入力して作成をクリック

f:id:fat47:20150814162954p:image:w360


作成されたらプロパティをおして、アクセス許可の項目を確認

現在はなにも設定されていないので、

「バケットポリシーの追加」などしか表示されていない


CloudFrontの設定

S3のファイルを配信するCloudFrontを設定します

マネージメントコンソールからCouldFrontをクリック

f:id:fat47:20150814162955p:image:w360


CreateDistributionをクリック

f:id:fat47:20150814162956p:image:w360


デリバリーメソッドの選択

今回はWebコンテンツの配信なのでWebの項目から「Get Started」をクリック

f:id:fat47:20150814162957p:image:w360


Origin Domain Nameの項目をクリックして、

先程作成したS3バケットを選択

f:id:fat47:20150814162958p:image:w360


オリジンアクセスアイデンティティ設定

「Restrict Bucket Access」でYesを選択

「Origin Access Identity」でCreate ad New Identityを選択cket

「Comment」に用途がわかるようなコメントを記入:例:access-identity-[バケット名]

「Grant Read Permissions on Bucket」でYes,Update BuPolisyを選択

f:id:fat47:20150814162959p:image:w360


その他はそのままでいいので、

一番下にある「Create Distribution」をクリック

f:id:fat47:20150814163000p:image:w360


最大15分程度設定反映まで時間がかかるので、

以下の行程は時間を置いてから行います


オリジンアクセスアイデンティティの確認

左メニューからOrigin Access Identityをクリック

すると今設定されてるものがリストで表示されます

先程Commentで入力したaccess-identity-[バケット名]が表示されている事を確認

「ID」の部分を覚えておきます(今回の場合はECS***)

f:id:fat47:20150814163001p:image:w360


S3バケットのポリシー確認

バケットのポリシーも同時に変更されているので確認

マネージメントコンソールからS3管理画面に飛んで、

先程作成したS3バケットを選択して、

「プロパティ」→「アクセス許可」→「バケットポリシーの編集」をクリック

f:id:fat47:20150814163002p:image:w360


先程を空欄だったらバケットポリシーが変更されていて、

GetAbjectに先程CloudFrontで設定されたIDが付与されています

f:id:fat47:20150814163003p:image:w360

コンテンツの利用確認

S3管理画面からバケットを選択して、適当なコンテンツをアップロードします

コンテンツを選択してプロパティを選択するとその画像のURLが表示されます

例、リンク: https://s3-ap-******.amazonaws.com/dev.hogehoge/hogehogehoge.jpg

そのURLを開こうとするとAccessDeniedではじかれます

f:id:fat47:20150814163004p:image:w360


次はCloudFrontの管理画面をひらき、先程作成したディストリビューションを選択

Genetalのタブをひらくと、Domain Nameという項目があるのでそれをコピー

ブラウザからに貼り付けて、先程S3にアップしたコンテンツのファイル名をつけてアクセス

例、https://********.cloudfront.net/hogehogehoge.jpg

するとちゃんと画像が表示されます

CloudFrontキーペアの作成

以下のドキュメントの通り、管理画面からキーペアを作成します

http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html

ユーザ権限によっては作成できないので、出来ない場合は管理者に問い合わせます

作成したキーペアをCloudFrontのディストリビューションに紐付ける

CloudFrontの管理画面からディストリビューションを選択して、

「Behavior」タブから一つのポリシーを選択して、

「Edit」ボタンをクリック

f:id:fat47:20150814163005p:image:w360

Restrict Viewer Accessをyesにし、

Trusted SignersでSelfを選択して、下にある「yes,Edit」をクリックします

※作成したキーペアの所有者がCloudFrontディストリビューションを作成している

AWSアカウント自体であればSelfで大丈夫ですが、

それ以外のAWSアカウントであれば「Specity Accounts」をチェックして、

そのAWSアカウント番号を入力

f:id:fat47:20150814163006p:image:w360


perlを使って認証URL発行テストする

1.Amazon CloudFront Signed URLs helper toolをダウンロードしてくる

https://aws.amazon.com/items/3052?externalID=3052&categoryID=215

2. perlで足りなかったモジュール入れます

yum install perl-URI

3. ツール実行

./cfsign.pl --action encode --url http://hogehoge**.cloudfront.net/index.html --expires 1435047210 --private-key pk-*****.pem --key-pair-id *****
    • url アクセスしたいコンテンツのCloudFront上のURL
    • expires 有効期限をUNIXタイムスタンプで指定
    • private-key AWS上で取得した秘密鍵を指定
    • key-pair-id アクセスキーを指定

すると、

Encoded URL:
http://*****.cloudfront.net/index.html?Expires=1435047210&Signature=PEJX4gtNsXPjVd5Hm4s9yRMGaQlYA7bRzeex-dz4f2Cgeha9GshVnwVUfTK0mv7WrO4nfvE53Ykcxxy4XfjNlvmy17fHDMsRT3gqlGgpBBPNTh55zPcjJkWMNMp7xSzDFKX3D7wsFeIhk2a5ppeQhXC2xK6yK81KOHuW-vOLqKBk6yRZyhpTFcwQohlGjARt0rkoJepCA8grwX84v6w79BB6k7kjxzNoMTjg7g1WvO0BHKnVvqKhogehogehogehogehogehoge
<l --expires 1435047210 --private-key pk-*****.pem --key-pair-id *****

のような期限付きで利用可能なURLが帰ってきます

参考URL

[CloudFront + S3]特定バケットに特定ディストリビューションのみからアクセスできるよう設定する

http://dev.classmethod.jp/cloud/aws/cloudfront-s3-origin-access-identity/

CloudFront+S3で署名付きURLでプライベートコンテンツを配信する

http://dev.classmethod.jp/cloud/aws/cf-s3-deliveries-use-signurl/

CloudFront を使用してプライベートコンテンツを供給する

http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html

オリジンアクセスアイデンティティを使用して Amazon S3 コンテンツへのアクセスを制限する

http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html

2014-07-30

nginxでLDAP認証いれたらめっちゃ遅くなった話

f:id:fat47:20140730153253p:image:w360

静的コンテンツ配信の為だけのサーバでnginxを利用。

公開前のサーバだったのでLDAPの認証をかけて確認したところ、

cssとかjsとか画像ファイルとかの静的ファイルの応答時間が10秒かかって、

HTTPステータスコード000になるという状態になった。

/var/log/nginx/access.log

24**:****: - hoge_fuga [30/Jul/2014:13:53:48 +0900] "GET /pc/ HTTP/1.1" 200 2244 "http://[24**:****:]/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko Firefox/28.0" "-" 0.005
24**:****: - hoge_fuga [30/Jul/2014:13:53:50 +0900] "GET /img/header.png HTTP/1.1" 000 0 "http://[24**:****:]/pc/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko Firefox/28.0" "-" 10.002

nginxでLDAP認証いれた設定

/etc/nginx/nginx.conf


http { の中に
    ldap_server nd {
    url ldap://hogehoge-ldap.jp/ou=nd,dc=fugafuga,dc=co,dc=jp?uid?sub;
    require valid_user;
    }

server { の中に
    auth_ldap "LDAP";
    auth_ldap_servers nd;

LDAP認証を外したり、.httpasswdファイルを置いたBasic認証だと上記の状況にはならなかった。

nginx-auth-ldapのソースコードには10000ms(10秒)のタイムアウト指定されていた

ngx_http_auth_ldap_module.c

ログ上の10秒後に応答帰ってくるのはこれが原因ぽい。

そしてこちらを見ると以下の様な設定がnginxで必要。

Module does no result-caching... slows down all web requests?


これがないとすべてのリクエストにLDAPの認証が毎回走ってしまうようだ。

auth_ldap_cache_enabled on;
auth_ldap_cache_expiration_time 10000;
auth_ldap_cache_size 1000;

auth_ldap_cache_expiration_timeとauth_ldap_cache_sizeに関しては、デフォルト値の設定があるようなので指定しなくても動作しそう。

なので、設定ファイルのhttp部に追加する。

/etc/nginx/nginx.conf

http {
.
.
.
    auth_ldap_cache_enabled on;

ログ確認

24**:****: - hoge_fuga [30/Jul/2014:13:55:45 +0900] "GET /pc/ HTTP/1.1" 200 2244 "http://[24**:****:]/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko Firefox/28.0" "-" 0.001
24**:****: - hoge_fuga [30/Jul/2014:13:55:45 +0900] "GET /img/header.png HTTP/1.1" 200 229015 "http://[24**:****:]/pc/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko Firefox/28.0" "-" 0.003

やったぜ速いぜ!

今までApache+LDAPでこの問題に遭遇したことなかったけど、

確認してみるとApacheではデフォルトでLDAPのキャッシュ有効になっていたようだ。

http://httpd.apache.org/docs/2.4/mod/mod_ldap.html#ldapopcacheentries


Apache大好き。

2014-04-21

online-schema-changeを過信していたら痛い目をみた話

f:id:fat47:20140421104444j:image

先日記事に書いたように、無停止のALTER文実行では

Percona-ToolkitのOnline-schema-changeを利用しています。

無停止でALTERできるPercona-Toolkitのonline-schema-change

オンラインでのカラム追加

私が担当しているサービスでは、ALTER文実行時にレプリケーションの遅延を出来るだけ発生させたくないので、

以下の様な手順でOnline-schema-changeを実行しています。

(1) スレーブ全台でOnline-schema-changeの実行

(2) マスターでOnline-schema-changeの実行(--set-vars="sql_log_bin=0"のオプション指定)

"sql_log_bin=0"オプションをつけて実行すると、binlogを出さずに実行できるので、

マスターで実行してもそのクエリはスレーブにレプリケーションされません。

この手順でINDEXの追加やカラムの追加などを実行していました。

事故の発生

いつものように、スレーブでonline-schema-change実行後、マスターで実行させました。

すると、一斉にアラートメールが。。。

スレーブ全台がエラーでレプリケーション停止してました。

Last_SQL_Error: Error executing row event: 'Table 'hoge._user_new' doesn't exist'
 Replicate_Ignore_Server_Ids:

事故の概要

"sql_log_bin=0"オプションを指定して実行したマスターDBでの作業時に、

なぜかトリガーの作成がスレーブにレプリケーションされて、

スレーブ側で存在しないテーブルへ更新が走るようになりエラーで停止しました。

そもそも、Online-Schema-Changeの仕組みとしては、先日記事に書いたとおり

online-schema-changeの仕組み

1. 対象テーブルと同じ構造をした作業用テーブルを作成する

2. 作業用テーブルに変更するALTER文を適用する

3. 3つトリガーを作成して、対象テーブルへの挿入・削除・更新が作業用テーブルに反映されるようにする

4. 対象テーブルから作業用テーブルへデータをコピーしてくる

5. RENAMEして対象テーブルと作業用テーブルを入れ替える

6. 入れ替え後の古いテーブルとトリガーを削除する

http://d.hatena.ne.jp/fat47/20140418/1397811745

このようになっています。

この(3)での処理がなぜかスレーブにも伝搬して、

Last_SQL_Error: Error executing row event: 'Table 'hoge._user_new' doesn't exist'
 Replicate_Ignore_Server_Ids:

このhoge._user_newテーブルへの更新がスレーブで走るようになってしまいました。

発生した環境

バージョン

DBマスター

OSCentOS5.4
DBMySQL5.5.24
Percona-Toolkit2.2.7-1

DBスレーブ

OSCentOS6.2
DBMySQL5.5.24
Percona-Toolkit2.2.7-1

発行したSQL

ALTER TABLE `user` ADD COLUMN fuga int(10) NOT NULL DEFAULT '0' COMMENT 'fugafuga';

対象テーブルのデータ件数

select count(*) from user;
+----------+
| count(*) |
+----------+
| 18476032 |
+----------+
1 row in set (9.09 sec)

検証環境でいろいろ試してみた

本番データを入れて検証環境で試してみました。

ちなみに、今回データ数の少ないステージング環境で事前に試していましたが、そちらの動作では問題ありませんでした。

エラー出て失敗したパターン

■DBMのOSバージョンを入れ替える

DBMをCentOS6.2、DBSをCentOS5.4に

MySQLのバージョンを上げてみる

MySQL5.5.24から5.5.34に

■Percona-Toolkitのバージョン下げてみる

他サービスで動作実績のある2.2.6に

■カラム追加ではなくてINDEX追加にして実行してみる


エラー出ずに実行完了したパターン

■別のテーブルにカラム追加してみる

■他サービスで実行成功したテーブル(今回のテーブルよりデータ量2倍)で確認してみる。

他サービスのテーブルをdumpして検証環境に挿入して実行


とりあえず結果

一部の条件を満たすテーブルでのみバグが発生する

でも、一部の条件がわからない…。なんだろう。。。

今後の対策

スレーブ側で作業テーブルがないためエラーになってしまうので、

スレーブ実行後に事前に作業テーブル(_テーブル名_new)を作成しておけば、仮にスレーブ側で

トリガーが作成されてしまってもエラーでレプリ停止することはない。

マスターで実行完了後に、スレーブで作成した作業テーブルをDROPする。

最後に

怖い作業やるときは、事前に本番と同様の環境で動作チェックすること!

本番に近いデータ量じゃないと再現しないこともある!



_| ̄|● サービス停止させて、本当に本当に申し訳ありませんでした。

Connection: close