2017年のクラウドを占う

どうもあけましておめでとうございます、分散システム界の負け犬こと李徴・ザ・グレートタイガーです。どちらかというといきなり吠えつくよりも山に篭ってこじらせていくタイプです。新春からAWS,サーバレス,コンテナ,マシンラーニング …2017年のクラウドを占う:新春特別企画|gihyo.jp … 技術評論社という記事を目にし、「ウソはいけません」とコメントしたところ何が本当で何がウソか分からなくなってきたので、わたしも2017年のクラウドを占いつつ、件の記事の批評をしてささやかながら新年の書き初めとしたいと思います。

🔥🔥🔥🔥🔥

件の記事ではまず、

そしてこのデジタライゼーションの基盤にあるもっとも重要なテクノロジがクラウドコンピューティングです。

という言葉から理解できないのだが、デジタル化とは何を指すのか?一昔前には「OA化」という言葉が一斉を風靡した。どの企業でも小売なら会計はPOSだし、クレジットカードはどこでも使えるのは、20世紀の時点で達成されている。ビジネスにコンピューターを使うという意味であれば、今更ということではない。…が、クラウドコンピューティングという言葉が出てきているし、この記事がクラウドを主題としているので、おそらくクラウド化のことを指しているのだろうと思われる。

それではクラウドとは何か? ここではとりあえずNISTがいうクラウドの定義を採用するとして、その直後に「レガシーを多く抱える企業にとっては,クラウドへの基幹業務の移行がビジネス再編の大きなカギになるとも言われています」とある言葉はどういう意味だろうか。レガシーというとスバルの車種が最初におもいつくが、レガシーシステムのことだろうか。一般的にはこれは自社がオンプレミスまたはホスティングで抱えている、NISTの定義に当てはまらないコンピューターシステムのことだろう。レガシーな基幹システムをクラウドへ移行することが、自社ビジネスを再編するために必須という主張だろう。

次に分からないのは

S3のデータに標準的なSQLで直接アクセスできるAmazon AthenaはフロントにPrestoをバックエンドにLambdaを使って構成されている

という写真のキャプションだ。PrestoDBを知っている人間なら分かると思うが、PrestoDBは各種DBやファイルフォーマットに対してSQLでクエリをかけられるという便利なもので、ParquetやORCなどを直接読み書きすることができる。S3のクライアントもかなり前に入っている。なので、その間のどこにLambdaが入る要素があるのか自明ではない。
Amazon Athena User Guide — User Guideを簡単にナナメ読みもしてみたが、独自のAPIを持っているということでもなく、管理コンソールとPrestoDBのJDBCドライバーがあるだけのようだ。うーん、どこにLambdaを使うのだろうか…使うところないんじゃないかな…

Evernoteについては当初「サービスローンチ以来,すべて自社データセンターでサービスを提供しており,パブリッククラウドはいっさい使わない」と書かれてる。これを読んですぐに私が違和感を持ったのは、元社員らに聞く「エバーノートはなぜ深刻な状況に陥ったのか」(前編)原文 "Evernote is in Deep Trouble")を以前見ていたからだ。同社は自前でAS番号をとるほどオンプレミス、自前のシステムに力を入れていたが、実際にはやる気やコダワリがあったのではなく単に迷走していただけなのだと思う。Evernoteというウェブサービスの全体像を考えると、GoogleFacebookのように高度なシステムは必要ないことが分かったが収穫で、役割はもう終わったのだろう。

記事が出た直後、山口さんの指摘を受けて「しかし2016年9月にこれまでの方針を変更し,Google Cloud Platformへの移行を新たに発表している」という記述が追加された。これはEvernote社の『「どうしてもパブリッククラウドには載せられないワークロードがある」という主張』が変わったことを意味するので、このリストに掲載し続けるのは不適切だろう。

Appleについては「プライベートクラウド上でコンピュートサービスやエナジーサービスを運用する」とある。プライベートクラウドを実現するソフトウェアはCloudStack, OpenStack, Eucalyptus, VMware などが代表的であるがそのどれも利用しているという話を聞いたことはない。本当なら興味があるが、どこかに一次資料はあるだろうか?

問題のきっかけとなったNetflixについては「AWSのほかにGoogle Cloud Platformも併用」とある。GCPの併用については Netflix Backing Could Pump Up Google Cloud Vs. Amazon | Stock News & Stock Market Analysis - IBD くらいしか裏をとれる資料がなかったのだが、Spinnakerで協業したよという話しかないように見える。写真のスライドはNetflixの社員のものではないようだしよく分からない。

続く文章に「一方でDVDビジネスやストリーミングCDNといったワークロードはプライベートクラウド環境を別に構築して稼働中」とあるのだが、わたしはこれは誤りだと思う。スライドを丁寧にみると "Private" としか書かれていないので、これは普通に英語を読んだらオンプレミスシステムのことだろう。DVDレンタルはNetflixからみるといわゆるレガシーシステムでレガシーサービスなので、わざわざそれだけのためにOpenStackなどのプライベートクラウドシステムを構築するとは思えない。実際、元Netflixの人が Episode 216: Adrian Cockcroft on the Modern Cloud-based Platform : Software Engineering Radio で「ちょっと分散システムの実験したいときに200台のサーバーを10分くらいで立ちあげれるのはすごいアドバンテージだよね」と語っているように、彼らがクラウドという言葉を使うときはElasticityが最も重要なのである。だから、DVDレンタルのためだけに(例えば)OpenStackを構築して移行するなんてあり得ない。

CDNについては北米のインターネットトラフィックの37%をNetflixが使っているとかインターネットの形が変わっているという事実を知っていれば、『「どうしてもパブリッククラウドには載せられないワークロードがある」という主張をする企業もあります』というよそよそしい表現にはならないはずだが…AWSがハイパージャイアントになる日が来るのと、日本中の男性がExileになるのと、人類がAWS上に仮想化されてしまうのと *1、どれが一番早いかなあ。

それでも、それでもNetflixならやってくれると俺たちは信じていた。そう信じさせてくれるプレスリリースもあった。だから、CDNはともかくDVDレンタルももうAWSで動いていると思っていた。だから指摘を貰ったときは非常に驚いた。

リンク先の記事を読んでみるとたしかに "exception" という言葉につづいてザックリ書かれていたので、移行完了という簡単な言葉で割り切れるものでもなかったようだ。

この企業紹介、私ならまっさきに楽天ファーストリテイリングを挙げて対照性を論じるけど、そっちの方が面白いって思う人は少数派かな?

次のコンテナという言葉についても疑問がいくつか。

2016年はコンテナの活用が進み,米国ではテスト環境だけでなく本番環境でのアダプションも劇的に増えつつあります

どうして「採用」と書かずに「アダプション」となっているのだろうか。何か特別な意味でもあるのかな? また、続く文章で「AWSやAzureといったパブリッククラウド上で使われることがメイン」と書かれているが、GCPでも当然ながら各種コンテナがサポートされているので、併記されないのはどうしてだろうか? さらにContainer-optimized VM imagesというものが出ているし、Borgの論文にもあるとおり、Googleは全てのOSをLinuxカーネル上の自前コンテナ上で動かしている。その独自実装の上に普及している各種コンテナのアダプタを乗せる方が、XenベースのAWSよりもかなり効率がよいはずで、どうしてここでは言及されないのか分からない。採用事例のデータがあるということだろうか? 2017年はOCIが決まってDocker側が歩み寄ってコンテナ業界はより平和になるだろう。

OpenStackについては私は未来はないと思う。多くのベンダの思惑が入って複雑になっているという印象が強く、完全仮想化ベースのシステムでは効率があまりよくない。それで仮想ネットワークまでサポートして、要件がコンパクトにまとまらない、グローバルにみてユーザーが少なく、中〜小規模のパブリッククラウド事業者か、Walmartのような巨大企業くらいしかない。前者はこれから順に淘汰されていくだろうし、後者は将来的にMesosやYARNのように、より効率のよいデータセンタースケジューラにワークロードを移していくだろう*2

DevOpsについては、SoEとSoRを分けない限り議論することに意味はない。SoRなシステムでそういうナウいものが採用されることは今後世界中のどこでもあり得ないだろうし、SoEなシステムについては、DevOps的な改善手法を採用しないところは早晩淘汰されるだろう。あとは個別論になるので、新春の概論記事としては必要ない。そこまで注目するほどのことだろうか? わたしはSREという職種がどのように普及していくかの方が興味がある。

そして、最後のまとめの「AI/マシンラーニングやFinTechなど,2016年に話題になったテクノロジはいずれもクラウドを前提にしています」という一文が私にはどうしても理解ができない。どうしても理解ができない。

まず、なぜ「マシンラーニング」であって機械学習ではないのか。先程のアダプションといい、特別な意味があるのだろうか? MapReduceやSparkといった分散処理のミドルウェアが発達し、学習データの量が劇的に増えたことが急激な発展を助けたことは事実だ。しかし、機械学習の理論と実践は分散処理とは本質的には関係ない。2010年頃から分散処理と密結合した機械学習システムはいくつか登場してきたが *3、基本的にはBSPに変形できれば分散処理はできるので、理論的に何かが前提になっているということがあるだろうか? 反例として Retty流『2200万ユーザを支える機械学習基盤』の作り方 - Qiita を挙げておきたい。

次にFinTechだ。フィンテックといわれる領域は大きくマイクロ会計サービス(Moneyforward, Freee, 古くはZaimなど)と、Bitcoinを始めとするブロックチェーン技術に二分される(追記あり)。前者はいわゆる典型的なウェブサービスなので、クラウドを前提としているということはないと思う。トラフィックが急激に増減するようなケースがあるか?というと、ソーシャルゲームと違ってむしろ流行り廃りがなく継続的に使われる類のものであるから、クラウドサービスの根本的な価値であるマシンリソースのプール化とはあまり関係がない。ウェブサービスのスタートアップが物理サーバーをいちいち買っていられないのでクラウド使っています以上の意味はないとすると、何が「前提」なのだろうか?

後者のブロックチェーンについては、おそらくPoWの実現に膨大なマシンリソースが必要なことを指して「クラウドが前提」だと仮定しても、たとえば現在のBitcoinのマイニングはほとんどASICで計算されていて、AWSのEC2を使ったとしても報酬以上のコストがかかる(誰もやってないでしょ…)ことが分かっている。ので、ブロックチェーンのシステムで本質的にクラウドでなければならないことはない。というか、ブロックチェーンの技術については世間で言われているほどの可能性はないので、2017年か2018年にはなかったことになっているのではないかというのが私の予想だ。破壊的イノベーションの一例に持ち出すのは適切ではないと思う。

🔥🔥🔥🔥🔥

記事は全体を通じて、「クラウドに行くか行かないかが問題ではない、いつ行くかが問題だ」「アメリカはこんなに進歩している、日本も乗り遅れないと滅んでしまう」といった論調で占められている。わたしの意見はもっと否定的で、2017年に日本人がクラウドへ昇っていくことはまあそんなにないし、世界がそんなに変わるかというとそうでもないだろう。クラウドへの移行が進むとかそういう話ではなく、いわゆるクラウド事業者にシステムを移せない人は、今年それが変わることが何かあるかというと疑問符がつく。

それには2通りの理由がある。まず技術的な問題だ。端的にいうと、記事中でメガクラウドと言及されている事業者はいずれも、自分たちの基幹ソフトウェアをひとつもオープンソースソフトウェアとして公開していない。じゃあOSSにしたら信用できるかというとそうではなくて、彼らのクラウドサービスが大量のソフトウェアが密結合していて、適切な粒度で公開できないからだ。また、適切な粒度で切れないので、各種仕様もおそらくかなり流動的で、何か障害があったときに根本的な原因を説明できない。おそらく障害時に社内では詳細なレポートが共有されているだろうが、社内の独自システム、独自ソフトウェア、独自ハードウェアのコンテキストが多すぎて対外的には読めたものにはならないだろう。そして、そういう障害は社内の多くのシステムが関わっているために、おそらく全体での再現は不可能だ。だから、最終的には「いろいろあったけど直りました」とレポートすることしかできない。分散システムの実装、運用は本当に地獄ですよ。

次は規制面での問題だ。AWSSOCレポートの提供やFISCの「金融機関等コンピュータシステムの安全対策基準」への対応をたしかにやっていると表明している。しかしSOCレポートを作成した第三者機関はアメリカのErnst & Young LLPというところが作成していて、それをそのまま日本で関係省庁に提出するだけでよいのか、また、リスクに対する詳細な説明になっているのか心配だ。一度クラウド事業者の提供するSOCレポートを全部読んでみた方がよいのだろう(読めるのか?)

FISCの安全対策基準、本冊子は有料なのですぐには手に入らないからまだ読んでいない。しかし、これへのAWSの対応は、レポートが公開されており、ういった規制への対応は評価したい。しかしながら、残念ながら安全対策基準がオンプレミスのシステムを前提に書かれたものが多く、基準とそれに対する回答が全然合っていない。オンプレミスシステムでの回答であれば前提が共有されているので対応策を一行書くだけでも回答になりうるが、仮想化されたマシン、ネットワークが複雑に絡み合った全く異なるアーキテクチャでは簡単に回答できないはずなのに、こんな感じである。

f:id:kuenishi:20170103002316p:plain
List of Measures are Copyright © 2012 The Center for Financial Industry Information Systems. AWS Responses are Copyright © 2012 Amazon, Inc.

ぇそれでいいの…?!みたいなのがずーーーっと続く。これで準拠してるって言っていいものなのだろうか。わたしはこちら方面は素人なので是非だれか専門家に解説してほしい。素人意見だが、もしわたしが銀行の情シスで、これしか資料が来なかったら「ナメんな」って怒る。

FISCでもクラウド利用についてはある程度議論がされていて、これ自体はああそうだよねと納得できるものである。ここでも、クラウド利用のリスクとして「インシデント対応の不十分性」(P37)が指摘されており、その対策として金融機関主導の監査が必要(P41)と言われている。メガクラウドといわれている事業者のどこかでも、これ本当にどこまでできんの?!って思う。時代が変われば規制も変わるかもしれないけど、世代が入れ替わるまで待つしかない類のものだ。


じゃあ、ホワイトハウスプライベートクラウド大人買いしたように、日本がそのようにIT投資が進んでクラウドにどんどん移行して欧米に追いついていくことがあるだろうか?またそうするべきだろうか?というと私は否定的だ。日本の人口はこれから減って1億人を切ると言われていて、一方で北米、欧州、インドなど英語および欧米圏の人口は合計すると20億人程度だ。市場のサイズに20倍の差があるのだから、まあちょっと考えれば否定的な結論しか出ないだろう。日本で0から出発してコンピュータに投資し続けたウェブサービスGoogleFacebookのようには成功しにくいのが現実だ。

それでも希望を持って何か言うとすれば、コンピュータ技術やITサービスではなく、トヨタ楽天ファーストリテイリングニコンのようにコンピュータ以外で世界的に競争力を持っている会社が人的資源、物的資源をコンピュータ技術に集中的に投資して世界的に成功し「コンピュータに投資しない限りチャンスはない」という理解が経営層に広がることが、イノベーションとかディスラプションとか各種バズワード以前に重要なことではないだろうか。そして私も、微力ながらそれに携わるコンピュータ技術者であり続けたいと思うし、2017年に何かきっかけでもないかなと期待しているところだ。



(追記)

フィンテックといわれる領域は大きくマイクロ会計サービス(Moneyforward, Freee, 古くはZaimなど)と、Bitcoinを始めとするブロックチェーン技術に二分される」と本文で書いたが、実際のフィンテックには、銀行のAPI解放をもとにした各種サービスの結合、APIの共有化、各種リスク計算の高度化などさまざまな分野があるようだ。読者諸賢においては FinTechセンター : 日本銀行 Bank of Japan などを始めとして広大な分野があることを知っていただければと思う。

参考: マネーフォワード、Open Bank APIの一環として日本IBMの「FinTech共通API」への接続検証を実施~今後、よりセキュアで利便性が高いサービスの提供が可能に~ | 株式会社マネーフォワード

(追記2)

わたしビューの経過をここにまとめておきます。まずわたしが「ウソはいけません」とブコメしたのち、事実と異なるいい加減なことを書くジャーナリストは有害だと感想を述べたところお返事を頂きました。その後わたしの指摘に対する反例のニュースソースを別の方に提示いただいたので、わたしの指摘は誤っていたことが判明したので謝罪しました。件の記事には誤りやウソがなく、五味さんは誤ったことは書いていないので当然、先の私の感想「適当なこと書いてるとその人の評判落とすどころか、世間には有害」は当てはまらないことになります。私としてはこれでできることは済んだと思ったのですが、やはり件の記事には気になるところが多く、それを改めてここでまとめることにしました。もとの記事は、2016年のまとめとしてはある程度内容が網羅されておりますが、2017年のクラウドまわりの展開を予想するに相応しい内容かというと私には分からないことが多かったです。是非それをオンラインで議論できればと思いましたが、うーむ、因果応報ですかね。

*1:順列都市、はやく読まなきゃ…

*2:ポジショントーク入ってるかな…入ってるよね…

*3:Jubatusとかねっ!!!

大都会ではなかった頃の岡山今昔〜

これは大都会岡山アドベントカレンダー2016の23日目の記事です。岡山には合同勉強会 in 大都会岡山のコミュニティがあるそうで、主にその周辺の方が投稿されているところにいきなり飛び込んでみました。知らない人ばかりだと思うので、まずはお前、誰よ?というところからですね。高校時代まで岡山に住んでいて *1 、大学行くために東京に出てきたのが2000年です。

それから東京で就職、結婚、出産、転職などを経て今、ノーチラス・テクノロジーズという会社でソフトウェアエンジニアとして *2 、おもにクラスタ向けジョブキューの開発をしたり、Apache Mesos に関する情報発信 [ 1 ] [ 2 ] [ 3 ] をしたりています。ちゃんと数えたら、次の4月で岡山を出て17年経っていることになります。人生の半分以上をもう東京で過ごしていることになってしまった…とりあえず勢いでエントリーしてみたもの何を書こうか迷って、そんなに若くもないし歴史を語るほどの歳でもないのに今昔とかいうタイトルにして今とても後悔しています。

101ND610-DSC_9145

というわけで、あまりにネタに困ったので、今日は新橋にある岡山のアンテナショップ(鳥取と合同) に息子と二人で行ってきました(上の写真は、その近所にある小川軒という洋菓子店です。レーズンウィッチというお菓子がとてもおいしいです)。アンテナショップというのは、地方の物産を東京で紹介して町おこしの宣伝をするためのお店です。物産館といってもいいと思いますが、最近はレストランやカフェを併設したり、イートインスペースがあったりするものが多いです。地方では当たり前のものを東京に持ってくると割と珍しかったり、ふつうに市場で買うと割高だったりするのが、ここにくるとサクッといろんなものが手頃な値段で手に入ります。僕のダントツのオススメは香川・愛媛の合同アンテナショップ 香川・愛媛せとうち旬彩館 の2階にあるうどん屋です。東京ではなかなかお目にかかれないクオリティのうどんが、学食のような値段で食べられるので近隣のサラリーマンには人気があるようです。

101ND610-DSC_9141

これで420円。いろいろトッピングつけれます。で、この店でいろいろ見つけてめぼしいものを買いました。まずはこれ。フルーツがどうこう、吉備団子がどうこう、言われていますが、岡山に住んでいた頃好きだったものNo.1は蒜山ジャージーヨーグルトでした。

101ND610-DSC_9150

これ昔とはパッケージが違っていて、昔の姿を知りたい方はこちらへどうぞ。

blogs.yahoo.co.jp

この姿を永久に保存したいので 魚拓 もとっておきました。新しいパッケージ、外見は郷愁を全く誘わないのですが…レジの同年代らしき兄さんとこの話をしたところ、中身はあまり変わってない様子。イートインスペースで期待を込めてオープン!!11

101ND610-DSC_9152

そう、これですこれ。このクリーム層もそのままでした。レジの兄さんによると箱買いする人も多いようです。パッケージは今は昔でしたが、中身は変わっていなかった!素晴らしい。さて他にもいろいろ買いました。

101ND610-DSC_9164

大手まんぢゅうは妻が好きなので時々食べていて、味が変わっていないことは知っていました。しかしこの後ろの大物、ひるぜん焼そば、なんというか、うんB級ですね…っていう感じでした。これはまあ年に1回くらいでいいかな…

この16年で岡山に何度か戻ってはいるのですが、徐々に情報は増えます。岡山に戻ったときに驚いたことを、驚いた順にいくつか並べてみましょう。

大都会になっていた

幼少時はまだ山陽道も開通していなくて、高速道路も通ってないのでまあ田舎でしたね。岡山駅まで自転車で30分くらいのところに住んでいたのに周囲はまだ田圃も多かったです。日常生活で電車に乗る人は少なく、ほとんどが自動車、バス、自転車などを使って通勤、通学をしていました。地下鉄なんてなかった *3
私が岡山を出たのは2000年でした。ちょうどADSLの普及前夜で、インターネットが庶民のものになるかならないかの頃でした。その頃はまだ岡山は大都会と言われておらず、政令指定都市になれるなんて私は思ってもいませんでした。なので、北区とか南区と言われても一体どこなのか全くわかりません。各区の範囲が広すぎて政令指定都市の無理矢理感が端的に区名に出ているのがとても岡山らしくて味がありますね。

東京で初めて知り合う大学生たちには「岡山って、桃太郎ランドあるんでしょ?行ったことある?」と言われていたのもその頃です。大都会は…いま調べると2006年6月11日放送のNHKトップランナーでアンジェラ・アキがそう言ったことが最初らしいのですが、たしか私の記憶だと、大都会の写真をアップするスレが何度も2chで上がり始めたのは、その頃だったと思います。大都会と言われるようになったのはそういったスレの方が記憶に残っていますね。ところが…数年前に友人の結婚式で岡山に戻ったときは本当に驚いたわけです。

岡山駅西口が本当に大都会になっていた

私の記憶の中の岡山駅はこうでした。

yufuki.cocolog-nifty.com

木造2階建て、時計塔が上にくっついている平和な建物でした。田舎というには少し大きく、都会というには木造ではちょっと不足で、弥生時代からの交通の要衝とは思えない建物。白いペンキがところどころ汚れたり剥がれたりして、どこか親しみのある叔父さんのような風合いのある建物が嫌いではなかったのです。駅前は微妙に綺麗に工事されてはいたものの、よくわからないうざったい時計魚拓)があったりで、嫌いではありませんでした。駅の向かいには普通の商店や民家が並び、少しあるくと奉還町という商店街もありました。奉還町は地元の人がそこそこいて、少し寂れかけてはいたもののシャッター街というわけではありませんでした。

それがなんと、巨大なNHKと巨大なホテル(いやそこに泊まったんだけど)が駅と直結してなんつーか大都会っ!みたいになってしまっていたのです。駅には巨大な2階通路ができてしまってて、しかもそこに大量の自動改札機が並んでてこれじゃあ本当に都会みたいじゃないか、あの寂れた地下通路はなくなってしまったんかい?!と思ったらまだ残っているようなので安心はしました。

岡山駅東口

西口がそう豹変していたからには、東口はもっとすごいことに…と思ったら、あのわけのわからない丸い噴水はそのままだし、まあ住友銀行の建物がまるまるビックカメラになっているくらいであとはあまり変わっていませんでした(地面のブロックは綺麗に敷き直されていたように思う)。こちら側はあまり景色が変わっていなくて、まあ高層マンションが建っているとか、VIVRE21が閉店していたとか、そういうのはありますが、あまり変化していないですね。地下の改札に自動改札機は導入されていたのでしょうか。

むしろまだ旧ダイエーの建物がまだ取り壊されずに居抜きでずっと残っていることに驚きを隠せません。ミスタードーナツもまだ残っているようですね。

国道53号の大カーブ

Street Viewでいうとここです。

ここは以前は交差点ではなくて、交差点の西から南へ大きく曲がるカーブでした。東の道路は計画はされていたみたいですが、そちら側は民家や店舗が並んでいました。夏は道沿いのドブにボウフラが沸いて蚊柱が立っていて、たまに自転車でカーブの内側を通っては蚊柱に裸眼で飛び込んで死にかけるという目に遭っていました。国体をやるためにスタジアムを立て直したようですが、いったいそんな金がどこから湧いてくるのか…

他にも、 OSKフェアレーン岡山 なんかはそのまま残っているみたいです。うーん懐かしいですね。

まとめ

  • 岡山を出て東京でコンピュータ技術者として生計を立てています
  • 岡山、いつの間に大都会(物理)になってたん…?
  • 蒜山ジャージーヨーグルト、昔のままだった(パッケージはオシャレになっていた

*1:途中、父の仕事の都合で何年か留守にしていましたが

*2:そういうロールで役割分担するほど大きな会社でもないんですが

*3:今もない模様

Apache Mesos だよ〜

これは、 Distributed computing (Apache Hadoop, Spark, ...) Advent Calendar 2016 - Qiita の13日目の記事である。

AMPLab発のなかでも屈指の地味さを誇る、データセンタースケジューラとかデータセンターOSと言われるソフトウェア、 Apache Mesos を紹介しよう。この記事も5分ほどで読めるはずだが、その5分が惜しい人は 忙しい人の5分で分かるMesos入門 - Mesos って何だ? をご覧いただきたい。はい、なんというか、非常にわかりやすい。要するに、Mesosを利用するプログラムはMesos APIを叩いていろんなタスクを分散環境で起動、管理できるようになっているわけだ。これ以上のMesosそのものの紹介はもうあちこちでされているので、ここでは違った角度から紹介したい。

  • 他製品との比較
  • 個人の感想
  • 海外のコミュニティ
  • 日本での取り組み

A benevolent social hack

他製品との比較

機能や利用目的がもっとも似ているのは、Apache Hadoop YARN や、 Google の Borg である。ていうか、シリコンバレーではMesosを紹介するときに「GoogleのBorgみたいなもんだよ」と実しやかに言われていたそうである。Borg、オプソでもねーのに論文なんか読んでられねーよっていう人は Borg Paper 感想 - steps to phantasien をざっと読んでいただければ何となく分かるのではないかと思う。MesosとYARNの比較は Hadoop YARNとApache Mesosの違いって何? - 夢とガラクタの集積場 という記事があるが、ちょっと内容が古いのでいくつかアップデートしておこうと思う。

  1. YARNはJava, MesosはC++ 、かわってない
  2. 8日目の記事にもあるとおり、YARNはCPUもリソースとして扱えるようになった。一方でMesosは従来のCPU, RAMに加えてディスク容量、GPU数、ポート番号を標準のリソースとして扱えるようになった。さらに、任意のリソースも追加で設定できるようになった ( Apache Mesos - Attributes and Resources )
  3. YARNは3.0でDockerをサポートするようになるらしい。一方MesosはLXC実装を削除し、独自のコンテナ実装上でDockerイメージおよびAppCイメージをサポートしている。OCIイメージのサポートも開発が進んでいるようだ ( [MESOS-5011] Support OCI image spec. - ASF JIRA )
  4. リソースの要求モデルは…変わっていない。YARNはリクエストベースだが、MesosはResource Offerという仕組み。
  5. 今日のmasterでYARNは17万行(ただし hadoop-commonが35万行)、Mesosはレポジトリ内だけで35万行。これは結局「Hadoopとは何なのか」という古くて新しい問題に帰着するのではないか。
  6. YARNは自動的にデータ局所性をサポート…ってどういうことなんだろう?アプリケーションが近い場所にデプロイされるってことかな?そもそもMesosはデータ持たないんだが…いちおう、Mesosは1.0 からKubernetesのPods用にTask Groupというのが実装されて、複数のコンテナを同じノードにデプロイして生死を共にさせることができるようになっている。
  7. ドキュメントは…わたしはYARNのドキュメントは追ってないが、半年前はちょっとお察しであった。変化の速いソフトウェアにありがちなことなので仕方がないだろう。一方、Mesosのドキュメントは基本的な考え方だけきっちり書くようにしてあって、変化に強いドキュメントだと思う(細かいところはコード見ろ、MLで訊けもという)。
  8. YARNも3.0でより広範なアプリケーションをサポート(Native Service? というやつ)しようとしているらしい。一方MesosはWindows Serverで動くようにもなった(ホントに動くのかね…)。
  9. オマケ: HadoopはCDHやHDPなどのディストリビューションあってのものだというのはその通りで、Mesosはそれがなくて不便だったのだけど、最近はDC/OSというのが出ていて、この上でHadoopでもCassandraでも何でも便利に動くようになっているらしい。

コード量比較

Mesos

$ git clone git://github.com/apache/mesos && cd mesos
$ find include src -type f | egrep "(pp|js|java|py|sh)$" |  xargs wc
(snip)
    1056    3681   30466 src/zookeeper/group.cpp
     710    1885   17320 src/zookeeper/zookeeper.cpp
  351467 1067690 11037544 total
$ git log -1 -n 1
commit ea45930db15143ca25ef114a5cb68f86af2d1eb7
Author: Vinod Kone <vinodkone@gmail.com>
Date:   Mon Dec 12 17:07:58 2016 -0800
(snip)

YARN

$ git clone https://github.com/apache/hadoop
$ find include src -type f | egrep "(pp|js|java|py|sh)$" |  xargs wc
(snip)
      26     152     998 ./hadoop-yarn/hadoop-yarn-ui/src/main/webapp/tests/unit/utils/sorter-test.js
      62     256    2350 ./hadoop-yarn/shellprofile.d/hadoop-yarn.sh
  174426  566283 6884187 total
$ git log -1
commit 754f15bae61b81ad3c2e3f722d1feaebf374e2c4
Author: Mingliang Liu <liuml07@apache.org>
Date:   Mon Dec 12 17:36:52 2016 -0800

    HDFS-11226. cacheadmin, cryptoadmin and storagepolicyadmin should support generic options. Contributed by Brahma Reddy Battula

個人の感想

Mesosにはいくつか設計で筋のよい点があって、

  • アプリケーションの状態を管理しない(冗長化フレームワークとかアプリでやってね)
  • 最低限のことしか保証しない(タスクの起動、状態遷移、最終的な回収、etc)
  • プリミティブで切れのよいAPI(Resource OfferやEvent streamなど)
  • たいていの故障では、システム全体が落ちることはまずない

あたりだ。順に説明していきたい。

まず、Mesosを利用するのはフレームワークという仕組みで、Mesosを利用するMarathonとかユーザー手製のフレームワークとかがある。MesosのScheduler APIを使っている限り、これらの状態や永続データをMesosが管理することは基本的にない。非常に原始的な永続化機能として、Persistent VolumesやReplicated Logがあるが、これは永続化する仕組みの典型的なトレードオフ(データ量 vs 耐障害性/可用性 vs 性能)のどれかを正しく選んでねというに留まっていて、「ここにとにかく何でも突っ込んでおけばOK!」ということにはならない。こういう設計思想は、分散システムとかコンピュータの中身とトレードオフを正しく理解している人からしか出てこない。

当然、始めからできることを限定しているので、難しいことはやらない。ひとつのことを上手くやるというやつである。Mesosが保証しているのは、Masterの可用性 *1の範囲でクラスタ全体の動作保証だ。それから、いくつかLinuxの機能を使いながらタスクのIsolationや最終的なタスクの回収、フレームワーク間でのDRFに基づいたFairnessなどだ。

それから、いろいろなAPI呼び出しなどは基本的に at-most-once セマンティクスであり、成功するまで利用側がリトライするものだ。Mesosからの通知は「いつでも欠落するよ〜、自分でちゃんと状態確認してネ」といった具合である。これは、フレームワーク側やアプリ側もいつでもノードが落ち得るわけだから、メッセージの通知側が配送保証しても意味がないという割り切りである。

YARNとの比較でいうと、感想を聞いた感じでは、YARNは「とにかく起動に時間がかかる」ということのようだ。重量級のフレームワークで、MapReduceやSparkを動かすのに多くのパスを通っているのだから仕方がない。一方でHadoop系のプロダクトとの相性の良さは折り紙つきだ。3.0ではサービスディスカバリやら何やら、何でも入りになっていきそうな感じである。

一方でMesosはUnix的なミニマリズムが根底にあって、ちょっと何か動かしたいときはサクッと動く(個人の感想です)。ただしこれは拙作のMesos フレームワーク Retz をうまく使ったときであり、他のフレームワークは目的が違うものも多く一概にはいえない。それでも、Retzはそういうレスポンスのよさに気を遣って開発していて、コンテナで動かすときは本当に1秒〜数秒でサクッと起動できるように作ってある(もちろんコンテナがFetch済とか、いろいろ条件はつくが)。

海外のコミュニティ

MesosCon Europe / US / Asia

MesosはLinux Foundationがバックについているので、年三回、世界3箇所でMesosConというカンファレンスが開催される。もちろん最大のものは MesosCon North America だが、 MesosCon Europe もそれなりに盛り上がっているようだ。

MesosCon Asiaはまだ一回しか開催されていないが、シングルトラックながら二日間もずっと話が続いていて、中国やインドの大規模ユーザーがボコボコいるだけの勢いを感じさせる。日本みたいな老人の島国と違って、人口がモリモリ増えている大国は勢いが違う。わたしも何か引っさげて登壇したいところであるが、いかんせん海外のカンファレンスはハイレベルである。今みたらAsiaはスライドもビデオもあまり公開されていないっぽいので、やはり一度行ってみる必要があるのかしら。。。

主要プレイヤー

コミット数やMLの参加量などをみると、 Mesosphere, Twitter, Apple, IBM などが大きな割合を占めていることがわかる。それぞれ紹介しておこう。

  • Mesosphere - 最初の開発者Benjamin Hindmanが設立したMesosとDC/OSの開発会社
  • Twitter - 最初の企業ユーザー。以降、多くのエンジニアがMesosphereに移籍した模様
  • Apple - Siriのバックエンドに採用 *2
  • IBM - 外から観測しているだけだと Powered-by のページにも入っていないし、よくわからない。Linux Foundationからの流れから使っているのか、それとも中で使っているのかな?

また、MSとHPEがMesosphereに$73.5Mという巨額の投資をしている。MSはAzure Container Serviceを出しているので分かりやすいが、HPEは果たしてどういうつもりなのか興味深い。OpenStackを手放しながらクラウドではMSと協業するということだが、Mesosにどう関わっていくのか(それとも関わらないのか)ちょっと想像つかなくて興味深い。

日本での取り組み

Mesosの論文が出たのは2010年で、2011年にはいちど目を通していた(気がする、内容は忘れた)が、日本で最初に観測していたのは3年ほど前の sonots さんの記事と、 yuukiさんの記事だ。論文の話とはちょっとコンテキストが違っていて、いわゆるウェブサービス on Docker の文脈でどうクラスタにアプリケーションをデプロイしていくかという問題に対して、パーツのひとつとして取り上げられている。当時はAnsibleやChefをEC2上で使うのが一般的で、Kubernetesもなかったのでオンプレやホスティングでどうすんの〜まさかOpenStackですか?!という残念な状況だったからMesosが多少期待されたのも仕方がないと思う。それから1年くらいして 第1回 Apache Mesos勉強会 - connpass も開催されたようだ。

で、時は流れて2016年、私が適当に紹介したのが最初の、新しい文脈ではないかと思う。つまりApache Sparkも動くし、他のいろんなアプリもひとつのクラスタ上で仮想化なしでAPI化させていろいろな大規模データ処理を動かすことができる便利なシロモノという文脈だ。MapReduceはたぶんかなり頑張らないと動かない(というか、実装があるというだけでオドロキ)。

というわけで Mesos勉強会 - connpass を開催して、200人近く人が集まるという驚異の事態になった。これはいけるかもしれない、 Mesosソースコードリーディング - connpass というのも始めてみた。第1回が明後日開催されるので、さらに中身を詳しく追ってみたい方は参加していただくとよい。

*1:Quorum/Paxosと、ZooKeeperが正しく動作している限り

*2:一方、某社はEC2で頑張った

2016年のまとめ

これは pyspa Advent Calendar 2016 - Adventar の記事です。昨年のアドベントカレンダーから自分の2015年まとめを見てみたが、大したことしていなかった2015年に比べて、今年はいろいろやった。書いてみたらすげー長い。

101ND610-DSC_7589

スプラトゥーン

www.instagram.com

かなりの時間を溶かしたと思う。夜の予定があいたときはだいたい2~3時間ほどやっていたので、ざっくり一年、週4日で計算すると 50 * 4 * 2.5 = 500 時間ほどプレイしたことになる。500時間やってもまだカンストしてないなんて雑魚と思われるかもしれないが、もともとこういったアクションゲームが苦手でやりこんだことが一切なかった(上手い奴に負けるのが分かっていて口惜しいからやらなかったともいう)。しかしながら、この歳になると何かしら趣味をみつけたくなるもので、新しいことに挑戦してみて、脳のこれまで使ってなかった部分を開拓していく感覚が面白くてついつい続けてしまった。なかなかS+になれず、負けて悪態をつくこともあり妻の顰蹙を買いながらも続けてしまった。こんなにゲームに夢中になれたのいつ以来だろうか。つい先日、目標だったS+にもやっとなれたので、なんとか年内に一区切りつけることができた。


スプラトゥーン S 赤ZAP ガチエリア@マヒマヒリゾート&スパ / Splatoon S N-ZAP89 Splat Zones@Mahi-Mahi Resort

あー、この頃はヘタクソだったなあ、今もヘタクソだけど。さて来年にはNintendo Switchが新作スプラトゥーンと共に発売されるという。またやるのか…?

アニメ(とその関連メディア)

これも、かなりの時間を溶かしてしまった。手元のメモを振り返ると、新旧アニメ、OVA込み込みで52本観たとある。冬完走しそうなやつも合わせると60本近くになるだろう。それぞれの感想は別途まとめた。今みている秋アニメは全部終わってから別途書く予定。

kuenishi.hatenadiary.jp
kuenishi.hatenadiary.jp
kuenishi.hatenadiary.jp


オレ基準でダントツ面白かったのはアルスラーン戦記1期、デート・ア・ライブストライク・ザ・ブラッド、東京喰種、東京喰種√Aぐらいだろうか。今年制作のやつあんまないやん。これも50本 x 12話 x 20分 = 200 時間ほどは溶かしたことになる。いったいどこからこんな時間が湧いて出てきたのか。その答えは後半に。

トレーニング

体脂肪率は20%を切ってある程度健康になったので昨年の目標は達成できたと思う。今年はベンチプレスやチンニングなど標準的な科目の強度を上げていって、パワーをつけていこうとした一年になった。いずれ絞らなければならないのが課題なのだが。記録が残っているので、簡単に1年前と比較してみたいと思う。

2015E 2016E
体重 70.0kg 73.1kg
体脂肪率 18.3% 17.7%
ベンプレ 45kg 65kg
CoC N/A #1

今年の前半はわりとヒマだったのでジムに週2で行けたのだけども、後半になって仕事が増えて(アニメやゲームで夜更かしして)時間をとりにくくなって週1が怪しい現状でよくキープできているなというのが正直なところだ。ベンチプレスで自重を上げるとか、チンニングを満足にできるようになるという目標を1年かけても達成できていなかったのが悔やまれる。それぞれ課題は分かっていて、ベンチプレスは単純に頻度が落ちたことが原因だ。神経系の開発が一段落してこれから筋力を増やさないといけない段階だと思われるが、いかんせん練習量が足りないのだからないものねだりである。

チンニングに関しては、おそらく肩の可動域とパワーに左右でギャップがあって、よいフォームを開発できていないのが課題だと思われる。可動域が狭いのは肩の柔軟性もあるが、どうも三角筋とその下にある深層筋のいくつかが凝っていて正常に機能してないことが原因と思われる(きっかけはWeb魚拓の中の人のコメントだった)。なので、そのあたりを集中的にコンディショニングしながら背中側の筋力を開発していくことが遠回りながら正しい道だと考えている。具体的には以下の道具を今使っている(アフィリエイト)。

マッサージポールは小さめ硬めのものでグリグリやる。これは調子がよくて背中が柔らかいときに使う。

FINE(ファイン) パワー・ポジション・ボール ピンク FIN-525

FINE(ファイン) パワー・ポジション・ボール ピンク FIN-525

仕事で机に詰める時間が長くなってしまって、背中が硬いときはランブルローラーを使う。

これらの道具を使って1日に30分から1時間程度床の上をゴロゴロしているとかなり背中が軽くなる。いわゆるトリガーポイントからの筋膜リリースというやつだ。整体に通うのも悪くはないが、こういった道具を使って毎日コンディショニングすることで、トレーニングでも効率的に負荷をかけることができるようになる。というか、凝ってる状態で負荷をかけても意味がないし、ストレッチしようにも難しい部位が多いしで、これ以外に方法がないのが現実だ。

どうしても(アニメやゲームで夜更かしして)体の調子が悪くて、痛すぎてどうにもならないというときはストレッチポールを使う。ストレッチポールは突起がなくて曲率が低めなので体表面への刺激も限定的だが、その分手のひらで広く軽く押すような刺激が得られる。また肩甲骨を浮かせるストレッチも、ストレッチポールがあると簡単だ。

あとトレーニー向けの本もいくつか買ってあるが、まだ積んだままの状態だ。折をみて読んでいずれまたここで紹介できたらいいなと思っているのでお楽しみに。今年の学びはトレーニングそのものよりもコンディショニングの方が余程大切だということが分かった、それだと言っても過言ではない。

プログラミングとか仕事とか

4月にノーチラス・テクノロジーズというところに転職してJavaをひたすら書く生活になった。HTTP API作ってJSONをデコードして、裏側のミドルを叩いてスレッド管理して、JUnitとScalaCheckをまわして、結合テストもDockerを使って自動化して…というのを何とかこなせた。

残業も全くないし自分のペースで仕事ができる*1し朝は遅くてもよい。これ以上一体何を職場に求めるというのか…。まあ前職がゆるすぎたというか、まあ現職では実業とか実需に沿って実案件に関われているのでそれなりに大変なこともあるが、それでも(日本の)世間一般のコンピュータ技術者よりも時間と収入に余裕のある仕事なので私は幸福です。一日の労働時間でいうと5〜6時間程度しか実際は働いていなくて、前職よりも机に向かっている時間は短くなった。その分、通勤もそうだけど趣味に時間を溶かすことができるようになった(おい)。

写真とかプライベートとか

夏は神楽坂に旅行に行ってきた。勤務地よりも近いところにわざわざ旅行?って思うかもしれないけど、機動力が低くて食欲旺盛な我が家にはそういう場所がピッタリなの。こんときに今の携帯の背景画像を撮ったので、見たい人は直接僕に声かけてください。

101ND610-DSC_4457

科学未来館にも行ってきた。これは僕が主に楽しんでしまった。子供に科学の面白さを教えるには、いったいどうやればよいのか。

101ND610-DSC_3801

国立天文台三鷹キャンパスのオープンデイにも行ってきた。子供にレンズ、宇宙物理、コンピュータの面白さを教えるには、いったいどうやればよいのか。やっぱり俺が楽しんでしまったのだけど。写真は日本最大の赤道儀。1926年、カールツァイス製、焦点距離10210mmとかですよ。ヤベー

101ND610-DSC_6937

で、こちらはALMAという巨大な電波望遠鏡の心臓部といっていい部品、宇宙から飛んできた電波をパラボラで集約した後に電気信号に変換する部品。4Kまで冷やして雑音除去するらしい。こういうものを製造する設備も三鷹にあって、それも見学できたのだけどEEIC出身的にやっぱり俺が楽しんでしまった。同じフロアでマイスナー効果を使った浮遊物の展示もあって、息子はそれをみて楽しんでいた模様。

101ND610-DSC_6913

秋には日本橋で舟遊びをした。といっても運河をちょっとクルージングしただけだが、高度経済成長と江戸時代の海運機構が絶妙にバランスしていて、風も気持ちよくて脳汁が出てた。写真は首都高の日本橋付近のジャンクションかなにかだと思う。

101ND610-DSC_6617

息子と高尾山に登った。頂上で飲むビールはよかった。

101ND610-DSC_5336

高尾山に登ったときに友達に借りたマクロレンズがよかったので自分でも買った。今年はこれ一本しか買ってないはず。沼ェ…写真は妻の蒔絵を60mm/f2.5で撮ったもの。巻物の紐の幅がたしか0.2mmとかそういう感じのやつ。

101ND610-DSC_5529

Nikon 単焦点マイクロレンズ AF-S  Micro 60mm f/2.8G ED フルサイズ対応

Nikon 単焦点マイクロレンズ AF-S Micro 60mm f/2.8G ED フルサイズ対応

紅葉の季節に京都にも行ってきた。そこで撮れた今年のベストショット、facebookで公開しているので興味ある人はそちらへどうぞ。

まとめ

これだけイロイロ自分の時間でやっていると家族の時間ほとんどないんじゃないの…家族ほったらかして何やってんの…?といわれると返す言葉もないのであるが、が、が、幼子がいる方が時間の使い方が上手になったとは思う。何か大きくてハイリスク・ハイリターンなことに取り組むことは確かにできなくなった。が、小さな時間を積み重ねて量をこなすことができるようになったのは、いまの会社の理解があることも大きい。

  • 労働時間と睡眠時間を削って、アニメとスプラトゥーンに可処分時間のほぼ全てを費やした
  • 筋トレそのものよりもコンディショニング、筋肉のケア、食事が大切
  • Java始めました
  • 写真は相変わらず上手くならない
  • アフィ沢山はったので買ってくれ

*1:これは、プロダクト開発という自分のロールの特性も大きいのだが

2016年に観たアニメのまとめ2

  • ★0は、観る価値なし。途中で切ったまたは観て損した。基本的には掲載しないが、最後までみたものは誤ってもう一度みてしまわないために掲載
  • ★1は、一度くらい観てもいいかも
  • ★2は、ちゃんともう一度見返してもいい
  • ★3は、絶対に観とけオススメ、名作、僕の好みの作品

この頃から、よかった作品に投げ銭の意味を込めてサントラを買うようにしている。Blu-rayやDVDはちょっとデカイので。。。

機動戦士ガンダム サンダーボルト DECEMBER SKY

★2

ジオンの若い傷病兵が義足のままスナイパーとして戦っていたが、祖国を守るために人間をやめていく話。オルフェンズの阿頼耶識みたいな感じで手足をモビルスーツに直結すると操作性が上がり戦闘力が向上する。豊かな連邦軍と、貧しいジオン軍の対比が悲しく、宇宙空間にクラシックではなくジャズを流すという描写が新しい。PPVじゃなかったらなー

剣風伝奇ベルセルク

★2

蝕までの黄金時代を描いたアニメ。1997年放映なので絵柄は古いが、当時としては金かかってんなーという、ベルセルクに相応しいさすがの作画。

空戦魔導士候補生の教官

んー、まあ、主人公チート系ハーレムもののやつ。戦闘シーンはそれなりに迫力があるが…

BTOOOM!

★2

オンラインの爆弾対戦ゲームが現実化した無人島にいきなり放り込まれた世界ランカーが命をかけて生き残る話。こういう極限モノは人間の喜怒哀楽、愚かさとか切実さがうまく描写されていると非常に面白くなる。が。が。が。1期で打ち切りってどういうことよ…ものすごくいいところで終わってしまって消化不良である。不満。

学戦都市アスタリスク 2nd SEASON

空戦魔導士候補生の教官落第騎士の英雄譚と区別ができないやーつ。おそらく原作はゼンゼン中盤なのだろうけど、さすがに2期までやってアニメ的にはダレてきた展開。伏線回収はまだまだ先で、さすがに企画と制作の体力が尽きたか。うまく幕引きできるタイミングがあったらよかったのにね。

花咲くいろは

true tears, TARI TARI に続くPA Worksのヒット作。18歳未満を早朝から夜までこき使ってもええんかいという違法性にはとくに触れることなく淡々と進んでいく。喜翆荘で働く三人の高校生が自信をつけていくお話なんだけど、ぼんぼり祭りは非常にキレイでよかったし作画も文句がないのだけど、なんというか、前作や前前作に比べるとワクドキ感というかハラハラしなかったので僕の中では重労働日常系に分類してしまいそう。若いっていーなー。

TARI TARI

★2

湘南で合唱をやる高校生の話。とにかく主人公の和奏が可愛い、年頃の彼女の心の奥まで見て若返った気になれる良作。これはサントラを買った。

TVアニメ TARI TARI ミュージックアルバム~歌ったり、奏でたり~

TVアニメ TARI TARI ミュージックアルバム~歌ったり、奏でたり~

true tears

★3

PA Worksの出世作ということで、たまたまバンダイチャンネルで観れたので、そのままちょっと観たもの。もともと同名のゲームが原作だが、アニメでは岡田麿里が自前の構成で脚本から作った話。元が女の子の涙を手に入れるとクリアというゲームなので、主人公の男の子が3人の女の子にモテて最終的に誰を選ぶの?!みたいなストーリーなのだけど、若者だなーという心の動きが繊細に描写されていて、こういうジャンルもあるのかと感心した。2008年放送だけど、当時観ても僕が若すぎて良さが分からなかっただろうな…という。バスケやる比呂美がかわいいです。サントラ買いました。

true tears オリジナルサウンドトラック

true tears オリジナルサウンドトラック

クロスアンジュ 天使と竜の輪舞

★2

どこが…と思ったらこれが、舞-HiMEでやらかしたサンライズだった。舞-HiMEからコメディ要素を抜き取って百合と奴隷制度とアルカトラズ、遺伝子操作、多世界解釈SFを追加するとこれになる。女子校ってこういう感じなのかな…と想像して怖くなるなどできる良作。

ダンジョンに出会いを求めるのは間違っているだろうか

★2

面白いので一気に観てしまって★2をつけたが、もう一度みたいかといわれたら微妙かもしれない。

2016年に観たアニメのまとめ3

  • ★0は、観る価値なし。途中で切ったまたは観て損した。基本的には掲載しないが、最後までみたものは誤ってもう一度みてしまわないために掲載
  • ★1は、一度くらい観てもいいかも
  • ★2は、ちゃんともう一度見返してもいい
  • ★3は、絶対に観とけオススメ、名作、僕の好みの作品

東京喰種

★★

これは原作が面白いのだろう。人類を脅かす天敵グールが人間の姿をして社会に溶け込んでいるという危機感を散々煽ったあと白鳩という天敵も作ってバランスをとっておいて、実はグールにも社会性、人間性があって、そいつを押し潰しているのはむしろ人間の側なんじゃないかとか、そういう背景の中である日突然人間をやめさせられてグールになってしまった少年の話。しかも最強のグールになってしまった話。ヤモリとか利世とかマジで頭おかしいヤツもいれば、グールなのに人間以上に人間らしい芳村とかがいて、はて人間性とは何だったのか知能とは何だったのか、基本的人権とは何だったのかみたいな話を沢山想像させる良作。…が、いいところで終わる。2期みないといけない。

Re:ゼロから始める異世界生活

大人気だった本作、元祖異世界ものでRPGよろしく死んだらセーブポイントから再開できるという斬新なプロットからスタートしてとても期待できた。白鯨倒して村を助けるところまでで2期が終わった。展開が予想できるようなできないような絶妙な線を進み続けただけあって楽しんで見れた。いっこ気になるとこといえば、渡鬼よろしく全部解説していく主人公の独白(ただし周りに聞いてほしい)がどうしても耳についてしまったくらいか。あと主人公ヘタレすぎ…だけどきっとそれは僕がすれたオッサンになってしまったからだろう。

ねじ巻き精霊戦記 天鏡のアルデラミン

★★

最初は作画がキレイだなーと思って見ていたのだけど、よくみると僕の好きな戦記物だとわかって原作も買ってみたらそれがわりと面白かったので星追加。基本的には主人公による戦略謎解きものなんだけど、一部がオーバーテクノロジーを少しずつ開示していきながら敵を倒していくのがよい。よいのだが。戦場で歩兵がメットなしとか女性兵士がスカートはいてるとか、ラノベ的な都合はあるにせよ、いくらなんでも現実感が…

野戦が主体なのでどうしても地形の描写がストーリーの説得力に直結するのだけど、アラファトラ山脈北側の描写がちょっと残念だったかな。師団規模を大隊ひとつで抑えるにはかなり工夫が必要なのは確かなんだけど、もっと雄大に描けたはず(予算がねェ)。アニメ化するにあたってあのキャラデザは大成功だと思う。

魔装学園HxH

★0

なんか、まあお色気モノつい観てしまった。こういう感じのやつ今まで地上波にはなかったよね。

マクロスΔ

お馴染みマクロスシリーズの最新版アップデート。最新鋭の宇宙戦闘機チームが歌姫の支援を受けて敵を倒して宇宙を守る基本プロットは変わらず(変わらないのがよいのです)、作画と音楽がモダンになって帰ってくる。コンピュータシステム全盛の今風としてテクノポップな曲が多くて好みだ。会いに行けるアイドルのアンチテーゼとして歌えるアイドルをもういちど提示した、といったところか。

うっかりサントラを間違えて買ってしまって、ワルキューレのアルバムと合わせて3枚も円盤買ってしまった。。。

Walkure Trap! (通常盤)

Walkure Trap! (通常盤)

Walkure Attack!(通常盤)

Walkure Attack!(通常盤)

クオリディア・コード

おそらく原作が面白いんだろうな。話が進むに連れ作画にかけられる工数がどんどん減っていくにも関わらず、話の展開と後半明らかになる意外な秘密が面白くて最後まで楽しんで観ることができた。主人公があまりに魅力がなく残念なのに観れる良作。

ベルセルク★★

最近のメディア展開を見ていると、ガンダム税だけでなくベルセルク税もどうやら最近制定されたらしい。黄金時代編の劇場版と同じキャスト、同じ3D作画でかなりクオリティが高くて楽しめた。いくつか原作をアレンジしているところがあるので少し混乱してしまうが、それでもドラゴン殺しのSE*1がとても爽快で一聞の価値がある。原作を読んでおくとなおその音を楽しめると思う。それを聴くためだけに見てもよいレベル。あの音つけた人は天才だと思う。

七つの大罪 聖戦の予兆

人気漫画のアニメ2期。

機動戦士ガンダムUC 0096

ガンダム税を払ったのだけど、Aimerのエンディングテーマがよかった。 UnChild というアルバムの bloody f8 という曲をアレンジしたものだ。Google Musicにたくさん曲があるのでたまにそれを聴いている。

七つの大罪

人気漫画のアニメ1期。少年誌らしく飽きさせない工夫があちこちにあってとても楽しめる。でも原作者、もうちょい休んでもいいんだぜ…?

凪のあすから

★★

P.A. Worksものは一通り観ておこうと思って、古いものから順にみてるのだけど、どうやらこれは当時大ヒットしたらしい。海に人が住んでて、果たして流体力学とは何だったのかという疑問だけを隅においておけばSF要素も超常現象も楽しめる。やはりこれも岡田麿里のシリーズ構成で、若者たちの繊細な心理がよく描写されていて楽しめる。前半はちさきが、後半はうみながかわいいと思います。

RDGレッドデータガール

これもP.A. Worksもの。記紀系の憑依モノといえばよくえるプロットかな?前生徒会長の神崎先輩がよかった。

アルスラーン戦記 風塵乱舞

港町ギラン編のみ。つーかあんだけ期待させといてそんだけ?!王都奪還までいくでしょ、これっ。1クールに収めるのに中途半端なサイズなのはわかるけど、3期に期待できない限りこの2期はいらなかったんじゃないの説…

IS<インフィニット・ストラトス> OVA ワールドパージ編

★★

IS<インフィニット・ストラトス>

★★
なんだよどうせハーレムものだろ?って思ってたけど、案外おもしろい。シャルロットさんかわいいですね。このときの花澤香菜のCVが非常によくてお気に入りです。OVAまでは惰性で結局見てしまったよ。

ベルセルク 黄金時代篇 I 覇王の卵

剣風伝奇を見ていればまあこれは見ていなくてもいいかも、OVAなので尺がなくて、重要なシーンをかいつまんでくっつけた感じ。スタッフ・キャストが同じなので、黒い騎士編を制作するための作画実験だと思えばまあ許せるが、ちょっとナァ、これじゃあ初見のひとに良さは伝わらないよ。

ストライク・ザ・ブラッド

★★

「雪菜の作画にはかなりこだわった」とどこかで制作メンバーが言っていたとおり、吸血鬼がハーレムを運営する…のだけど、中でもヒロインがよく描けているやつ。暁の帝国編はなかなかよい見せ方で、今後のシリーズ展開に期待、って思ったらもう制作はなさそうである。残念。

ガンダムTHE ORIGIN III

226事件とかを美しく描くとこうなるのかなというありがたいお話。このまま流れで一年戦争に突っ込んでいくのかと思うと日本人は全員これ見て考え直した方がいいんじゃないのって思う。シャアは残酷ですナァ…ちな転職時に全巻プレゼントしてもらってそれ読んだので、ストーリーは知ってた。

*1:Sound Effect

Google翻訳でとても仕事で助かった話

Google翻訳がニューラルネットワーク応用で「さらに進化」。翻訳ソフト感うすれ、流暢さを身につける - Engadget 日本版にもあるように、新しいNMTのGoogle翻訳はこれまでの機械翻訳とは段違いの性能で評判だ。わたしも少しずつ使ってみたりしていたのだが実際に職務でインパクトがあったのでここに記録しておこうと思う。

...

ご存知の方もいると思うが、わたしはApache Mesosを使ったソフトウェアの開発を仕事にしている。これは単体のサーバーでも動作するので、開発するときはほとんど1台または2台くらいのサーバーを使っている。しかしながら、実際の環境ではもっと多くのサーバーがクラスタとなって動作する。当然、複数のサーバーで動作するときしかでない問題は多い。詳しくは省略するが、今回もその件に漏れず複数サーバーないと出ない問題に当たって、それ自体はMesosの仕様を見逃していたせいなので修正はすぐできたのだが、再現試験などの環境が家になかった(オフィスにはあったのだが)。

で、Debian上のVirtualBoxVMを4台上げて手元で再現させようとしたのだが、このとき4台のVMをNATネットワークでつなごうとすると、そもそもゲストVMがネットワークにまったく接続できない。ポートフォワードも設定したのだが、ホスト側からもゲストにTCPで全くアクセスできない(VirtualBoxGUIからはアクセスできた)。オフィスにあるMacOSのNATネットワークなら動くのなぁ、困ったなあ…。で、こりゃVirtualBoxのバグだろといろいろ調べていたのだが全然でてこない。こまった、この問題の再現と修正確認ができないとリリースできない。でも調べるの時間かかりそうだなあ…OSSだから仕方ないんだけど、ヤダなぁ…ちゃんとやったら1週間でできるかなぁ、オフィスいってMac使った方が早いんだろうけどなあ…などと逡巡していた。

いろいろやって、それっぽいエラーメッセージが出たのでそれで検索すると、次のページが引っかかった。

gist.github.com

はい全然わかりませんね。同じ漢字文化圏といってもこんなもんです。で、これを精度がよいと評判のGoogle翻訳にかけてみた。そのまんまかけてみただけなのだが、結構英語が読める。まあ英語といっても大概なんだが、よく訓練された俺達は、同じ意味不明なら日本語よりも英語の方が理解できるのだ。どうも asciidoc aware ではないらしいが、日本語に訳してもこれは全然わからない。

しかしVirtualBoxのは、名前を見て、この問題は、それがすべての可能性のリードにであることであると推測関連1 Virtualboxのゾンビがあり、例外、ないモニタポート2204がありませんログインします。
[ソース、コンソール]

まとめると、

  • VBoxNetNAT というNATネットワークを管理するプログラムはroot権限でしか動かないようだ (ユーザー権限でやると になってしまってにっちもさっちもいかなくなる→コレがだんまりの原因っぽい)
  • "VBoxNetNAT: Effective UID is not root (euid = 1000 egid = 100 uid = 1000 gid = 100)" というメッセージからわかる
  • ps してみてもわかる
  • そのあたりのコマンドに +s 権限をつけたら動くようになる(実施前にみたら、たしかに s ついてないやつが多かった)
for bin in VirtualBox VirtualBoxVM VBoxNetAdpCtl VBoxNetDHCP VBoxNetNAT VBoxHeadless; do
    chmod u+s /usr/lib/virtualbox/${bin}
done

これでVirtualBoxをふつうに再起動するとなおる。で、ポートフォワードもゲストOSのネットワークアクセスも普通にできるようになった。

まとめ

  • VirtualBoxOSS なので問題は自己解決するのが原則
  • ネット上に同じ問題でハマってる人は少なかったが、答えが中国語で書かれてていた(私は中国語が読めない)
  • Googleの自動翻訳(中→英)が自然すぎて解決策を正しく理解できた
  • 結果、自分で調査したら解決できたかどうか分からない問題が半日というか数十分で解決した
  • 仕事ができて身長が5cm伸びた

Paxos-based replicationはEventually consistentではなくstrongly consistentである

ちょっと発言力のありそうな方がテクニカルに誤りを書かれていたので、ここでひっそりと訂正しておきたい。

このスライドの43ページ目に、

The problem with Paxos-based algorithm is that replications are eventual consistent.

と、色付き文字で協調されて書かれている。このスライドで主張したいことの本筋ではないが、Spannerの性能がよいこととは関係がなく、Paxosなどのレプリケーションと、トランザクションとの関係で誤解を広めそうなので指摘しておきたい。辻マサカリと言って差し支えないだろう。

PaxosはStrongly consistentであることがMade Simpleの論文で証明されている(Strongly consistentが何かはまた別の機会にここに書こうと思う)。ちょっと長いが引用しておこう。

To learn that a value has been chosen, a learner must find out that a proposal has been accepted by a majority of acceptors. The obvious algorithm is to have each acceptor, whenever it accepts a proposal, respond to all
learners, sending them the proposal. This allows learners to find out about a chosen value as soon as possible, but it requires each acceptor to respond to each learner—a number of responses equal to the product of the number of acceptors and the number of learners.

ベタにいうと、Paxos-basedなレプリケーションでも過半数読まないと値は決まらないので、それに従ってる限り誤った値が読まれるということはない。

Eventual consistencyとは「古い値が読まれることがあっても、最終的には最新の値が読めるようになる」なので、これは真っ向から定義に反するわけだ。

ではPaxosの定義はともかく、Spannerにおける実装はどうなんだということになる。Twitterでは日本語で、似たような趣旨のことを書かれている。 SOの記事
Paxos algorithm in the context of distributed database transaction - Stack Overflow を引いて

というPaxosに伴うEventual Consistencyの問題をwrite処理にタイムスタンプを付けることで、あるレプリカが、クライアントが要求する時刻より新しいデータを返せるかを判断できるようにしたのがSpanner

と書かれている。上記の通りPaxosにはECの問題なんてないし、SOの記事にもそんなことは1ミリも書かれていないのだが、どうしてこういう誤解がされたのか、せっかくなのでSpannerの論文を当たってみよう。 2.1 の冒頭でレプリケーショントランザクションについて語られている。

Unlike Bigtable, Spanner assigns timestamps to data, which is an important way in which Spanner is more like a multi-version database than a key-value store. A tablet’s state is stored in set of B-tree-like files and a write-ahead log, all on a distributed file system called Colossus (the successor to the Google File System [15]).

ここから分かるのは、Spannerではひとつの行にタイムスタンプで複数のバージョンを保持できるようにしているということだ。そしてWALがある。ということは、Tabletに対する更新はおそらくキー毎ではなく、Multi Paxosのように1Tabletにつき一つのWALを合意し続けるような作りであることが想像できる*1が…先を読んでみよう。

To support replication, each spanserver implements a single Paxos state machine on top of each tablet. (中略by引用者) Each state machine stores its metadata and log in its corresponding tablet. Our Paxos implementation supports long-lived leaders with time-based leader leases, whose length defaults to 10 seconds.

うむMulti-Paxosそのものだな。ちなMultiPaxosの特許は10年ほど前にMSがとっていて日本の特許公報でも見つけることができる。この書きっぷりからして思いっきり侵害していると思われるがそこは西海岸の論理でそんな野暮なことはしねーんだョ〜というのが垣間見えておもしろい。

Fig 2をみると分かるが、ここでのレプリケーションはデータセンター間のレプリケーションを指している。そしてちょっとあとに重要なことが書かれいている。

Our implementation of Paxos is pipelined, so as to improve Spanner’s throughput in the presence of WAN latencies; but writes are applied by Paxos in order (a fact on which we will depend in Section 4).

PaxosのWriteはパイプライン化してWAN超えても高速に送れるようになっている。で、Writeは必ず時間順に適用されると書いてある。TrueTimeを使っているからこんな芸当ができるんだね。で、勘違いされたのはすぐ次のここだと思われる

Writes must initiate the Paxos protocol at the leader; reads access state directly from the underlying
tablet at any replica that is sufficiently up-to-date. The set of replicas is collectively a Paxos group.

つまり、readsはPaxosをすっとばしてTabletに直接行くと書いてある。もとのPaxosにあるようなlearnerを通しての読み方ではなく、近くのデータセンターのTabletを直接読む...んだったら、そりゃあ間違った値が読めてしまっても仕方ない。しかしこれは上でも説明したようにEventual consistencyではない。sufficently up-to-dateな値を読んでも正しい値が読めるのは、たまたまSpannerでTrueTimeとそれに伴う並行性制御が適切に設計されているからである(4章で説明されているように)。

そもそもConsistencyというのはそのプロトコルが規定したR/Wの組み合わせパターンのそれぞれの結果のスペックであって、PaxosでもSpannerでもそういうスペックは規定してないのだからEventual consistencyと勝手に呼ぶのは間違っていて...Spannerの論文にもそんなことはどこにも書かれていないし…ブツブツブツブツ。

*1:ちなみにこれはRiakのStrong Consistencyでもやってるやーつ