「オンプレミス・システムの終わり」の始まり〜AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道
個人的には割と大変だったので、その辺をまとめておきます。 ニュースリリースはこちら。 http://www.nautilus-technologies.com/topics/20130409.html 要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。 システムの機能概要 1.売上の確定処理と債権管理 POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。 2.仕入・費用の計上と確定処理、および支払いデータの作成 費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI（BMS）との
MapReduceは今後どうなるのか？ - 急がば回れ、選ぶなら近道
2012年の現在、割と悩んでいるのでメモっておく。 年度末ぐらいに再調査の予定。・・なので暫定ですよ。 まず前提として、現行のHadoopの実行フレームワークであるMapReduceは、実行効率は決して良くはないです。この辺が割と辛い。 とはいえ、大規模並列処理を一般的に行うという観点での品質や取り回しを考えた場合、”結果として”非常にバランスがとれており、普及している。その上で、このMapReduceですが、今後の見通しについては、潮流は今のところ二つに割れているよう見える。ので、その辺のメモ。 ■YARN 一つの方向性は、現在のHadoop2.0系で実装されているMapReduce2.0、というか、MapReduceとは別の実行基盤を利用するという方向ですね。すなわちBSPや、MPIを利用する。要は、今までの並列処理の成果をそのまま利用しましょう、という流れに近い。 MapReduce
Welcome back to the TRANSACTION! - 急がば回れ、選ぶなら近道
最近、トランザクションの再勉強を始めていて、先日クラウド温泉でも発表させてもらった手前、ちょうどいいので一回まとめておく。はじめに断っておくと自分は別にDBやTXの専門家ではない。なので以下の内容の正確性については保証しない。内容については自分で勉強してくださいね。 1.「なんでまたTXなのか」 まずもって何故にTXなのか？というお話から始めます。もう枯れてんじゃないか？今頃RDBMSでもないだろう。それはそうですが、以下の流れは無視できません。 ・RDBMSの特許切れ NIIの佐藤先生の指摘にもあるように、1980-90年代のRDBMS関連の特許が切れ始めます。これにより商用一辺倒で、OSSではどうしても勝てなかったRDBMSでの技術革新や、その技術を応用した別のもの（RDBMSとは限りません）が登場してくる可能性が高いです。各ベンダーもそれを見越して、一斉にRDBMS関連への「逆張り」
CDH4説明会に行って参りました。 - 急がば回れ、選ぶなら近道
CDH4説明会に行って参りました。 日時：2012年7月6日（金） 場所：ベルサール八重洲 タイトル： 進化するHadoop：CDH4とCloudera Enterprise4.0のご紹介 アジェンダは以下の通り。 18:30 開場 19:00 開会のご挨拶（ジュゼッペ小林さん） 19:10 CDH4とCloudera Enterprise4.0（川崎さん） 〜エンタープライズにおけるHadoopの標準〜 19:50 CDH4はなぜエンタープライズに適しているのか（嶋内さん） 〜新しく導入された技術から読み解く〜 20:30 懇親会 21:00 閉会 以下、内容と感想をまとめておきます。スライドはあとで上がるそうなので、セミナーの詳細はそちらを参考にした方がよろしいかと。 あとはメモも上げられているので、こちらを見ると詳細がわかるかと。 http://d.hatena.ne.jp/gara
Distributed Control Break - 急がば回れ、選ぶなら近道
まず始めに断っておきますが、このワードの発案は@marblejenkaさんによるものです。個人的には、言い得て妙だと思っています。この手の言葉の使い方のセンスはマーブル先生は時々天才な時があり、このワーディングもそれに属します。尚、社内では「この言い方は若干、一種の中二病的な側面もある」という意見のため、公式のドキュメントから削除されています。残念です。よってブログに残す。 まずもってControl Breakですが、COBOLの必殺技のひとつで最上位古代魔法(ハイ・エンシェント・ロア)のひとつに属します。JavaとかJavaとかJavaとか、な人たちにはちょっと意味がわからない感じになりますが、ある一定の処理の固まりを順におこなっている時に、なにかのタイミングで（大抵はキーの切り替え）で別の処理を一時的に行う（コントロールがブレイクする）ことを言います。 まず単純な例では、例えば、明細が
業務系処理の分散処理の実行基盤について(Asakusa0.2.6) - 急がば回れ、選ぶなら近道
Asakusa supports for the multi-clusterというお話で、多分解説がいるので書いておく。公式に書くものではない、という意見も強いので、ここで書く。先日のSIGMOD日本支部のMtgでも発表した内容ともかぶりますが。 具体的にはここで http://asakusafw.s3.amazonaws.com/documents/0.2/release/ja/html/yaess/multi-dispatch.html いろいろ細かい内容は以下を参照で。 「AsakusaFW0.2.6の見どころ」 http://blog.goo.ne.jp/hishidama/e/2ba82d5ad404000de52d1a4029eb7346 まず、前提として現在のAsakusaは業務処理のバッチ処理、特に非同期処理を対象している。その上で実際に使われているし、SIも行われている。
「チームリーダーの１０か条」 - 急がば回れ、選ぶなら近道
ちょいと家を掃除してて、バックナンバーのフットボリスタの特集が「チームリーダーの10か条」になっておりまして。この雑誌、サッカーは海外でしか存在しません、とばかりに、日本代表とかガン無視の今時珍しいサッカー雑誌でございますが、なんとかいうかサッカーというより「文化」を記述しているのじゃまいか？ということが多すぎるわけです。この特集があまりにもサッカー以外に当てハマるので、ちょっとITにおけるチームリーダー論的に書いてみる。 1 「３０代のベテランが望ましい」ITチーム的には、これはありですね。確かに技術的な吸収力や体力では20代が優位で、政治力優位では40代に以降にはなる。とはいえ、ある程度の経験をもっている上で、かつ過度に政治的になっていない状態で、20代を御せるのは30代ですよ、ということは正しい。しかし、なんというか最近はベテランの勢いがなさすぎな感もあるので、なんとか頑張ってほしい
エンタープライズでOSSであるということ - 急がば回れ、選ぶなら近道
エンタープライズのOSSについて こんなこと書くとOSSなモヒカンな人にぶん殴られるわけです。読み手の方で、自分はOSSを引っ張ってきたと自負されている方や組織のかたや、OSSは商用より無条件で優れていると思っている人は気分が悪くなるので、読まないでください。非常に個人的なメモですので。以下の考えは基本的にソフトウェア・ビジネスとしての考えなので、自分で作って、自分で利用して、ムフフな人はあんまり考えてないので、そのつもりで読んでね。自分利用OSSはそれでいいと思うので、それでいいかと。 [まずAsakusaについて] まずAsakusaがなぜOSSかということを明確にしておきます。非常に単純です。Asakusaは様々な人の意見を集約してできています。これは別にNautilus-technologiesのメンバーというわけではなく、Hadoopコミュニティに参加した方の意見を相当取り入れて
Dosakusaフレームワークがリリース間近 - 急がば回れ、選ぶなら近道
ノーチラス社内でAsakusaと同時に開発されているフレームワークについて。 Dosakusaフレームワーク基本的にAsakusaフレームワークの上位で構成されているフレームワークで、Asakusaフレームワークの拡張仕様。N階層DSLにより構成される、現時点では100万階層まで確認されている。無数のオレオレDSLを、鬼の勢いでステージングコンパイルして、原型をなくして、最後はシンプルなニーモニックに変換しきる。可能コンパイルオプションは、guutara、shot、kobayashiの３つの隠しオプションがある。 -guutara 残念デバックモードになる。ちょっと間違うと、何やってんのそれ？とか言われる。よく見ると多少Haskellっぽい感じ。間違った箇所はなんか割と適当にでる。 -shot 若干まじめ愚痴デバックモードになる。筋があっていると、まぁいんじゃないでしょうか？というコメント
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
年始の抱負〜仕事の師匠から教わった事 - 急がば回れ、選ぶなら近道
2012年の始まりなんで。記録として書いておく。今年の抱負も含めて。 ちょうど会社も立ちあげたし、こんな事を書いても良い世代になってしまったと思うわけです。 えっと、自分が師匠とよべる人はふたりしかいなくて、しかも性格は正反対だった。しかしながら、二人とも仕事は異様にできた。あんなにできる人は今まで見た事がないし、今後も見ることは無いと思う。（今時「師匠」って言い方もどうかと思うが、他に適当な言い方もないし。死語ですけど。） 一人目の師匠は、掛け値なしの鬼軍曹だった。本気と書いてマジという位、本気で怖い感じだった。ついていける人はほとんどいなかったと思う。僕はたまたま仕事に集中して余計な事を考えたくなかった時期だったこともあって、ゾンビのように働いた。月の残業時間が400時間とかいう時もあった。（勤務時間ではない） 死ぬかと思った。 仕事のやり方は、もう軍隊のようだった。ミスしたら、ミスし
来年のHadoop - 急がば回れ、選ぶなら近道
Hadoopアドベント・カレンダーの多分最終日のはず。 せっかくなんで、来年の予想でもしてみようかと。 日本の話です。世界のことはよくわかりません。本当のことは、日本には伝わらない（表向きの話はともかく、現状ではVCあたりの外野の方が発言力があると思うし、向こうでも、その辺の正確な情報は伝播してる気がしません）と思うので。とはいえ、日本のHadoopマーケットは、それなりわかっている（というか、わかっていないとまずい）感じみたいなので・・・勝手に、来年のHadoopとか予想します。外れたら焼き肉おごります。 1 大量データ処理でのデファクト化 ・いわゆるWeb系ではつかっていないところは一社もなくなる 特にレコメンデーションエンジンあたりは、もう普通に実装して使う。ただし、それ以上のものは出ない。集計処理と推論をうまく利用したレコメンデーションエンジン（とその亜流）、従来からのフィルタリン
"BigData"では何が問題なのか？ - 急がば回れ、選ぶなら近道
”ビッグデータで奇跡が起こる” はいどうも。まず、個人的には楽天的な進歩史観には、まったく組しない。 従って、突然に新技術ができて、なんか凄い事になる、というのはさらにまったく同意しない。すべからくブレイクスルーは課題解決により起こると思っているので、問題意識のないところに、こんなものできました的な発想は、基本的にプラスにならないことが多いと思っている。現状のビッグデータブームは2011年の秋口現在は完全にハイプになっており、バブルと言ってもいいと思う。印象として、十数年前のナノテク・ブームに似ている。 とはいえ、過度の期待という側面を除けば、それなり効果もある部分もあり、”そこだけ”を見ていけばそれなりに効果はある（と思う）。大体において、今後は以下の二つのユースケース・カテゴリーに集約されると思う。すなわち、ビッグデータの拠り所はまずもって以下の２点だ。 1 Webのログ解析 というか
アトムとビット〜Hadoopでバッチが速くなって何がうれしいか？ - 急がば回れ、選ぶなら近道
まず、社内のオープニングで説明した内容だったりするのですが、一回まとめておきたいので。 断っておくとこの言い方はニコラス・ネグロポンティから取っています。彼の主張は明確でいままでアトム（物質）的な存在だったものが、ビット（電子情報）的な存在に凌駕される、いや大きく姿を変えてるという指摘でございますね。Being digitalが出版されたのが95年なので、もう15年以上になるわけですね。ま、ざっくりすぎてアレですが。・・ワーディングとして便利なので利用させてもらいます。 まず、主題は何かというと、「バッチが速くなって何がうれしいのか？」という問題の背景をちゃんと説明しておきたい。もともとHadoopで何がしたかったのかというと、そもそもバッチのスピードを上げたかった。そもそもRDBMSではまぁ限界があったというのが事の起こり。んで分散処理を行うとIOが分散されるので、スピードがあがりますね
Jubatusについて - 急がば回れ、選ぶなら近道
先週の月曜日にお披露目会的なものがあったので行ってきた。 ちょいと前半戦は見れなかったので、肝心なところを見てない説もあり、その辺は割り引きたいが、まず印象まで。 Jubatus http://jubat.us/ 基本的なラインは、言ってみれば、分散CEP+機械学習というコンセプト。（ある程度の）リアルタイム性を重視して、データの使い捨てをベースにして、スケールアウト戦略を選択している。溜めてから学習するのではなく、ストリーミングしながらの学習というコンセプトに見える。アーキテクチャはN:Nな感じ。耐障害性はどこまで見ているのか？ってのはあるが、まずはスループットを優先したのと、ボトルネックが発生しないように割と気を使っているのはわかる。おそらくもっとも重視したのは「使い勝手」だろう。 まず、現状の日本のITでは機械学習は使いこなすだけ精一杯という中で、アーキテクチャや仕組みまで考えたフレ
Mapreduce2.0 - 急がば回れ、選ぶなら近道
次世代Hadoopの開発が進んでいる。現状の推移では、少なくとも分散クラウドでの「OSSインフラ」としてはHadoopが最有力候補であることは間違いない。クラウド上での分散処理基盤での技術競争ではGoogleやAmazonが相当抜きんでいる現在、それに対抗しうる可能性があるOSSはHadoopの潮流の延長線上にしか考えられない。その形としてHadoop-MapReduce2.0があるように見える。現在の状態で自分なりの次世代Hadoopの理解をまとめておく。基本的に全部は見切れていないので、そのあたりはあしからず。基本的に次世代Hadoopの仕組みは大きく二つの要素からなる 現在のところの柱はHDFSとMapreduce2.0の二つだ。 まずMapReduce。これは従来の「MapReduce」というものからはほど遠い。むしろ「任意」の分散処理実行フレームワークにたいして、適切なリソースを
「テクノロジーとイノベーション」 - 急がば回れ、選ぶなら近道
難解で知られるブライアン・アーサーの新刊 「テクノロジーとイノベーション―― 進化／生成の理論」 http://www.amazon.co.jp/%E3%83%86%E3%82%AF%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC%E3%81%A8%E3%82%A4%E3%83%8E%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E2%80%95%E2%80%95-%E9%80%B2%E5%8C%96%EF%BC%8F%E7%94%9F%E6%88%90%E3%81%AE%E7%90%86%E8%AB%96-%EF%BC%B7%E3%83%BB%E3%83%96%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%BB%E3%82%A2%E3%83%BC%E3%82%B5%E3%83%BC/
Hadoop Conferene Japan Fall 2011 - 急がば回れ、選ぶなら近道
Hadoop Conference Japan Fall 2011が 終わったので、その印象を記録しておきたい。 詳細は、日経の中田さんの記事が 今のところ一番的確な感じ。 Hadoopカンファレンスが開催、本格普及を見据えた支援サービスや先進事例が充実 | 日経 xTECH（クロステック） 内容はこの方の記事がすげーので Attending Hadoop Conference Japan 2011 Fall in Shinbashi, Bellesalle Shiodome! #hcj11f - #garagekidztweetz また別の方のブログ記述もあるので、参考に。 http://d.hatena.ne.jp/smg-engineer/20110926/1317067540 まずは、主催して頂いたリクルート社の方々に 厚く御礼申し上げたい。本当にありがとうございました。 凄く大変
Hadoop MapReduce デザインパターン - 急がば回れ、選ぶなら近道
Amazon CAPTCHA Hadoop MapReduce デザインパターン の監修という事をさせたもらったので その内容とかについてですね。 まず、元の本はこれです。 http://www.amazon.co.jp/Data-Intensive-Processing-MapReduce-Synthesis-Technologies/dp/1608453421/ref=sr_1_1?s=english-books&ie=UTF8&qid=1316817977&sr=1-1 著者のJimmy Linは 現在Clouderaに所属と聞いています。 （が、割と所属不明な感じみたいです。） 現実にClouderaのトレーニングの内容は 特にアプリサイドの、かなりの部分を この本の内容に準拠していました。 なので、Hadoopを利用する際には ほぼ必須の書籍と見ていいと思います。 この本の特長と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
