AsakusaとOLTP（RDB）とバッチ処理 - 急がば回れ、選ぶなら近道
Asakusa Advend Calnderの最終として 現状 2018/12月の現在の自分のタスクは、DBのMVCCでのTX制御の理論・アルゴリズムの設計になっている。要するにDBを作りましょうということで、そのコア部分をどうにかしなさい、ということになっている。それで、その前提として、今回のDB-Prjでの最大の眼目の一つを「Writeの強いRDB（OLTP）」ということにしている。 現在のRDBはそもそも原理的かつそのツールとしての特性上WriteというよりもReadにパフォーマンスが振られている。結果として、一般に、書き込みヘビーの業務系大型バッチ処理がRDBでまぁほぼ全敗になる。これは常識のまま、そろそろ30年くらいになるし、この辺が改善する見込みはほぼない。ということで、大規模（といってもさすがに最近のトレンドの規模感からはそう簡単には大規模とは言いがたいが）で複雑な一貫性を担
Asakusa 0.10.0 - 急がば回れ、選ぶなら近道
Asakusa 0.10.0について あけましておめでとうございます。今年もよろしくお願いします。 のっけからアレですが、これはAsakuas Advent Calendar 2017のエントリーなわけ（個人的には12/31までがクリスマスとかそんな感じの年末催事なのでそのつもり：2017/12/30に追記）（って書いてたら、年が明けたけど、個人的にはあと3ヶ月は2017年の感じなので：2018/1/4にさらに追記） Asakusaで、先日0.10.0をリリースしている。ある程度刻んでリリースして行く、というのがAsakusaのポリシーではあるが、今回のリリースはちょっとした節目にはなっている。 http://www.asakusafw.com/ ◆一つの区切りとして とうとうというか、今更というか、ようやくというか。MapReduceのサポートについて一つの道筋をつけた。Hadoop界隈
クラウドのためのクラウド〜VMware Cloud on AWSの意味 - 急がば回れ、選ぶなら近道
記事とか詳細とかはこっち http://www.atmarkit.co.jp/ait/articles/1708/28/news097.html https://cloud.vmware.com/vmc-aws http://www.publickey1.jp/blog/17/vmwarevcloud_air.html まぁ概ねこんな感じ 単純に見れば、AWS上でVMWareが使えるので、VMで動いているシステムがそのままAWSで使えるようになりました。便利ですね。はい、おしまいの話ではある。が、それは二重の意味で「表層的」な見方だ。そもそもVMWareがクラウドから撤退し、AWSの軍門に降ったというエポックメイキングなものとして見るべきだと思う。 ・ハード調達の争いの決着 結局のところ、DCを含めたハードウェアの調達という点で、競争に決着がつきつつあるということかと。VMWareの規模を
「パブリッククラウドvsプライベートクラウドの終わり」の始まり - 急がば回れ、選ぶなら近道
遅めですが明けましておめでとうございます。そんな感じで。 基本的に社内向け。あとは特定のお客さん向け。 自分の意見を詳記しとく。あとこれは日本の話で、海外の状況は知りません。 ■「パブリック」クラウド ここでは、大規模メガクラウドを指す。よって、AWS・Azureあたりを考えている。国内クラウドとは明確に規模・技術力で差がついており、はっきり分けるべきと思っているので、ここではAWS・Azureとしている。多分SalesforceとかIBMのやつも入るとは思う。Googleのクラウドについては技術はぶっちぎりだけど、一般民間人には意図していること天才すぎて理解できる気がしないので範囲外とする。 基本的に「所有より利用を」コンセプトにし、使いやすさと低コストを全面に打ち出し、トレードオフとして共有故の仕組み/運用の「ある種の不透明性」を要求する仕組み。なお、不透明性ってのは、これは提供者の企
Asakusa 0.8 with M3BP - 急がば回れ、選ぶなら近道
Asakusaが新規に高速実行エンジン（M3BP）をサポートした。M3BPはメニーコア特化型のC++で実装されたDAGの実行エンジンになる。ノーチラスとFixstarsの共同開発のOSSで、単ノード・メニーコアでの「処理の高速化」に振っている。いわゆるIn-memoryの実行エンジンで、ノードのCPUコアを使い切ることを目標しており、余計な機能はすべて削った。データがサーバ・メモリーに乗るクラスのバッチ処理であれば、ほぼ物理限界までパフォーマンスをたたき出す。 http://www.asakusafw.com/release/20160412.html 実際のベンチマークは以下のwhite paperにある。 http://www.asakusafw.com/wp/wp-content/uploads/2016/04/M3forBP_WP_JA_2016Apr12.pdf ベンチマーク対象
ITは必要悪か？その2 - 急がば回れ、選ぶなら近道
大規模会社、特に社会インフラ系の会社で売上も兆に届くところでのITのあり方は、中小規模の会社とは全く違います。システム構築、とくにSI的な観点からは、実際のプロジェクト単位で見たときに大規模システムと中小規模システムを便宜的に一緒にして考察することが多いのですが、俯瞰したときのあり方は、まったくの別ものです。 大規模な会社では情報システムは、大きな組織のバックエンドの一部であると同時に、企業を動かす歯車として欠くことできない存在になっています。「ITがない」という選択肢は企業活動としてありえません。システムのあり方が大企業と中小企業では異なるため、中小企業でITの必要性という点と、大企業でのITの必要性では意味が大きく違います。明確に区別する必要があります。 ■あり方 大規模企業の内部において、情報システムはその企業が存続するための重要な機能を担っており、それなしでは企業は成立しません。大
ITは必要悪か？その1 - 急がば回れ、選ぶなら近道
もともとは2016年の年の初めに書こうかと思っていたことですが、時間も経ってしまっていたところ、アリエルの井上さんとの対談 IT屋はバズワードを使ってはいけない……のか？ (1/5)：EnterpriseZine（エンタープライズジン） も あって、ちょうどいいので記録的に思うところを書いておきます。 ・前提 ここではITと言う漠然とした言い方になっていますが、日本で最もマーケットの大きい、いわゆる業務システムを対象にしています。いわゆるSIの対象になるところです。と言っても一概に言えないので、売上2000億円程度の大規模企業の、下の方から、中小企業までの話にしています。売上が兆円単位の規模の社会インフラ系のシステムは、その2 ITは必要悪か？その2 - 急がば回れ、選ぶなら近道 で考えます。業務システムなのでコンシューマーものは考えてません。 ・ITは必要悪という認識 基本的にユーザ企
RSA（Rack-Scale-Architecture) - 急がば回れ、選ぶなら近道
一応、Asakusaのアドベントカレンダーのネタです。 いろいろ今後のAsakusaの対応について、現状を踏まえて一回まとめます。 1.ビックデータの敗北 まず、現状のビックデータの現状はちゃんと踏まえておきたい。というのは、いままでの分散処理の技術革新は、クラウド・ビックデータ関連を中心で進んできたわけで、当然次の流れはその「歴史」を考慮しなければ、ビジネス的な先はないでしょう。 まず、経験的には日本での「ビックデータ」の実行基盤としての大規模クラスターの展開はほぼ全滅に近いと思います。特に、日本ではPByteを越えるデータはその辺に転がっているものではありません。もちろん何百台・何千台ものクラスターを構成・運用しているところもありますが、おそらく十指を越える程度でしょう。日本の企業数が5万としても、99.9%の企業はそんなクラスターは持っていません。ただし、企業数が多いので結果としての
データセンターの原価計算について〜「クラウド」の別側面として - 急がば回れ、選ぶなら近道
要するにデータセンターの「原価計算」です。いろいろこのあたりに関わっています。複雑な計算ロジックと大量のデータを扱う必要があるので、大規模並列計算の適用が必須になり、結果として当方の出番になった、という状態。尚、実行基盤にHadoop（MapR）を利用しています。（一応予定ではSparkに移行するつもりで、開発も始まっています。） さて、いろいろやっていて思うところがあるので、現時点での考え方をまとめておきます。機微な部分はNDAになるので書きませんし、以下は自分の「個人的な」意見であり、特定のサービサーの話をしているわけではありません。基本的にInteropで公にしゃべった話のまとめです。 ■現状認識 現在、国内DCはほぼ乱立状態に近いと思われます。ここへ来て春先のAWSの値下げのインパクトもありました。今後は、より競争的なマーケットになるでしょう。退場する企業やM&Aも活発化していくで
業務系システムのクラウド適用の現状 - 急がば回れ、選ぶなら近道
2013年の夏・秋の状況の整理として記録しておきます。数年したら変わっているか、そもそも自分の仮説が違うかわかるのでそのポイントとしても記述しておきます。 4月以降、「業務系システムのクラウド化」ということで、顧客各社やマーケットへのヒアリングを行ってきています。対象はいわゆるWeb系は除いてあります。曖昧な言い方になりますが一般に「IT業界でエンタープライズ」と言われるセグメントにフォーカスしています。結果としてわかったのは、企業のクラウド利用についての意識は、言われているほどには高くはない、というのが現状です。ただし、これは一様に低い、ということではなく、かなり業界やセグメントや企業規模によって違いがあります。この違いの要因と今後どのようなところに影響するのか、というのが興味の焦点です。尚、これは自分個人の印象や某社でのヒアリングの整理のみをよりどころにしているので、たかだか200社弱
パトリオット法は日本のDCに適用されるのか？についてのメモ - 急がば回れ、選ぶなら近道
・Disclaimer自分は弁護士ではないし、その手の専門家ではありません。よってここに書いてあることを信じて、何かを行ってヤバい事になっても一切責任は負いませんし、それは自身の責任で処理してくださいね。まじめに会社の公式見解でもなければ、クラウドベンダーの代弁でもありません。 ・問題 自分の問題は以下、単純に「業務系システムを日本国内のDCのクラウドに上げている状態で、パトリオット法が適用された時に、そのクラウド上の業務系データが、一方的に米局政府に差し押さえられるということが起こりうるか？」という点につきます。 ・個人的な結論 結論から言うと、それは「ない」ですね。つまり、一方的かつ直接的に国内DCのデータが米国政府に押さえられることはないと思います。勿論、一定の要件を満たしたテロ等の嫌疑がある場合にはすべて正式の手続きに則った上で、米国当局の要請をうけて日本の司法がしかるべき手続きを
Making Snapshot Isolation Serializable 再考 - 急がば回れ、選ぶなら近道
Making Snapshot Isolation Serializable 再考 ■2013年的な位置付け まずちょうど年度の開始なので、今年は自分的にはRDBMS関連の位置付けとか整理しておきます。去年の後半あたりからの匂いですが、NoSQL的な発展と合わせて、本格的なDB回帰が始まっている感じです。NoSQL系のほぼ致命的な弱点の一つがtransaction処理であることは指摘も多いところです。要するにデータが書き込めても不整合が発生しますね、ということになってしまいます。これではなかなか使えない、というのが現状でしょう。 なので、RDBMの最良のノウハウであるtransaction処理とNoSQL的な分散処理をちゃんと整合性とれるようにしましょう、という自然な流れは従前よりもより強い要請が働くでしょう。(できるかどうかは別ですが。) それで、そろそろなんかその手のものがRDBMSサ
クラウド上にEDIを「移行する」ということの意味 - 急がば回れ、選ぶなら近道
ニュースリリースというか記事はこちら。日経の中田さんの記事ですね。 http://itpro.nikkeibp.co.jp/article/NEWS/20130306/461423/ この辺の解説を記録のために書いておきます。個人的にはちょっとしたマイルストーンなので。 まずEDIの定義ですが、これはElectronic Data Interchangeの略で、B2Bでの電子データ交換の仕組み自体をさします。歴史的にはITの歴史と同じくらい古い。当然インターネットよりも古い。昔は（場所によっては今も）電話で”ぴー”とか”がー”とかやっていた代物です。多分50年以上の来歴を誇る仕組みですね。業界ごとにその業界に応じたプロトコルが制定されており、いわゆる標準化がもっとも進んだ分野のひとつです。そして、大抵はミッションクリティカルな業務に属します。エンタープライズ系のITでは最下層に位置するレイ
軽減税率がITに与えるインパクト - 急がば回れ、選ぶなら近道
http://www.nikkei.com/article/DGXDZO50933940U3A120C1MM8000/ どうやら本格的に複数税率が消費税に適用されるようです。まだ、決定でもないし、今後の業界の猛烈な反対もあるだろうから、どうなるか分からないのですが、その辺を部外者的に（かつ元関係者的に）記録として書いておきますよ。 この軽減税率で、もっとも変更のコストがかかる「仕組み」の一つはITであることは、多分論を待たないと思います。特に、税率を複数適応する羽目になる流通・サービス系のITは下手をするとかなりのコスト負担になるところも出てきます。またか！またコストですか！いや、これこそがITなのですよ。 まず影響が出てくるところ予想すると、事の大小はありますが、ほぼ大抵のところで手を入れる必要がある気がします。んで、例によって、多分この辺が正確に予想できている、CIOを除く経営陣は皆無
Hadoop Conference Japan 2013で話したことと思ったこと - 急がば回れ、選ぶなら近道
Hadoop Conference Japan 2013 http://hcj2013w.eventbrite.com/ 先週終了。かなりの盛況で終わった感じです。まずは開催をサポートして頂き、相当の負担まで頂いたリクルート・テクノロジー様に感謝申し上げます。どうもありがとうございました。 さて、えっと、前回がそもそもいつだったのか、良く覚えてないわけで。2011 Fallだったような。 http://hadoop-conference-japan-2011-fall.eventbrite.com/ 2011年の9月なので、1年4ヶ月ぶりという感じですね。Track数が増えて2から3で、会場もベルサールからビッグサイトになっていました。人数も1000人超になっております。 以下、感想文です。記録としておいておく感じで。 ・内容で印象に残ったもの ・HBase~LINEのバックボーンで使って
バッチ処理を再考する - 急がば回れ、選ぶなら近道
最近そもそもバッチ処理というものを知らない人達を見ることが多くなりました。某プロジェクトで「いや、ストプロってよくわからないんですよ。最近書いたことないし。」という話をずーっと聞いていたのですが、本人はバッチ処理という意味で話していたことが後から判明した、ということがありました。 ああ、この人はSQLでのバッチ処理しか知らないのですね、とちょっと衝撃ではありました。とうとうそーゆー時代になったかと。 まず、誤解のないようにいうとバッチ処理、という言葉自体はIT固有のものではないです。生産管理や物流や、そういった業務では普通に「バッチ」という言葉をIT以外で使います。ただし意味はある程度同じで、「一定の塊を一度に処理をする」ということです。物流システムの業務要件なんかを詰めているとバッチっていうと、どっちのこと？なんて普通に聞かれたりします。その意味ではバッチの対義語がリアルタイムというのは
設立して1年経過 - 急がば回れ、選ぶなら近道
この10月でノーチラスの設立1年という運びになりました。お世話になったお客様・パートナー様・応援して頂いた皆さんに感謝申し上げます。ありがとうございます。 ということで気づけば一年経過ということで、陳腐なようですが「光陰矢のごとし」の一言に尽きます。思えばこの一年はいろいろありましたというか、有り過ぎました。 ■Asakusaの状況「Hadoopの使い方としてのバッチ処理」という意義は市場ではアクセプトされた感もあります。この一年は、SI屋さんを始めベンダーさんやトップ・ノッチのエンドユーザーさんでの検証・小手調べの期間だったかな、と思います。結果としては「まぁ確かに速くはなるね」という点と、「まぁ確かに開発効率は高いわね」という二点については、程度の差こそあれ、大抵の利用者・検証者には認識してもらえた感じです。 一年終了時点での市場でのプレゼンスはそこそこには出せているので、まずは及第点
A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道
元論文はこちら https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf 詳細なスライドはこちらになります。今年の夏のクラウド温泉で発表した内容です。一回見直して、若干手直しをしています。 http://www.slideshare.net/okachimachi/a-critique-of-ansi-sql-isolation-levels 論文の解説は割と意味があると思ったので、スライド自体は割とまじめに作りました。クラウド温泉では口八丁手八丁でいろいろ話しましたが、その辺はオミットしています。この論文の解説は探せば、いろいろ巷にはあるのですが、かなり苦闘して矢尽き刀折れ状態が散見されるので、多少なりとも状況が補修できればと思っておいておきます。（尚、当然ですが、内容が正確かどうかは
業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道
某DevLoveというところで話をしろ、ということでありましたので、いろいろ話をして来ました。 http://devlove.doorkeeper.jp/events/1733 まとめはこちら http://togetter.com/li/387189 あと、しんやさんの詳細なブログがこちら http://d.hatena.ne.jp/absj31/20121009/1349795347 スライドはこちら http://www.slideshare.net/okachimachi/devlove1 以下、ちょっと自分なりにまとめを。 ■自分なりにどう話したか 自分の仕事的にはHadoopとAsakusaでの課題解決が現在の本業です。ただ、Asakusaの位置づけとして、SIのための道具立てという側面が強く、また結果として会社も直接・間接にSIにはかかわっているので、割と現状の問題も意識して
MapReduceは今後どうなるのか？ - 急がば回れ、選ぶなら近道
2012年の現在、割と悩んでいるのでメモっておく。 年度末ぐらいに再調査の予定。・・なので暫定ですよ。 まず前提として、現行のHadoopの実行フレームワークであるMapReduceは、実行効率は決して良くはないです。この辺が割と辛い。 とはいえ、大規模並列処理を一般的に行うという観点での品質や取り回しを考えた場合、”結果として”非常にバランスがとれており、普及している。その上で、このMapReduceですが、今後の見通しについては、潮流は今のところ二つに割れているよう見える。ので、その辺のメモ。 ■YARN 一つの方向性は、現在のHadoop2.0系で実装されているMapReduce2.0、というか、MapReduceとは別の実行基盤を利用するという方向ですね。すなわちBSPや、MPIを利用する。要は、今までの並列処理の成果をそのまま利用しましょう、という流れに近い。 MapReduce
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
