仕事の備忘録

IT系技術とか、カスタマーサービスとか

Qculus Quest をセットアップするまでの手順と確認点

 前回のブログをみて反応が大変大きくてびっくりしている。流入元をみるとどうやらSmartNewsに掲載されたらしい。そしてそのブログをみた働いている子供から「今度Quest 購入しようと思う」というLINEが来た。おおお!ボッチでやってたから複数人での体験を初めて出来る予定ができた。

ということでOculus Questのセットアップ手順と確認点を自分が参考にしたリンク先とあわせてまとめておく。買うと決めた方に役に立つと嬉しい。高い買い物ですもんね。

0.買う前にOculus Questのおさらい

VRと言えばMoguraVRさん。レビュー記事を紹介しておく。他のOculus Quest記事も参考にしたほうがよい。

www.moguravr.com

1.利用アカウントの確認とインストール用アプリの確認

Oculus社はFacebookの配下のためFacebookアカウントが王道。ただ登録するとランキングなどすべてのものでFacebookアカウント名が表示される。なのでゲームのランキングもアイコンと共に表示。Facebookは本名で登録していて表示されたくない人は新規にOculusアカウントを登録する方法もある。ただFacebookアカウントのみ対応しているアプリもあるらしい。一度紐づけすると初期化以外にアカウント設定できないので先に決めておくこと。Facebookアカウント持ってない方はこのタイミングで作るのもあり。将来は切り替え予定もあるらしい。

www.moguravr.com

あとインストールにはスマートフォンiOSかAndroidが必要なので準備を。ないとインストールできない。ガラケーしか持ってないと先に買うべきはOculusよりAndroidです。

2.購入

Amazon で買うとなぜか遅延するOculus製品。あとOculus社自身も直接買ってくれるほうが嬉しいとTwitterでつぶやいていたので公式サイトをお勧め。ストレージ容量の違いなのでパソコンあるなら安いほうで問題ない。Amazon だと転売屋さんも多いので見分けるの自身ある方以外には勧めない。

以下公式サイトですが英語で出てますが購入は日本語で大丈夫。注意点は荷物の発送がアメリカからなので住所などを英語で入力する。

www.oculus.com

住所入力など英語でわからない!という方には、以下のサイトが非常に親切に説明している・・・が、アダルトVRの初心者向けサイトなのでその点を気にしない方のみリンク先を見てほしい。説明文自体非常に丁寧で今まで見た中でここまでOculusのHPに親切な入力説明はなかった。が他のページは普通に肌色だらけなので・・・

adultvr-choose.com

3.セットアップ

2.で発送されると早ければ3日で届く。アメリカからこんなに早く届くのだと毎回びっくりする。で、1.で準備したスマートフォンがあればセットアップはアプリが導いてくれる。説明としてはMoguraVRさんのセットアップ方法が一番わかりやすかった。

数分で完了 Oculus Questの開封からセットアップまで詳細 | MoguLive - 「バーチャルを楽しむ」ためのエンタメメディア

とりあえずセットアップはMoguravrさんのみれば確実にできると思う。それより部屋を片付けたり壁に服をかけたりしてケガしないよう場所確保なりよ(広い場所がある方は場所設定すれば安全になるんで問題なし)

2019/06/29 17:59

4.質問をしたいとき

Oculus Questについてわからないとき、以下のFacebookグループにはVRアプリ開発者などが多いので投稿してみるのがよいと思う。アプリの紹介などしてくれる方も多くてありがたい。

www.facebook.com

これで一人で購入からセットアップまで可能なはず。アプリの紹介は検索でたくさん出てきますが、できれば「やってみた動画」を見るのをお勧めする。思ったより場所が必要なものや逆にそこまでいらないものなど把握しやすい。

Oculus Quest は忙しくてスポーツ嫌いな人が買うといいよ

Oculus Quest を発売日に手に入れた。Oculus QuestはFacebook配下のOculus社が発売したスタンドアロン型のVRヘッドマウントディスプレイ(HMD)。

www.oculus.com

Oculus Goを購入してから東京クロノスを経由してVRが大好きになってから購入したQuest。一月ほぼ毎日稼働しているのは子供と二人で利用していることが大きい。

Oculus Goと異なるのは前後左右高さの概念があること。つまり体全体の動きを検知してアプリケーションが動作する。下は上記Questのトップページ。この写真通りに全身でVRの世界に入り込むのだ。以前紹介したWindows MRと異なりPCとつながるケーブルはない。これより自分の動きに制限がないことがこんなに楽なのだと、毎日使っている自分で実感している。1分あればライトセーバーが輝くのだ。

f:id:testedquality:20190628233436p:plain

この写真はVR系で代表的なゲーム Beat Saber 。私と子供はこのゲームをほぼ毎日やっている。今までは風呂場でストレッチをするのが日課だったのだが、この一月は先に20分から30分毎日ライトセーバーをもってブロックを切り、汗だくになったタイミングで風呂に入る様にしている。

もう一つのお気に入りはDance Central。XBOX360からある定番アプリらしいが、この2,3年の洋楽が32曲もあるのがよい。日本語完全対応でダンスフロアでアメリカンな会話ができるのが超楽しい。ダンスがステップは少な目で体をリズムにあわせて揺らす感じ。腰を揺らす、腕を回すなど「ステイ感」が高いため中高年の私でも大丈夫であるし、2畳あれば問題なし。

www.oculus.com

Oculus Questのいいところ

一月経ったうえでQuestの好きな点を上げてみる

  1. 室内で24時間いつでも運動できる。時間に縛られない。
  2. 思い立って5分もあれば開始できる。決心が揺るぐ間がない。
  3. VRのキャラクターたちは誰も下手な動きを嘲笑しない。心理的安全が満たされているので楽である。
  4. 未体験でも楽しめる。ダンスフロアでのバトルとかやったことないし。
  5. 楽しみながら全身運動ができる。運動のいいところどりである

1.2.は一体型であることのメリットなのだが、WindowsMRを使っている自分でも圧倒的に楽に流れているのがわかる。同じ場所に置いてるのにPCにつなぎたくないのだ。それから3.4.5.はおもてなし度数がVRで高められていることを感じる。自分がいる環境がVRで包まれるので現実から切り離された世界での活動となる。それが楽しい。

ちなみに私は痩せてないが、毎日使っている方々は痩せているらしく、ダイエット機器として優秀だと思う。私は痩せなくても体質は変わったらしく、残業でたまに出てきていた腰痛が全くなくなったのでありがたい。

每日、BEAT SABER2時間ぐらいずつやってたら、ゴルフ練習いったら、うまくなっていました - 勝間和代が徹底的にマニアックな話をアップするブログ

いいこと聞きました!運動苦手なゲーマーの子供が昨日デモ版1曲を30分以上やってたのでこのまま継続させるため本日製品版を購入します。

2019/06/01 12:06

 公式サイトから購入すれば5万円で購入可能。VRとか関係なくダイエットマシンでもいいと思っている。VRの間口を広げる楽しさを提供する機器としてOculus Questぜひ皆さんに買ってもらいたい。

Athenaのメモリ制限をかいくぐる新機能 CTASを使ってみた

昨年末にAthenaを業務適用した際の話を書いた。

testedquality-tech.hatenadiary.jp

その後リリースしたシステムは使われるようになり、バグもなく、利用者も想定通りの発生率。目標達成したので追加開発に入るとの話だった。そのため早速要件定義を始めたところ、レコード最大件数は変更しない状態で、出力項目数を最大6000カラムにしてほしいとの要件が入ってきた。前回の要件はこちら。

ヘッダが商品IDの1000カラム+ID単位1以上の値を持つ場合の0/1フラグで合計2000カラム、出力行数は200万レコードが最大となる。

このヘッダ部分に商品IDごとの追加データを任意で最大4カラム追加となったのだ。前回Athenaを使った現行要件だと、2000カラムが限界値であると把握していたが、その3倍である。現行全く対応できない項目数。

  1. 単純に6000カラム並べただけでAthenaのSQL文字数制限を大幅に超える。
  2. 最大メモリをさらに使うため同時処理数にさらに制限がかかる。

5JOBどころか全く処理できない!

2つの問題をに頭を抱えたまま、チームに持ち帰り対応を検討した。

最初はAmazon EMRにて処理することを考えた。既に2年近く業務利用していることもあり開発には問題がない。Athenaでできない部分はファイル処理でもなんとでもする方法だ。

aws.amazon.com

ただし利用するたびにインスタンスを用意するのに8分程度かかる。それは現在遅くても3分内で検索完了する要件を満たせない。

続いて開発メンバーから「Athenaが一時テーブル利用ができるようになった」という話がでてきた。CTAS(Create Table As Select )と呼ばれているこの機能はSelect内容を新テーブルとして作成する機能で2018年11月に追加された。

aws.amazon.com

詳細についてはクラスメソッドさんの以下のブログがわかりやすくまとめられているので参照してほしい。

dev.classmethod.jp

ここで実際にCTASを現行SQLで試しているうち「項目を分割して、複数の一時テーブルとして出力、最後にすべてを1テーブルにまとめる」というアイデアがでてきた。図にすると以下のようになる。

f:id:testedquality:20190503234747p:plain

要件では

検索では件数と上位10件を表示、確認後OKならcsv出力を実施。

これより3.のタイミングで10レコードに絞り込むことで3.の処理をAthenaのメモリ制限内に収めることが可能である。(1.の時点で件数は確定している)

【良かった点】

カラム数が大幅に増えてもAthenaのまま対応できた

出力項目が多い検索は既存より早くなった。

一定規模を超えた時、同一件数をSelectするよりCTASするほうが早くなるのが判明。

【悪かった点】

少ないレコード数だと検索速度が現行DWHより悪くなった

これは一時テーブル作成のオーバーヘッドが出るため。

②CTASでの一時テーブル作成後はAthenaの制限で操作ができない場合がでる

CTASはメモリ利用がSlelectと異なるのかSelectではできなかった2000カラム越えの一時テーブル作成も可能なことが分かったので対応できそうだと思った・・・が、一時テーブルとして実テーブル化してしまった3.のテーブルを再度並び替えなどは全く対応できない。それはAthenaの現行仕様なので当たり前であるが。

Order by はAthenaでシングルノード処理になる仕様のため、どうしても負荷がかかるのだと開発メンバーがPrestoのマニュアルで見つけたそうである。ということで、出力時の並び替え仕様が満たせない点、別途PandasでCSVの並び替えを行ってもらうことになった。

③CTASは無限ではない。メモリ制限でダメならファイル処理が必要

いろいろ処理の幅が広がったがCTASしても限界はある。3.作成において最大レコードでの2100カラム以上はエラーとなってしまった。これより2.までで作成できた一時テーブルを使って3.を当初検討したAWS EMRで結合処理するように分岐させることにした。出力処理が遅い分には問題がないためである。

ということで2次開発が4月にリリースされ、とりあえず無事に動いている。EMRも結局対応しているので あるが、開発メンバーが能力高いので方針さえ決まれば対応してもらえるのが本当に有難い。

自分の反省としてはReactで少しは役割をもったものの、プログラマーとして力不足だったことが悔しかった。ので次期開発にむけてReactをGW中に再勉強。少しでも手が動くようになっておきたい。

Windows でVisual Studio Code+Typescript実行環境をつくった(参考サイト紹介)

TypescriptをWindows 環境で整えるための方法。完全に備忘録。

技術書典6に参加して手に入れた「りあクト!」第二版。開発が始まる前に思い出して最低限の改修できるようになろうと勉強を始めた(連休を得てもになにも予定がない寂しい日常である)

が、28PからのTypescriptの解説コードを実行しようして思いっきり躓いた。前回の1版はTypescript部分をCodeSnadboxで試したので自前でTypescriptを実行する環境じゃなかった。そこで自分のWindows PCでTypescript実行環境を作っておこうとしたが「りあクト!」はNode.jsに慣れている前提での話なのだからその部分は省略されている。

ということでTypescriptのコンパイル環境を自分で作成した。

基本はこちらのサイトをみて順を追って作成。Typescriptのインストール忘れがちなので注意。この手順だとWindows 環境でも大丈夫。

www.casleyconsulting.co.jp

上記サイトの「HelloWorld.ts」がデバッグで実行できるまで作成できれば「りあクト!」のコードを「HelloWorld.ts」の中身として書き換えて確認できるはず。

ただし、上記サイトで省略されている「tsconfig.jsonの作成」について。ここが設定できないとビルドエラーで先に進まない。悩んで他のサイトにあるサンプルをコピーしてもエラー解消できないので、きちんと調べようとしたら、以下のサイトを発見。非常にわかりやすい。

tyablog.net

以下のコマンドラインで現状のプロジェクトから作り出してくれる。これはありがたい。

tsc --init

これで必要な情報を含んだtsconfig.tsが作成され、ビルドができるようになる。

整えてみて、ボイラーテンプレートであるcreate-react-appが無茶苦茶色々やってくれているのを改めて実感した。

東京クロノスはいいぞ 

Oculus Goを最近使う暇なくしまい込んでいたが先週から充電して準備していた。それは「東京クロノス」というVRゲームをするため。そして本日無事にゲームクリアした。

東京クロノスは公式サイトでPSVR版だけ7月に発売ということもあり、公表していい内容がある程度現在制限されている。しかしゲームの良さを書き留めておきたいので、物語に触れずに書き留めておく。

東京クロノスとは

「東京クロノス」の概要は以下のTwitterモーメントを参照してほしい。

twitter.com

ゲームジャンルとしては「ビジュアルノベル」と言われるもので、参加者は1名。話が進む途中で提示される選択肢で、話の内容が変わる仕組みである。

Oculus Go版を選択した理由

昨年クラウドファンディングでこのゲームを知った際に、ビジュアルノベルでのVRゲーム、かつ複数デバイス対応だと記載があり、その中にOculus Goが含まれていることを知った。

Oculus Goは単独で動作するVRゴーグル。スピーカーも電源も一体となっているため場所を特定しない。値段も2万円台で買えるということで2018年ヒットした。Vtuberの操作などでよく使われるVRデバイスとの違いはこちらのツイートがわかりやすい。

VRカノジョを私は保有しているが、この場合PCと接続して利用する方式のデバイス、WindowsMRで操作した。私はカノジョの部屋の中を歩き回り、手を使ってモノを持つなど操作できた。寝転がってみたり。カノジョの頭を撫でてみたり。

testedquality-tech.hatenadiary.jp

一方Oculus Goは頭の前後左右上下の3方向のみに対応。別途メニュー操作用のポインターデバイスがあるが自分の胴体が移動したことを把握はできない。しかしこの制限によってNetflixなどの映画を寝転がってみても安定した動作でみることができる。

ノベルゲームは長時間続けて行うことが想定される。例えば有名なFateシリーズ初回作品「Fate/Stay nigth」だと標準プレイ時間は60時間。私は産休中ほとんど自宅にいたのだが、1か月を使ってクリアした。出産前だったので何とか時間が確保できたが、子育て&仕事に出ていたならもっと時間がかかったであろう。話を進めるための時間を確保するにもスマートフォンと違って持ち運びもできない。いや無理すれば持ち運び出来るがPC&弁当以外の荷物を増やしたくない。

  1. 少しでも自宅で手軽に遊べるOculus Go版なら進めやすい
  2. Oculus Go版だと他のデバイスに比べ制限がある。どうやってゲームにしているのか?ゲーム内容が非常に気になる。
  3. キャラクター作成が好きな方だったが本当にVR環境でこの絵が動くの?むっちゃデザイン複雑なのに。
このような3点が気になってクラウドファンディングに参加した。先週2019/3/22に無事製品は発売され、ファンドのリターンとしてゲームを受け取った。とはいってもダウンロードキーである。

f:id:testedquality:20190328165946p:plain

東京クロノス感想

実際に始めると、当初主人公目線での動きをすることになる。歩けないので移動をどのようにするのかとおもったら、自動で画面転換していく。はじめはVRなのに移動していく風景が見えないことが少々不満だった。しかし、よく考えたら漫画のコマ割りでの場面転換と一緒だと気づいた。これで十二分に動きを感じるのだ。

あとセリフの表示や人へのかぶせ方も極力人物の動作が見えるように工夫されている。吹き出しの視認性を保ちつつ、人物の様子がはっきり全部見える仕組みが素晴らしい。また誰のセリフか8人全員が場面にいても全く混乱しない。セリフを人物側から投げかける側へ動かす、声の流れる方向をわかるようなUIなどの細やかな表現がストーリーだけに集中させるための仕掛けになっていた。

遠くから人が駆けてくるとき、外をのぞき込むとき。CGでVRなのだからアニメーションでずっと動くかと思えば、ここもまんが的表現を使って最小限の動作とする。しかし代わりに人物たちの表情は非常に細やかである。LAMさんの美しい造形のまま叫び、うつむき、見つめてくる。瞼に揺れるまつ毛の先の震えまで表現されているのは驚愕である。Oculus Go自体はちょっとよいスマートフォンくらいの性能なのだ。既にここで「ここまで近づいてくれるのに気持ちにこたえられないんだよなあ」と主人公と同じ気持ちとなり、魔法のように私は物語の中に取り込まれていることを自覚した。

ただたまに人物が「むっちゃでかくね」と思うタイミングがある。君建物比で5メートルくらいあるぞと我に返るのだ。これは表情を見せるために実際のスケールの3.5倍にしていると、開発者さんのツイートでみかけた。そして実際に人間は目で見たいものだけ見ている便利な機能をもっているため、ゲームを続けていると大きくしているのが気にならなくなってくるのだ。人間の仕組みを利用したよいUIなことの証明であろう。

最後まで所要約20時間かかった。そして想定通り全く全く酔わなかった。VR酔いしやすい人でも一度体験してみるべきだ。非常に考慮された仕組みになっている。

また話の内容としては異世界ものではあるがオーソドックスなSFだと思う。あと倫理観が現代日本なので各登場人物を好きになれる。ぜひ体験をしてほしい。できればOculus Goで。

Amason Athena を業務利用した

2018年後半は社会人で初めて人手不足で忙しかった。人手は足りないのに仕事は増えるで必死に過ごした結果、初めて客先との会議中に寝る失敗をしたりとひどかったが無事2019年を迎えることができた。

夏からメインでやってたシステム、フロントエンドがReactでメインプログラマになり損ねたのであるが、こちらが無事リリースされた。バックエンド側も初めての構成だったがスケジュール費用とも想定内で収まり、かつ開発自体正直面白かった。そこでの知見を書く。

現在業務ではオンプレでSpark準拠のDWH(データウェアハウス)を利用している。UIはなくて各自SQLにてデータを取得する。このDWHのデータをUIで検索できるシステム提供が目的。SQLが書けない人にデータ提供したいのだ。

グループ内はAWSの各種システムが運用されているため、今回も経験者にてAWSでのシステム構築が検討された。しかし一番王道だと思われるAWS Redshiftは今回使えなかった。

aws.amazon.com

実証実験でDB構築して現行と同一速度になるまで課金した結果、月額換算で予算の5倍となることが判明したためである。今回の顧客はそこまでお金がないのでこの方法は取れなかった。そのため再検討でAthenaを利用する案が浮上した。

AWS Athena とはAWSが提供するサーバレスのS3検索システム。S3データをSQLで検索可能となる。

aws.amazon.com

詳細については色々ブログを探したが、こちらの方が2018年の記事でかつわかりやすかったので参考にしていただきたい。

www.casleyconsulting.co.jp

検証である程度の速度が担保できそうということで利用に踏み切った。

【現行システム概要】

データ内容

DWHの1テーブルにある1年間のユーザーアクセスログを検索する。

テーブルをtsv形式で出力して6.7G。年間で5700万レコード。tsvで6.8G。

テーブルのキーは日付、ユーザーID、商品ID。日付と商品IDを検索項目とする。

指定できる商品IDは最大1000。データ内のユーザIDは200万ID。

ユーザーごとに指定された商品IDでサマリー結果を出力する。

ヘッダが商品IDの1000カラム+ID単位1以上の値を持つ場合の0/1フラグで合計2000カラム、出力行数は200万レコードが最大となる。

データ検索と出力イメージ

2019-01-01から01-03までの検索レコードが以下のオレンジテーブルだった場合、出力は緑のテーブルのようになる。今回だとヘッダは3ID,出力レコード数も3レコードだ。

f:id:testedquality:20190119005535p:plain

要件

検索とcsv出力の2機能を搭載する。

検索は同時検索最大10人。かつ1日200回程度の検索を想定。

検索では件数と上位10件を表示、確認後OKならcsv出力を実施。

出力は非同期でOK。同時処理数は最大5JOB。

==================================================================

システム概要より最終的に構成を以下のように実施した。

【Athena構成】

①日付をキーとしたS3構成にする

現行DWHでのデータが日次処理であるため、検索条件と一致させるためS3の構成を 年→月→日 に設定。

②Apatch Parquet形式とする

データをAWSに送る際にはtsv.gzに変換して一日単位で持ってきていた。Athenaに利用するデータ形式は一番検索が早いということで、Apatch Parquetに変換。


parquet.apache.org

以下の記事を参考にしたと、提案してくれた人が教えてくれました。
dev.classmethod.jp

 

変換する際に1ファイルサイズを整えられるらしく、最初は128KBに分割されていた。しかし、試行錯誤中に海外の事例を見つけたメンバーが、1日1ファイルに1か月分を変換してして検索検証したところ、検索速度が半分以下に短縮された。

これよりデータをすべて作り直し1日1ファイルとしてS3に再配置を実施した。どうやらファイルサイズが小さすぎると検索のオーバーヘッドがあるらしい。

最終的に1年間で1.83G程度のデータ量となっていた。

【良かった点】

1.検索速度が現行DWHより早くなった

当初検索する商品ID指定の一覧表を実テーブル化、SQLでLeft join を行った。これは要求元の処理方法だった。

しかしAthenaではJOINするテーブルが増えると極端に速度が遅くなり、途中でメモリ不足となった。Athenaのメモリは提供されいている範囲のみで拡張はできない。要件を満たせないので、悩んだ末DWH利用者に最大IDの削減を相談した際にヒアリングさせてもらった。

そこでIDをSQLに直接指定する形で、集計関数を利用したSQLをExcelマクロで作成して検索していることが判明した。どうやら現場のみこのマクロを利用していたらしい。ヒアリング不足であった・・・・

この時のSQLを現行DWHで件数検索すると1000ID+フラグ1000カラムで5分かかることが判明した。

早速SQLを変更したところ、商品IDがSQLに記載されることもあり、AthenaのSQL文字数最大値「262,144 バイト」に限りなく近づいたが、1年間、1000IDの集計を1分40秒で完了することを確認した。
docs.aws.amazon.com

ぜひ実証実験を最初にやってめどをつけて利用したほうがよい。

2.運用時のアクセス量が少ない時に利用すると、費用対効果が高い

Athenaは従量課金である。それも検索する際のデータスキャン量による。

今回期間指定が最大1年間だが、DBの利用頻度が1日200回程度の検索が想定されている。全員が1年間検索した場合、

1.83*200=372G が1日のスキャン料金となる。

30日で10.96T。課金は1Tあたり5$なので、10.96*5=54.8$  = 6000円弱(110円換算)

この金額でRedShiftを運用できない。RDSだと検索スピードがここまで早くできない。ので費用対効果は非常に良いといえる。

常時利用するようなシステムではないが、データ量は多いとき、Athenaは有効な選択肢だと思う。

3.S3を利用するのでデータ量増大でも費用を抑えられる

S3がストレージとして使えるので、DWHで利用しているすべてのデータが現在約1Tなのだがそれを全部検索対象にしても、現行オンプレの1/5以下に抑えられることが判明している。またストレージでのデータ損失についても安定度が高いこともあり安心できる。

【悪かった点】

1.更新処理ができない

SQLが使えるがUpdate文は使えない。だからデータ修正時にはParquet形式ファイルの作り直しになる。データ不備はありえるため、日次転送用プログラムとあわせてリカバリー用のプログラムを事前準備してもらった。どうしても更新が必要となるUIでの検索情報などの管理部分はAmazon RDSを利用している。

2.メモリを利用しすぎると同一処理数を4以下に削減されることがある
先ほどのサービス制限にAPIごとの「1 秒あたりのデフォルトの呼び出し数」があるが、検索に関わるAPIについては5回と記載がある。

これより同一処理は5件までできるのだと判断。同時処理を5JOBとして管理するように設計した。

開発後の負荷テストでは、検索での件数取得いわゆるcount(*)や上位10件の表示は、前述の1年間1000IDを10人同時に実施して、順次10JOB が正常終了することを確認した。

しかしファイル出力の同時処理テストを実施した際に、1JOBづつのプロセスを5JOB用意し同時に処理させたところ、4JOBしか処理されない現象が発生した。

コンソールには4つのJOBしか出てこない。初めは「JOBを設定し損ねた?」とテスターが確認し、1JOB追加してみたがコンソールには出てこない。そのうちテストと平行で検索をしていた私は、画面での件数チェックでシステムが返答しなくなったのを確認して、Athenaがなんらかの障害を起こしていると判断した。

処理を一度中断させて、サポートにJOBの動作について確認を実施したところ、

「メモリ利用量によって、最大のJOB数を変更するのは仕様である。サービス制限のページに書かれている5JOBは、あくまでもデフォルトの呼び出し数であり、メモリ利用状況によってこの数を変更することはある。」との返答を頂いた。

5JOBの要求満たせないじゃん!

と返答のメールをみて開発者全員で天を仰いだ。

今回は4JOBでサービス制限がかかってしまい、Athenaのサービス全般が停止したのだ。これにより検索など画面に利用する部分の処理も待機、システムが停止することになったのだ。

サービス停止するJOB数を同時実行させるわけにはいかず、想定最大のSQLを全員が実行したときを考慮し、同時処理数を3JOBまで減らすことにした。お客様も普段AWSを利用していて状況を把握していただいたこと、出力処理が遅くても問題がないことよりご了承を頂けたのが幸いであった。負荷テストして本当に良かった。

Athenaのメモリ利用量の制限値は非公開のため、ここは負荷テストにて利用時必ずチェックしないといけない。

【まとめ】

ということで、Athena によってシステム構築をして満足している。DBよりチューニングできる箇所は少ないが、AWSが提供する潤沢なリソースを割安で利用できる点で検討に値すると思う。お客様からも早さと安さで高評価を受けていてちょっとうれしい。

あと、今回はAthenaを提案してくれたメンバーのおかげであるので、メンバーに感謝している。選択したとき、他部署の人はだれもそれをよしとはしなかっただけど、無事顧客に価値を提供できたのですべてよしである。

第12回 SQL Server 2019勉強会(1st Anniversary) に参加してきた その2

昨日途中だったので勉強会の報告その2。今回は途中退席するまでとなるがツイートで思い出して記載する。登壇者小澤さんブログは日本全国SQL Serverの使い手で知らない人はいないはずだがリンクを貼っておく。

blog.engineer-memo.com

先に始まった質問コーナーが一通り終わったので2019詳細解説が始まった。本日のセッションは資料公開がないため、写真撮影をしてほしいとのことだった。しかし写真が下手なのでツイートで文字起こしを兼ねたメモをした。

ここで小澤さんのKubernetesを使ったデモンストレーションが始まった。

2017から対応されたSQL Server On Linux のようなプラットフォーム複数対応、その後Dockerによるコンテナ対応、そして2019になってのKubernetes での利用や多種のDBを直接統合する様子は、まるで塊魂。Data Pratform データ統合ってこういうことかと話を聞きながら感動した。一方もうLinuxを使わずにSQLServer の新機能を使うことはできない。この辺り国内だと多いはずのWindows Serverのみを使っていたエンジニアには本当に厳しいなと思う。

この辺りのデモは小澤さんがAKSを使うのが楽でよいとのことだったので、さっそく来月の課題とする予定。現在IBM旧MSの戸倉さんのツイートが身に沁みる。

小澤さんのセッションは本当に別世界のようにSQL Serverが突き進んでいるのがわかり楽しかった。自分が業務でまた使うかわからないが、勉強だけはしておこう。面白い駆動である。

【初級者、中級者向け】SQL ServerのAzure移行のいろいろ

Ijimaさんが仕事でオンプレのSQL ServerをAzureに移行検討した際の調査結果紹介。まだテスト段階とのこと。

IjimaさんのSQL Serverをサーバリプレイスするにあたって

  • 現行サービスを止めずにデータ移行できること(オンライン移行)
  • T単位のデータ量である
  • サーバ管理者が自分しかいないのでAzureを使って手間を減らしたい

という点が課題。AzureのDBとしては、SQL Databaseがありますが、このDBは単一しか使えないので、インスタンスにDB二つなどオンプレだとよく実施していたパターンにはできない。そこでSQL Database Managed Instanceを調査したとのこと。

ちょうどMSが2日前に移行検討手順と資料を日本語で公開したのでリンクを記載しておく。

SQL Server から Azure SQL Database Managed Instance への移行【11/22更新】 – Microsoft Partner Network ブログ

この記事内にオンラインでの移行検討も記載がある。

IjimaさんはManaged Instanceが高いのでまだ実施までに至ってないということで発表は終了したが、その後皆さんから色々と意見がでていた。小澤さんからはManaged Instanceのもっと安いものが現在開発中との情報もあった。最低ラインで一月10万近いのだ。オンプレ版だとEnterpriseバージョンくらいのイメージだと思う。

また小澤さんが発表を聞いて以下を指摘していた。

移行をオンラインで行う場合通常業務に影響ないように通信経路を確保しないと、移行中に他のネットワーク操作ができないなど業務影響が甚大となる。T単位のデータだと通信帯域確保してないと(ここがExpress Routeが必要になる)いつまでも転送が終わらないかもしれないと、別の方も指摘していた。

ということでSQL Serverの勉強会に久方に参加したが、現状も今後も含めSQL Serverを使うためにまだまだ勉強しようとケツイするくらいには楽しい勉強会だった。また参加したいと思う。