【DQ10】占い師で闇の領界クリア

ドラゴンクエスト10の闇の領界（ver3.3）のラスボス神獣パチャティカを占い師で倒した。
ver3.2（氷の領界）の最初の集団モンスターを思い出す、嫌なボスだった(苦笑) 

ラスボスの1つ手前（闇魔ティトス）はオーソドックスなパーティー構成（攻撃2人＋僧侶＋賢者）で意外とあっさりクリアできたんだけど、パチャティカではいまいち…。
攻略サイトを参考にして攻撃役3＋僧侶1でやってみたけど、蘇生役が1人しかいないのは無理。（そもそも自分の火力が無いので持久戦が好み。達人クエストでもタイムアタック系や死んじゃいけない系は苦手）

結局レンジャー（オノ）＋どうぐ（やり）＋僧侶＋自分で、自分が僧侶・魔法使い・賢者など試したけど、僧侶だとやはり火力不足。
途中のマホカンタやマジックバリアを使ってくるやつがうざいので、魔法使い系も厳しい。下手に範囲魔法を撃つと、しばらく動かないはずの敵まで巻き込んで、止まっていた敵が動き出してしまうし。
なので物理構成が良さそうという訳で、レンジャーが一番いい線いった（戦士系はスキルを振ってないのでレンジャー以外は超弱い）。でもパチャティカが動き出す頃にお供が3匹ほど残っていて、倒せない…。

しかしここで占い師にしたら、結構あっさりクリアできた(笑)
占い師は遠距離から攻撃できるので敵のおたけびも無視しやすいし、単体攻撃も集団攻撃も出来る。しかもマホカンタとか関係ない。
という訳で、占い師の為のようなボスであったｗ

（ちなみに痺れることがあるのでマヒガード100％のサポを選んでみたんだけど、防げなかった＾＾； これなら呪文耐性とかブレス耐性を重視すればもっと楽だったかも）

Scala関西Summit 2016でAsakusaFWを紹介しました

Scala関西Summit 2016（2016/10/8）でAsakusa Frameworkの紹介をさせていただきました。
（→資料、Togetter）

今回はきの子さんから登壇の依頼をいただき、「最近はAsakusaFWしかやってないんですけど～」と言ったら「Scalaと少しでも絡んでいればOK」とのことだったので、少々厳しいかなーと思いつつも、Scalaの集まりなのにAsakusaFWの話をさせていただきました＾＾；
ありがとうございます。
（ちなみに今回、生きの子さんを拝見しましたが、あんなテンションの高い方だと思ってませんでしたｗ） 

資料は去年のJJUG CCC（2015/11）で使ったものからJava8成分を抜いてScala成分（自己紹介）を加えた感じになっているので、大部分は似ています。
ただ、去年の時点で「将来の技術」で「CPUがメニーコア」としていたものに今年対応してAsakusa on M3BPが実装されたので、その紹介を大幅に増やしました。
（もしJJUGとScalaでの発表が逆だったなら、去年ScalaでAsakusa on Sparkを紹介し、今年JavaでAsakusa on M3BPという順序になり、良かったかもしれない…） 

今回はJJUGのときよりは少しはまともに喋れたかなーと思うんですが…、振り返ってみると、資料に書かずに口頭で補足しようと思っていた内容がかなり抜けてましたorz
道理で、想定より5分も早く終わったわけだ…。

なのでちょっと補足しておきますと、まず、バージョンはHadoopは主に1系、Scalaは2.8～2.10、Sparkは1系の知識です。あ、AsakusaFWは最新ですｗ

M3BPは、分散処理へのアンチテーゼとも言えるかもしれません。
基幹業務のバッチ処理なら実際はそれほどのデータ量じゃないよね、だったら分散処理する必要がないよね、という。
HadoopやSparkはやはりビッグデータ、すなわち数百とか千ノードをターゲットにしているので、構造や設計は当然それを考慮しているんですよね（十数台のような小さなクラスターの性能向上には興味がないらしい？）。
千ノードもあれば毎週だか毎月だかで1台は必ず壊れるらしいので、耐障害性なんかも現実的に考える必要がある。でも十数台くらいなら滅多に壊れないので、耐障害性にリソースを割くのも少々もったいない。
そんなわけで、サーバー1台のメモリー量も数百GBと増えてきたので、M3BPのように1台で（マルチスレッドで）処理するという揺り戻し・逆張りをしてみたという感じですかね。

あと、いくつかのバッチをピックアップして実行時間を紹介しましたが、複数バッチを実行する日次処理全体（つまり各バッチの平均）では、MapReduce（スモールジョブ実行エンジン込み）→Sparkが約1.6倍、Spark→M3BPは4～5倍の速さになっています。
CPUは88プロセッサーですが、実行時には1バッチにつき22プロセッサー（全体の1/4）だけ割り当てました。データ量的な問題だと思いますが、プロセッサーをたくさん割り当てても（マルチスレッドでスレッド数が多くなっても）、プロセッサー数に応じた性能は出ませんでした。

それと、Scala関西Summit 2016のスポンサーにさくらインターネットさんの名前が入っている事に気付いたのでちょっと宣伝してもいいかと思ったのに忘れていたのでここに書いておきますが(爆)、自分が使っているM3BPマシンのスペックは、高火力コンピューティングというサービスの次バージョンで採用予定のサーバーと同スペック（メモリーは最大で1TB積める）らしいです。
今入手しようと思ったらまだ高価だと思いますが、試用する手段はあるということですね。 

---

今回は懇親会にも参加させていただきました。
色々な方に声をかけていただき、また、うらがみさん・よこなさん・だいくしーさんといった有名人にも会えて感激です(笑)（うらがみさん、超ハンサムやったで～！ｗ）

「Hadoopは聞いたことがあったけどSparkはあまり知らなかったので勉強になった」という方もいて、色々な話題を入れた甲斐があったというものです(笑)

そんな中で驚いたのが、参加者に若い人（大学生や社会人1年目とか）が意外と多いということです。
今回の資料には、NoSQLやCAP定理のような、今回のテーマとは全く無関係すぎる話題も余談として入れていました。「昔話題になってたけどこの分野を知らない人は知らないだろうなぁ」とは思っていましたが、「ビッグデータブームというものがあった」ことくらいは知っているだろうと（無意識に）想定していました。しかし若い人だと、それすらも知らない可能性が高いですよね。
いやあ、無意識に前提を敷いてしまうのは怖いですねorz

あと、AsakusaFWでは出来るがScalaでは出来ないよ、という例（分岐（AsakusaFWのBranch）。filterで条件を満たしたものとそうでないものを同時に出せないと話した）に対して、Scalaならpartitionやfoldを使えば出来ると教えていただきました。
partitionは失念していただけですが、fold（厳密にはfoldLeftやfoldRight。foldそのものでは出来ない）で複数の出力を作るという方法は全く思い付きませんでした。
うーむ、素晴らしい。関西の技術者の実力をしかと見せていただきました。
さっそく自分のウェブページにfoldLeftの例として追加させていただきました(笑)（このようにして少しずつウェブページの内容が増えていくのですｗ）
ちなみに、Asakusa on SparkではBranchを処理するのに独自RDDを作ったらしいので、そんなことしなくてもこのfoldLeftの方法でいけるんじゃね？！と思ったのですが、Sparkのfoldでは零元としてタプルやMapを渡すことが出来ない（Scalaのfold（並列処理用）でも渡せない）ので、無理そうでした。残念。

それから、懇親会でLTがありましたが、opengl-8080さんの『ScalaでFizzBuzz』、なぜ予備知識でアセンブリ言語・CASLが要るのか！超ウケました(笑)

---

スタッフの方も大勢いらして、お疲れ様でした。
大変有意義な時間を過ごさせていただき、ありがとうございました。