2017-04-02

こういうの本当にやめていただきたい

anime

f:id:kuenishi:20170215024411p:plain

いやまあこれなんだけど。昨日急に通知があったということは計画停止じゃないというわけで、そんな前日にダウンロードしてくださいませ！とか言われてもできるわけねえだろ！ダウンロードするくれえなら見るわ！

【メンテナンスのお知らせ】システムメンテナンスに伴い、以下の時間帯でdアニメストアの全てのサービスがご利用頂けません。
・2017年2月15日(水) 午前 2:00 ～午前5:00(予定)
予めご覧になりたいアニメをダウンロードしておいてくださいませ！よろしくお願いいたします。
— dアニメストア＠夏アニメ配信スタート！ (@docomo_anime) 2017年2月14日

過去もだいたいこの時間。

【お詫びと訂正】
今夜dアニメストアのサービスメンテナンス時間ですが、以下のツイートで
■12/21（水）午前2時～午前4時（予定）とお知らせしましたが、
■12/21（水）午前2時～午前6時（予定）の誤りでした。
お詫びして、訂正させていただきます。 https://t.co/TjiZVtTEoT
— dアニメストア＠夏アニメ配信スタート！ (@docomo_anime) 2016年12月20日

【メンテナンス情報】
今晩～明朝にてシステムメンテナンスが実施されるため、以下の時間帯でdアニメストアの全てのサービスが利用停止になります。

2016年6月21日(火) 午前 2:00 ～午前7:00 (予定)

ご迷惑をおかけしますがご理解のほどよろしくお願いします。
— dアニメストア＠夏アニメ配信スタート！ (@docomo_anime) 2016年6月20日

たとえば検索すると「重要なお知らせ」が引っかかるんだけど…この時間に止めるということはこの時間が一番トラフィック少ないわけで、みんな割と昼間とか朝観てるの…まじで…っていう感じです。

こんなにメンテナンスばかりしていて本当に大丈夫なの、システムちゃんと作れているのかとても心配、というか、まあ安いから入ってるんだけど、こういう感じで何もアナウンスなくメンテナンス入られるんならまた移行考えちゃうYo...

2017-02-12

大根はなぜ消化によいのか

夕食で大根の煮物が出てきた。冬はやはりこういうものに限る。暖まるなあ…消化にもいいらしいし…と思ったところで、ふと大根はなぜ消化によいのだろうか？という疑問がわいた。大根は動物ではないのだから食物を消化する必要はないわけだ、消化酵素というものが含まれているが、酵素は通常は動物の体温程度の方が活性が高いので地面に埋まってる大根が低温で持ってても使う機会ないんでは…？などと疑問は尽きない。

我々取材班は早速Google経由でWikipediaに向かった（夕食を食べてダンベルのメニューとブルガリアンスクワットと、スプラトゥーンのガチマッチを10戦ほどこなした後で）。

f:id:kuenishi:20170211213057j:plain

大根おろし - Wikipediaには「大根にはアミラーゼ、プロテアーゼ、リパーゼなどの消化酵素が豊富に含まれているが、これら酵素は熱に弱いため、加熱をともなう調理法では有効に利用できない」と書かれており、主に三種類の消化酵素が含まれていることが分かる。この三種類の酵素について、調べていこう。

アミラーゼ

アミラーゼは、デンプンを分解する酵素だ。というのはあちこちの料理サイトから、いかがわしい健康ダイエット系のサイトまで、どんなところでも書かれている。過熱すると酵素はこわれちゃいから大根はなるべく生で食べましょう、消化がよいのでダイエットに効果ありますぜ！と、そういうのは無視したいのだけど、もうWebは汚れてしまっていてほしい情報に辿り着くのは非常に難しい。

しかしアミラーゼについては案外簡単に答えがみつかった。ダイコンのアミラーゼ | みんなのひろば | 日本植物生理学会が非常に詳しい。いわく「大根にはほとんどデンプンがないのに、どうしてその消化酵素が多く含まれているのですか？」という非常に鋭い質問だ。しかも実験までされている。最近の塾ってすごいんだな…とにかく、要点を引用すると

デンプンはデンプン粒として1〜0.5%存在しているとのことです（澱粉科学35: 19 (1988)）
ダイコンの根は〜90%が水分であることからすれば、そんなに少ないわけでもありません
アミラーゼは植物細胞中で、原形質ではなく成熟細胞の大部分の体積を占める液胞の中に局在
デンプン粒は液胞の中ではなく、原形質に存在
相互に接触していないため、デンプン粒がアミラーゼによって分解を受けることはありません
冬大根であれば秋―冬での光合成産物を根に貯え、春に種子ができるときそのエネルギー源として根のデンプンを利用していると考えられます

ということだ。動植物が冬を越すためにエネルギーを蓄え、その中でデンプンと同様にアミラーゼも蓄えられているという精巧な仕組みになっている。ではデンプンの消化を助けるというが効果のほどはどうなのか。唾液や膵液に含まれているアミラーゼの含有量はわからないけど、

膵液は一日に1500ml程度分泌されるらしいこと、
唾液も1000~1500ml ほど分泌されるらしいこと

から、なんとなくオーダーが推測でき…ない。大根おろしを1リットルほど食べれば補助にはなるかな。食べ過ぎかな。

α-アミラーゼ｜酵素辞典｜AMANO

プロテアーゼ

リパーゼ

まとめ

分子生物学とか化学ちゃんと分かってないと説明するのは難しい。あと市井の情報源はほとんど信頼に足らず、どれだけ食べたらどういう定量的効果が得られたのかといったデータを全く語っていない。
タンパクを壊すタンパク・プロテアーゼのような面白いページで時間を溶かしてしまって簡単には目指す知識にたどり着けなかった。人類の膨大な知的資源を投資し続けているだけのことはある。

2017-01-24

筑波大学で分散システムの話をしてきました

また呼んでいただいたので、筑波大学の情報システム特別講義D（1/19, 20 - 20日4限）で話してきました。これは業界で川島さんに無茶振りをされた人が聴講に来た大学生を置き去りにして講師陣に実力を試されるという素敵なイベントです。発表に使ったスライドはこちらです。自分で論文読んで証明を考えながら作ったスライドなので曖昧なところや誤りがあれば指摘いただきたいです。

前回はデータベースの話をしました。

kuenishi.hatenadiary.jp

今回は、転職もしたし、NoSQLブーム的なのも一通り終わったのでもうデータベースの話でもねーだろってことで、分散システムの理論面に入門した内容になっています。分散システムの理論面は20世紀に一通り出揃ってしまって、21世紀の最初の15年は実装と運用の時代でした。具体的には、理論と実装のギャップをどう埋めるかという研究や試行錯誤が盛んで、理論それ自体の進歩はそれほどでもなかったと思います。…と言いながら、自然言語で記述する分散システムの証明に限界があって人類には難しすぎるのも事実なので、その検証や証明を補助するツールや理論がいくつか試された時代でもありました。そのあたりは発展編として、私はカバー~~できません~~しませんでしたが、10年後には現場でも必要になっている技術だと思うので、いまから入門しておいてもよいかと思います。

おまけ

データサイエンス根性論

Kota UENISHIさん(@kuenishi)が投稿した写真 - 2017 1月 18 11:45午後 PST

2017-01-24

俺専用パスワード管理ツールを作った

diy

github.com

恥ずかしながらわたし、つい最近まで類似のパスワードを適当に記憶に頼って数種類使い分けるという運用をしていた。しかしながら、次のようなメールが期間をおいていくつか届き、類似のパスワードを使っている他のサービスに被害が及ぶのを恐れて、ランダムにパスワードを生成して保存するツールを作った。

f:id:kuenishi:20170124213157p:plain
f:id:kuenishi:20170124215620p:plain

いくつかのECサイト、特に小規模ECサイトは2要素認証が設定できないものが多く*1、あのアマゾンでさえ…と思ったら、いつのまにか2要素認証できるようになっていた。そうはいっても一部のサイトではクレジットカード情報を保存しておきながら2要素認証しないとか不安しかないので、自分でパスワード管理できるプログラムを練習がてら作って運用をまるごと変えることにした。既存のパスワード管理のソフトウェアやサービスがいくつもあるが、以下の理由でやめた

無料サービスは信用できない
有料サービスはちょっと躊躇する（秘密鍵を預けるのは怖い
プロプライエタリなソフトウェアは、いざというときに検証できない（損害賠償するのかな）
OSSはGUIがついているものが大半で、コードベースが大きいので検証しにくい

要件としては

パスワードを暗号化してローカルファイルシステムに保存する
保存したファイルは読みやすいフォーマットであること、外部にバックアップ可能であること
秘密鍵は別途保存
ツール全体のコードが小さいこと（目標1000行以下、GUIは不要）
依存するライブラリは最小限にして、常にコードをチェックできるようにしておくこと
ポータブルであること（Mac, Linux, Windowsで動くこと）
他の端末にもデータを移せること

くらい。それで作ったのが、冒頭の Baccounts だ。GnuPGの秘密鍵が安全に保持されている限りパスワードが漏洩される危険はない。ブラウザを使わないのでXSSやCSRF、自動補完の心配もない。Baccounts が持っている機能は

プロファイル毎に、サイトのメールアドレスを保存したりパスワードを生成(generate)・表示(show)できる
プロファイルやアカウントを一覧表示(list)
持っている公開鍵暗号ペアを一覧表示(list-keys)
公開鍵があれば、その鍵ペアに対して全ての情報をexportできる（複数のマシンで使いまわせる）

である。なにかのサイトにログインしたいときは、次のような感じでパスワードを見ずに取り出せる

$ baccounts show -site https://twitter.com                                                      [~/log/baccounts]
datafile: /Users/kuenishi/.baccounts
baccounts version 0.0.1-SNAPSHOT - data file version: 0.0.1-SNAPSHOT
Passphrase of your GPG key:
Secret Keyring: /Users/kuenishi/.gnupg/secring.gpg
Pass for https://twitter.com copied to clipboard

非エンジニアの人はCUIとかGo言語とか使えないと思う…なお、GnuPG 1.4または2.0で作った OpenPGP フォーマットの公開鍵と秘密鍵が "$HOME/.gnupg" 以下に揃っていることが動作条件だ。これは

$ baccounts list-keys
$ baccounts test

などとして動作確認することができる。

なお、コードの透明性を高めるためにライセンスはあえてGPLとした。これからコミットされるコードは全て署名を要求することにしようと思う。

今後やりたいことは

Androidアプリでも作ってスマホでも使えるようにする
keybase.io にデータを保存、できるかな？
GnuPG 2.1 (gpgsm) フォーマットも読めるようにする...これはGoのcrypto/openpgp次第かな…
yubikeyなどの物理デバイスでの解錠
実行バイナリの署名付き配布
パスワードの更新

などである。もし興味のある人がいたらPull requestを送ってくれてもよいし、セキュリティホールがあった場合はご指摘いただければと思う。

*1:おめーだよ、ヨドバシ.com!!

2017-01-03

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というウェブサービスの全体像を考えると、GoogleやFacebookのように高度なシステムは必要ないことが分かったが収穫で、役割はもう終わったのだろう。

記事が出た直後、山口さんの指摘を受けて「しかし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で動いていると思っていた。だから指摘を貰ったときは非常に驚いた。

@kuenishi DVD配送ビジネスはクラウド移行しないと報道されています。たしかにプレスリリースには一言も書いてないのでもにょるんですけど… https://t.co/NwzlKzcsUc
— Hiroaki Yutani (@yutannihilation) January 1, 2017

リンク先の記事を読んでみるとたしかに "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にしたら信用できるかというとそうではなくて、彼らのクラウドサービスが大量のソフトウェアが密結合していて、適切な粒度で公開できないからだ。また、適切な粒度で切れないので、各種仕様もおそらくかなり流動的で、何か障害があったときに根本的な原因を説明できない。おそらく障害時に社内では詳細なレポートが共有されているだろうが、社内の独自システム、独自ソフトウェア、独自ハードウェアのコンテキストが多すぎて対外的には読めたものにはならないだろう。そして、そういう障害は社内の多くのシステムが関わっているために、おそらく全体での再現は不可能だ。だから、最終的には「いろいろあったけど直りました」とレポートすることしかできない。分散システムの実装、運用は本当に地獄ですよ。

次は規制面での問題だ。AWSはSOCレポートの提供や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から出発してコンピュータに投資し続けたウェブサービスがGoogleやFacebookのようには成功しにくいのが現実だ。

それでも希望を持って何か言うとすれば、コンピュータ技術や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-12-23

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

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

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

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

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

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

blogs.yahoo.co.jp

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

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

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

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

大都会になっていた

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

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

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

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

yufuki.cocolog-nifty.com

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

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

岡山駅 東口

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

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

国道53号の大カーブ

Street Viewでいうとここです。

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

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

まとめ

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

参考にならない話

ITエンジニア U＆Iターンの理想と現実（6）：岡山編：エンジニアの給料は、全国平均より高い？低い？――岡山のIT企業、給与、コミュニティー (2/3) - ＠IT
ITエンジニア U＆Iターンの理想と現実（5）：岡山編：立ち乗客3人で「すげー満員じゃあ」――岡山の交通、住宅、生活事情 (3/4) - ＠IT
大都会岡山に初めて行った東京都民がマジで驚いた10の理由 | ロケットニュース24
【画像】岡山駅でヤンキー200人VSパトカー15台警察の大乱闘ヤンキー集会【大都会岡山】 - NAVER まとめ
 大都会岡山~岡山を大都会にするゲーム~かんたん無料放置 - Google Play の Android アプリ

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

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

*3:今もない模様

2016-12-13

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そのものの紹介はもうあちこちでされているので、ここでは違った角度から紹介したい。

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

他製品との比較

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

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

その他参考

GitHub - dharmeshkakadia/awesome-mesos: Everything about Apache Mesos

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

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

kuenishi's blog

最近のトレ

目標

メニュー

ジムに行けないとき

口に入れるもの

モチベーションの維持

結果