Kubernetesがコンテナ時代のソフトウェア産業を全面的に支配、大企業もCloud Native Computing Foundationに参集する

駅を出て徐々にスピードを増す列車のように、Cloud Native Computing Foundationは急速に強くなり、テクノロジー業界の大物たちを吸引してきた。過去1か月半だけでも、AWS, Oracle, Microsoft, VMwareとPivotalなどがこぞって参加した。

これらの企業は必ずしも毎日仲が良いわけではないが、しかしそんな中でKubernetesは業界の必須のツールへと育ち、どの企業もCNCFに参加してそのミッションをサポートすることが必要だ、と考えている。これは部分的には顧客の要望によるものであり、そして残りの部分は、Kubernetesやそのほかのクラウドネイティブ技術に自分も口出しをしたいという欲求の表れだ。

この団体はLinux Foundationの傘下にあり、最初はGoogleが開発したオープンソースのプロジェクトKubernetesもこの親団体の管理下にある。Kubernetesはコンテナ化されたプログラムのオーケストレーション部分を担う。そしてコンテナは、ソフトウェアを、以前のように大きな一枚岩的なプログラムとしてではなく、マイクロサービスと呼ばれる離散的な小片の集まりとして配布するための形式ないし方法である

過去2年ほどはDockerがコンテナの普及に大きく貢献し、コンテナ化されたプログラムを作るための共通的な方法をデベロッパーに提供してきた。そして今では、企業はこれらのコンテナ化されたアプリケーションを“クラウドネイティブ*に”動かすことを欲している…CNCFの事務局長Dan Kohnはそう語る。〔*: cloud-native, ‘クラウド生まれ’、アプリケーションの作成も実稼働もクラウド上で行われること。〕

彼の説明によると、企業がAWS, Azure, GCPのようなパブリッククラウドへ行くにせよ、あるいはオンプレミスのプライベートクラウドでアプリケーションを動かすにせよ、どちらの場合も同じ技術がベースになる。アプリケーションがどっちにあっても、Kubernetesはそれらを整合性のある形で動かし管理するためのツールを提供する。

コンテナ化されたクラウドネイティブなアプリケーションをローンチする企業にとって、Kubernetesはオーケストレーションとオペレーションのレイヤを提供し、それを軸として驚異的なほど高い生産性が実現する。だから冒頭に挙げた巨大企業ですら、そのことを認識して、今やCNCFというバスに乗り込んでくるのだ。

というわけで、すべての中心にあるものはKubernetesだが、Kohnによるとそれは、見た目ほどシンプルではない。コンテナオーケストレーションツールを採用しCNCFに参加することには、企業目的が伴っている。“全員が輪になって手を握り合い、Kumbayaを歌う、という状況ではない。同じ顧客を奪い合う競合関係もある。しかし彼らは、コンテナオーケストレーションツールをめぐって争っても一文の得にもならないことを、十分に理解している”、とKohnは語る。

Kohnによると、Kubernetesは今やコンテナオーケストレーションのデファクトスタンダードだから、企業はもはやその部分では競合せず、コンテナの管理体験を向上させるそのほかの部分のサービスで優位に立とうとしている。業界の大物たちも、コンテナのオーケストレーションは今や解決済みの問題であり、今さら車輪の再発明に取り組むのは愚かである、という認識を共有している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Apache Flinkの商用化企業Data ArtisansがFlinkアプリケーションのためのApplication Managerを発表

オープンソースの分散ストリームプロセッサーApache Flinkの商用部門Data Artisansが、ストリーミングアプリケーションを管理するための新しいツールを含む、このプラットホームの商用バージョンの、アーリーアクセスリリースを発表した。

Data ArtisansのCEO Kostas Tzoumasによると、リアルタイムでストリーミングを行うプロダクトを管理するアプリケーションは、それを自分で作ろうとする顧客にいくつかの難題をつきつけるので、同社のApplication Managerはその難題を解決するために設計されている。

Netflix, Alibaba, INGなど大手のFlinkユーザーには、そのようなツールを自作して大量のストリーミングアクティビティを管理しモニタする能力があるが、平均的な企業にはそんな贅沢ができない、とTzoumasは語る。

そんな顧客が作って使っているアプリケーションは、さまざまな外部システムと対話するものが多く、しかもそれをやりながら、大量のデータを、ほぼリアルタイムで処理しなければならない。Data Artisansは、そういう処理につきまとう複雑性を軽減するために、管理の部分を担当するツールを作ったのだ、とTzoumasは説明する。

その新しいツールはFlinkを通るすべてのストリーミングアクティビティを一箇所で集中的に管理する管理コンソールを提供する。そしてストリーミングデータのデータソースやデベロッパーのワークフロー、サービスのデプロイアーキテクチャ、ロギング、メトリクスなどを一望できる。

Apache Flinkを利用しているストリーミングアプリケーションと対話するすべてのサービスを管理できるだけでなく、そのツールを使ってデベロッパーがアプリケーションの開発過程を管理できる。完成したそれらのアプリケーションは、Kubernetesのようなコンテナオーケストレーションツールを使ってローンチする。

さらに、Apache Flinkのストリームに関連するすべてのユーザーアクションの監査証跡を記録するから、デプロイ後にそのステップをさかのぼって調べることができる。

ファウンダーのTzoumasとCTOのStephen Ewenは、Apache Flinkを学生時代に作り、2014年にはその商用化を行う企業としてData Artisansを創業した。標準的なオープンソースのビジネスモデルを採用して顧客がApache Flinkをサポートできるようにし、また企業がApach Flinkによるストリーミングアプリケーションを作るときにはコンサルタントとしてそれを手伝う。しかし、そうやって企業顧客との付き合いを重ねる中で、管理ツールの不在に新たなビジネス機会を見出したのだ。

彼らの会社はベルリンにあり、これまで700万ドルを調達した。今、Apache Flinkのダウンロード回数は1か月に1万ぐらいだ。この記事で取り上げた商用バージョンは2017年の終わりから2018年の初めにかけて一般公開される。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Kafkaクラスターの自動ロードバランシングツールCruise ControlをLinkedInが発表

今日(米国時間8/28)サンフランシスコで行われたKafka SummitLinkedInが、KafkaのクラスターのためのロードバランサーツールCruise Controlを発表した。

LinkedInが開発したオープンソースのメッセージストリーミングツールKafkaは、それを使えば、ネットワーク上で大量のデータをアプリケーション間でリアルタイムに送受するタスクが簡単にできる。Cruise ControlのプロジェクトをリードしたソフトウェアエンジニアJiangjie Qinによると、Kafkaは今、ほとんど必須のツールになっているので、今LinkedInには専用のサーバーが1800台、それらが…つまりKafkaが…一日に2兆あまりのトランザクションを動かしている。

これだけの量であれば当然、Kafkaのクラスターを正常に動かし続けることはユーザーの企業にとってミッションクリティカルであり、そこで今年早期にチームは、クラスターの異状を見つけるツールを作ろうとした。そしてそのツールは、既定の一連のルールに従ってクラスターを自動的に構成し、適正な数のリソースを使用し、不具合を自己修復して動き続けるようにする。そのツールが、Cruise Controlになった。

Cruise Controlを作る前には、クラスターがダウンするたびにそれを手作業で再構成しなければならず、しかもQinによると、再構成に不正があると将棋倒しのようにほかのクラスターたちに悪影響が及ぶ。若干の人間の監視のもとに、マシン自身にクラスターの管理をやらせれば、その過程が大幅に単純化され、成長するネットワークのニーズに合わせてクラスターの修復作業のスケーリング(規模拡大)も可能になり、技術者たちが手作業でやっていたときに比べると仕事は大幅に効率化される(人力では不可能なほどに)。

Qinの説明によると、それらはロードバランシングの問題に帰結する。クラスターは、他のクラスターに迷惑をかけずに、正しい数のリソースで動いているか? 彼によるとこの問題はさらに、よくある構成上の問題を見つけ、ひとつひとつのクラスターに適正な目標を適用することに帰結する。人間でなく機械なら、クラスターのニーズを素早く評価し、一連の一般的な構成および目標と比較対照し、正しいものを選ぶ。

Cruise Controlはその際、この最適化プランでよろしいか?と人間に尋ねる。

なぜそんなツールが、もっと前からなかったのか、それについてQinは、技術者の数を最近増やすまでは、そっちにリソースを回す余裕がなかった、と答えた。

クラスターの構成とリソースの使用量を機械にチェックさせる今回のソリューションが完成するまでに、約半年を要している。同社はこのツールをオープンソースでリリースし、Kafkaクラスターのロードバランシングを改善するだけでなく、そのほかの分散システムにも同じロードバランシングの原理を適用できるようにしたい、と考えている。いろんなユースケースで、便利に使えるはずだ、とQinは述べている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Red HatのコンテナプラットホームOpenShiftのアップデートに外部サービスへの接続インタフェイスを導入

Red Hatが今日(米国時間8/9)、OpenShiftプラットホームの今四半期のアップデートをリリースし、社内や社外のさまざまなサービスへの接続を作る機能、Service Catalogを新たに加えた。

OpenShiftは、KubernetesDockerをベースとするPaaSで、コンテナのスタンダードとしてOpen Container Initiativeを採用している。KubernetesはGoogleで開発されたコンテナ管理プラットホーム、Dockeは広く使われているコンテナ作成プラットホームだ。

企業が仮想マシンからコンテナへ移行していくに伴い、OpenShiftのようなコンテナデプロイプラットホームのニーズがますます高まっている。そして今やRed Hatの顧客の中には、Deutsche Bank, Volvo, United Healthのような有名大企業もいる。

Red HatでOpenShiftを担当するプロダクトマネージャーJoe Fernandesによると、コンテナへ移行しようとする企業は最近ますます多くなり、すべての企業が何らかの形でコンテナの採用を目指していると言っても過言ではない。今では“いちいち表に書ききれないほど多い”、と彼は言う。

同社の、コンテナを利用する顧客ベースの増大とともに、大企業のIT部門の現実的なニーズを満たす、コンテナ化アプリケーションの展開プラットホームが重要になっている。とくに最近よく聞くニーズは、コンテナ化したアプリケーションが社内や外部のサービスに容易に接続できるようにしてほしい、という要望だ。

Service Catalogは、アプリケーションストアみたいな機能で、デベロッパーがそこへ行って構成済みのコネクターを見つけ、それらをサービスへのインタフェイスとして利用する。それは会社のOracleデータベースへのコネクターのこともあれば、AWSやAzureのようなパブリッククラウド、すなわち社外的サービスへのコネクターのこともある。Fernandesによると、アプリケーションストアの比喩は適切だが、今のところ正規の調達の手順は組み込まれていない。それが今後の課題だ、という。

これまでも、顧客がサービスへの接続を自作できたが、それには大量の作業を要した。ユーザーの面倒な作業を要しない、パッケージ化されたやり方でないと、時間と労力を取られすぎる。

そのために登場したService Catalogは、今回のリリースではテクニカルプレビューだ。次のリリースは、今年の終わりになる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

ConfluentがKafkaによるメッセージングシステムの長年の夢、‘正確に一度だけ’をついに実現

オープンソースの分散メッセージストリーミングツールApache Kafkaの商用化サービス(リアルタイムデータストリーミング)を提供しているConfluentが今週、Kafkaのユーザーにとって嬉しい機能を発表した。それは、Kafkaを使ってメッセージを、“正確に一度だけ”送る能力だ。

それのどこがすごいのか、門外漢には分かりづらいが、Kafkaのような高速メッセージングツールを使っている人たちにとっては、長年の見果てぬ夢だった。コミュニティの人たちは、実現不可能とも思っていた。

通常、メッセージを送る側は、それが届いたという受信確認を待つ。しかしConfluentのCTO Neha Narkhedeによると、Kafkaのような分散メッセージングシステムでは、途中で問題が起きることがある。コンピューターのエラー、ネットワークの障害、などなど。しかしたとえば金融関連のトランザクションなどでは、メッセージは確実に一度だけ送られてほしい。二度以上は、ノーだ。

多くの人びとが“正確に一度だけ”は達成不可能な目標と考えているのは、それを実現するためのスピードと正確さのトレードオフが大きすぎるからだ。しかしNarkhedeによると、同社はこの問題に大量の技術者をつぎ込み、1年がかりでやっと、長年探し求めていた解に到達した。

それを実現している技術的細部はきわめて多い。そしてNarkhedeによると、随所に技術的なトレードオフもあるが、でもみんなが考えるほど多くはない。というか、彼女によると、同社はこの問題を解決しただけでなく、メッセージのスピードを犠牲にすることなくそれを達成したのだ。

“正確に一度だけのモードでも、パフォーマンスのオーバヘッドはほとんど無視できる。そして通常モードでは、パフォーマンスは従来より向上した”、と彼女は語る。

その新しいリリースは、通常の利用で20%速くなり、“正確に一度だけ”の機能を使うと3〜10%のスピードペナルティが生じる。彼女によると、正確に一度だけではつねに多少のオーバヘッドは生ずるが、今後数か月の努力でそれをできるだけなくしていきたい、という。

彼女によると、この機能を眉唾で見ている人がまだ多い。頭がおかしいんじゃないか、と言う人もいる。長年、誰も解決できなかった問題だ。実際にそのとおり動くことを、どうやって確認するのだ? …彼女はコミュニティが抱(いだ)いている疑念を、このように表現した。

“何千時間もテストをした。パフォーマンスにはとくに気をつけた。Kafkaのアーキテクチャを抜本的に再検討し、全体的な高速化を図った。一年がかりで、やっと使えるようになった”、とこれまでの努力を彼女は説明する。

Confluentは3月に5000万ドルを調達し、調達総額は8000万ドルになった。Kafkaは最初、LinkedInで作られ、その後オープンソースのコミュニティへ移った。Confluentは、2014年に創業された。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Facebookは同社社員にAdobeのCreative Cloudを使わせるためのIT管理ツールをオープンソース化、Facebook固有色はない

Facebookでは、IT部門のことを“IT”と呼ばず、“エンタープライズエンジニアリングオーガニゼーション(enterprise engineering organization)”と呼ぶ。Facebookのクライアントプラットホーム担当エンジニアNick McSpaddenによると、Facebookぐらいの大きさの企業になると、ITはベンダーのプロダクトのボタンを押すだけの仕事ではなくなるからだ。そしてそのことを強調するかのように同社は今日(米国時間6/21)、AdobeのCreative Cloudのプロダクトを社員に使わせるための内部的IT管理サービスオープンソースにした

Facebookのそのエンタープライズ〜〜オーガニゼーションは今、3万台近くのコンピューターと4万近いモバイルデバイスを管理している。ラップトップとデスクトップの多くはOS Xだが、Windowsマシンも約8000台ある。“組織が大きくなりすぎると、もう、ベンダーからターンキーのソリューションを大量に買い付ければすむ、という状態ではなくなる”、とMcSpaddenは強調する。そこでオーガニ〜〜のチームは、たくさんのオープンソースツールを使って、必要に応じて独自のソリューションを構築することになる。McSpaddenの説によると、ベンダーが彼らのソリューションを作るときには、メインストリームのユースケースを想定しがちだが、でもつねにエッジケースはある。そしてFacebookぐらいの巨体になると、エッジケースはどんどん増えてITチームの生産性を干上がらせる。

今回Adobeのプロダクトに社員がアクセスするためのツールをオープンソースにしたのは、至るところで使われているベンダーだし、ユーザー数も多いからだ。そのFacebookのスクリプトを一般企業が使うと、Adobeのサブスクリプションへの新しいアカウントを企業レベルの裁可のもとに作成することが容易にできるし、特定のユーザーに特定のツールへのアクセスを与え、あとでそのアクセスを必要に応じて取り去ることも簡単にできる。

McSpaddenによると、この新しいツールがオープンソースになったことをAdobe自身も喜んでおり、またそのコード中にはFacebook固有の部分は何一つない、と強調した。“Facebookだけでしか使えないものを公開する気はない。現状のままで誰にでも使えるものをリリースしたい”、と彼は語る。

コードはGitHub上にあり、McSpaddenは曰く、Facebookは外部からのコントリビューションを大歓迎する、と。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

MicrosoftがオープンソースのPaaSプロジェクトを支えるCloud Foundry Foundation に参加

Microsoftが今日(米国時間6/13)、Cloud Foundry Foundationに参加する、と発表した。この団体が運営するオープンソースで非営利のPaaSプロジェクトCloud Foundryは今や、Fortune 500社の約半数が利用している。

Microsoftは同団体に、Google, Huawei, Ford, GE Digital, NTT, Philips, Swisscomなどと同じくGold Member(ゴールド会員)として参加し、このプロジェクトを支援していく。Googleは昨年12月に加わり、また同財団の元CEO Sam Ramjiを雇用した。

Cloud Foundry FoundationのCTO Chip Childersによると、プロジェクトにMicrosoftが公式に参加したことにより、今では最大の巨大クラウドプラットホームのうちの二つ(GoogleとMicrosoft)がこのプロジェクトを支持していることになる。ということはもちろん、両プラットホーム上の企業顧客からの需要も期待される、ということだ。

まだここにいないのは、言うまでもなく、Amazonだ。“彼らが来れば歓迎する”、とChildersは言うが、最近のAmazonは徐々にオープンソースの世界で活動するようになってきたとはいえ、Cloud Foundry Foundationへの参加については、現状ではまだ何も言えない雰囲気だ。

MicrosoftのAzureのPM Corey Sandersは、今週シリコンバレーで例年のサミットを開くCloud Foundry Foundationへの参加についてこう語る: “そうなればわれわれのソリューションのデリバリ能力がより深くなり、コミュニティを大きくでき、Cloud Foundryの統合も拡大できる”。

彼の話が具体的に意味しているのは、Azure DatabaseとPostgresSQLおよびMySQLのバックエンド統合により、それらをCloud Foundryベースのアプリケーションのバックエンドデータベースにできることだ。Azure上のPostgreSQLとMySQLは、数週間前に同社のデベロッパーカンファレンスBuildでローンチされた。同社は今日さらに、Azure Cloud Shell上にCloud Foundryのコマンドラインツールを加えたことを発表した。これも、ローンチの機会はBuildだった。

Microsoftは今年初めにDeisを買収したことによって、Cloud Foundryと関わりの深いデベロッパーチームと、またとくにOpen Service Broker APIを獲得した。このAPIを使えばデベロッパーやISVs(デベロッパーショップ)やSaaSのベンダーなどが、自分のアプリケーションを容易に、Cloud FoundryやOpenShift、Kubernetesなどのプラットホームで動くアプリケーションから可利用にできる。DeisがMicrosoftに入り、そしてMicrosoftがFoundationに入ったことによって、Sandersによれば、今後Service Brokerのサポートがさらに増える、という。Microsoftは、Open Service Brokerのワーキンググループにも公式に参加する。

MicrosoftがCloud Foundry Foundationに参加して、最初のうち何をやるのか。Sandersによると、初めはもっぱら、“勉強と、コミュニティへの深いレベルでの参加”だそうだ。

なお、MicrosoftはこれまでもCloud Foundryの各種プロジェクトに活発に関わっている。だから今日の発表は、この関係をより強化するものだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Cloud Foundryがクラウドネイティブのスキルを涵養するためデベロッパー資格認定事業を開始

Cloud Foundryは大規模なオープンソースプロジェクトで、企業はこれを利用して自社専用のPaaSをホストし、自分のデータセンターやパブリッククラウドでクラウドアプリケーションを動かす。同社は今日(米国時間3/29)、そのためのデベロッパーを育成するため、“Cloud Foundry Certified Developer(Cloud Foundry認定デベロッパー)”事業のローンチを発表した。

Cloud Foundry Foundationはこれを、“世界最大のクラウドネイティブデベロッパーの資格認定事業”、と呼ぶ。その成否を今から云々することはもちろんできないが、すでにDell EMC, IBM, SAP and Pivotal(Cloud Foundryのインキュベーター)などが支援している。同社はLinux Foundationとパートナーして、そのeラーニングインフラストラクチャから資格認定事業を提供していく。〔*: クラウドネイティブ, 既存の何かをクラウド化するのでなく、最初からクラウド上で動くものとして開発すること。〕

目に見える資格認定があれば、デベロッパーはオープンソースのクラウドに関する自分のスキルを他に示すことができる。この事業は、現在Cloud Foundryをサポートしている大手のパブリッククラウドプラットホームすべてを対象とする。それらは、Huawei, IBM, Pivotal, SAP, Swisscomなどだ。

約4時間で終わる300ドルの試験は、Cloud Foundryの基礎、クラウドネイティブなアプリケーションのセキュリティ、アプリケーション管理とコンテナの管理などをカバーし、また、JavaやNode.js、Rubyなどで書かれたシンプルなアプリケーションの書き換えも試験に含まれる。範囲がきわめて広いと思われるが、でもこれだけの分野で有能なデベロッパーなら、仕事を見つけるのも早いだろう。

Cloud FoundryのCTO Chip Childersが今日の発表声明で言っている: “企業はクラウドネイティブなアプリケーションを構築し管理できるデベロッパーを必要としており、そしてデベロッパーは仕事が必要だ。弊社はそこにある大きなギャップに着目し、デベロッパーとエンタープライズの両者が必要とするものを提供することを、弊社の機会と認識している”。

この事業の立ち上げは、必ずしも意外ではない。Childersはすでに昨年の11月に、これを今準備中、と語っていた。

この資格認定事業は今はベータで、一般供用は6月13日からになる(その日はCloud FoundryのSummit Silicon Valleyカンファレンスの初日で、そこでデベロッパーは個人でこの試験を受けられる)。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Googleが同社のオープンソースプロジェクトをすべて一箇所にまとめたサイトをオープン、関連ドキュメントも充実

Googleが今日(米国時間3/28)、同社のオープンソースプロジェクトをすべて一箇所にまとめたサイトを立ち上げる。

これらのプロジェクトのコードは今後もGitHubと、Google自身がホストしているgitサービス上にあるが、この新しいサイトの機能はそれらのための中央的ディレクトリ(目録)だ。しかもGoogleのプロジェクトを陳列するだけでなく、Googleがソースコードをオープンにする場合のGoogle独自の“やり方”を開示することも目的だ、という。

Googleの社内におけるオープンソースのやり方については、すでにいろんなドキュメントが公開されているから、今さら何を、という部分もあるが、Googleの今日の発表声明はこう言っている: “弊社のポリシーと手続きは、われわれ自身の長年の経験と、そこで学んだことを反映している。オープンソースへの弊社独自の取り組みが、誰にとっても正しいとは限らないし、むしろいろんなやり方があって当然だから、これらのドキュメントを‘ハウツー・ガイド’としては読まないでいただきたい”。

現在これらのドキュメントがカバーしている話題は、Googleが新しいプロジェクトをリリースするときのリリースプロセスに関する情報や、プロジェクトへのパッチを提出するやり方、そして同社がサードパーティのオープンソースプロジェクトを社内的に利用するときの取り扱い方、などだ。

最近GoogleはKubernetesやTensorFlowをオープンソースにして、そのまわりに大きなエコシステムをすでに作り出し、成功しているから、これらのドキュメントを詳しく読めば、大いに参考になることだろう。とくに、今後自分たちのプロジェクトやツールをオープンソースにしていきたい、と考えている企業にとっては。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Confluentが$50Mを調達してApache Kafkaの商用化にますます邁進…巨大テク企業の不可欠の構築ベースへ

オープンソースのストリーミングデータベースプロジェクトApache Kafkaの商用サービスを提供しているConfluentが今日(米国時間3/7)、5000万ドルの資金調達を発表した。

そのラウンドはSequoiaがリードし、BenchmarkとIndex Venturesが参加した。SequoiaのMatt Millerが、これを機にConfluentの取締役会に加わる。これで同社の資金調達総額は8000万ドルになる。

Kafkaは一種のメッセージングシステムだが、LinkedInがこれを最初にオリジナルで作ったときは、大量のデータをアプリケーション間、システム間、オンプレミスとクラウドの間などでスムーズに移動することが目的だった。一度にものすごく大量のメッセージを扱えることが、要件とされた。

ConfluentのCEO Jay Krepsによると、LinkedInのチームは、企業内のすべてのデータを、それらがどこにあろうと扱えて、またデータへのアクセスや応答がどこからでもできることを目標とした。“毎日1兆件のメッセージをリアルタイムで処理できるそのシステムをわれわれはオープンソースにして、シリコンバレー全域に普及させた。今の巨大テクノロジー企業の中には、Kafkaを軸として構築されているところが少なくない”、という。

内部システムの中核としてKafkaを使っている企業の例として、Netflix, Uber, Cisco, Goldman Sachsなどが挙げられる。リード投資家SequoiaのMatt Millerは、事前にこれらユーザー企業に聞き取りをして、Confluentの今後の市場が巨大であることを確信した。“Confluentは次の10年でもっともインパクトの大きい企業になりうる、とわれわれは見ている”、と彼は語る。

Confluentには無料のコミュニティエディションもあるが、企業ユーザーの多くは補助的ツールの揃った有料エディションを使いたがる。それらのツールは、複雑な企業内におけるデータフローを管理しモニタするツール、Kafkaのクラスタ上におけるデータフローの最適化と均衡化のために全社的なデータフローを追跡するツールなどだ。さらにConfluentは、いくつかのサポートプランを用意している。

Millerによると、社内の多様なシステムをKafkaを使わずに接続することはできるが、それは効率が悪くて費用も大きい。“多くの企業が、場当たり的な統合化や、時間のかかるバッチ処理でお茶を濁してきた。Kafkaを使えば、もっと安上がりに大量の情報を共有できるし、古いシステムから乳離れしてマイクロサービスへの移行もできる”、と彼は説明する。

大量のデータを扱えてしかもさまざまなシステムと迅速にコミュニケートできるKafkaは、IoTにもすごく向いている。数年後にはIoTが生成するデータが膨大な量になり、しかも企業は、それらのデータを迅速有効に利用するための方法を必要とするのだ。

今度の5000万ドルの使いみちとしてKrepsは、急速に成長している市場への対応能力の完備を挙げる。“この動きの激しい分野で先頭を走っているのだから、今後も先頭を維持しなければならない。順位が下がることは許されない。これからも、このカテゴリーの定義といえばこれ!、と言えるような技術を作り出し、それを世界中の市場に持ち込む必要がある”、と彼は語る。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Googleの大規模分散システムに適した高効率のRPC実装gRPCがCloud Native Computing Foundationに寄贈された

shutterstock_268614635

Googleが今日(米国時間3/1)、同社の高性能なリモートプロシージャコール(remote procedure call, RPC)フレームワークgRPCを、Cloud Native Computing Foundation, CNCF)に寄贈する、と発表した。CNCFはすでに、Google生まれのコンテナオーケストレーションツールKubernetesやそのほかのコンテナおよびマイクロサービス関連のプロジェクトを普及させていくための、ホームになっている。gRPCはCNCFのポートフォリオの6つめのプロジェクトだ。

gRPCやApache ThriftのようなRPCフレームワークは、アプリケーションが自分と同じマシンまたはリモートのサーバーで動いている別のアプリケーションのコード(プロシージャ)を動かしたり、その結果をもらったりするための技術的枠組みだ。その点ではREST APIの仕組みにも似ているが、RPCが実際にリモートのコードを…まるでプログラミング言語が関数/ファンクションを呼び出すときのように…動かす(呼び出す、コールする)のに対して、RESTは特定のリソース(処理の結果)を得ることが主な目的だ。

grpc

GoogleはgRPCを2015年にオープンソースにした。そのとき同社は、このフレームワークを使って自分たちのマイクロサービスの多くを動かしている、と述べた。そのことは、今でも変わらない。2015年の同社の説明では、“gRPCは分散システムの構築における長年の経験がベースになっている。この新しいフレームワークを利用してデベロッパーが、現代的で帯域効率とCPU効率の良い、そしてレイテンシーの低いやり方で、複数のデータセンターにまたがる大規模な分散システムや、モバイルアプリの駆動、リアルタイム通信、IoTデバイス、そしてAPIなどを作ってほしい”、と言っている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

デベロッパーが直面する難題、オープンソースのライセンス管理を助けるFOSSAが$2.2Mのシード資金を獲得

Shot of a young programmer working in a dimly-lit office. All screen content is designed by us and not copyrighted by others, and upon purchase a user license is granted to the purchaser. A property release can be obtained if needed.http://195.154.178.81/DATA/i_collage/pi/shoots/783867.jpg

FOSSAは、デベロッパーのために、オープンソースのライセンスの管理という面倒な仕事を助けたい、と願っている。その同社が今日(米国時間2/23)、220万ドルのシード資金の調達を発表した。また、その社名と同名のプロダクトが、今日から公開ベータで提供されることも発表した。

今回の投資はBain Capital Venturesがリードし、Salesforceの会長でCEOのMarc Benioff, YouTubeの協同ファウンダーで元CTOだったSteve Chen, Skypeの協同ファウンダーで元CTOのJaan Tallinn, Clouderaの協同ファウンダーでCTOのAmr Awadallah, Tinderの協同ファウンダーでCMOのJustin Mateen、というオールスターメンバーが参加した。

これらの個人たちは、オープンソースのライセンス管理が重要かつ困難な仕事であることを、十分に理解している人たちのようだ。FOSSAの22歳のファウンダーKevin Wangによると、今時(いまどき)のプログラムは一連のオープンソースおよびサードパーティ製の部品で組み立てられる傾向があるが、しかしその一つ々々に独自の権利要件がある。それらすべてと正しくつき合っていくことはデベロッパーにとって大変な仕事であり、しかも既成のソリューションは乏しい。というか、今はほとんどの人がスプレッドシートを使って手作業でライセンス要件をチェックしている、とWangは述べる。

“今年はすでに2017年だが、私たちは未だに、自分が何を作って何をリリースしたのかをよく知らない。デベロッパーは、自分のコードのコントロールを握っていない”、と彼は語る。

彼のプロダクトはこの問題を、すべてのコードを自動的に分析することによって解決するようだ。そのシステムはライセンス要件を見つけて、問題があれば修復を提供する。追跡のためのツールとしてJiraや、Slackなどを推薦することもある。報告は正しい法律用語で書かれているが、Wangによるとそのためにオープンソースの法務ソフトを利用し、また詳細情報や著作権情報は自動的に生成する。

fossa

写真提供: FOSSA

同社への投資ラウンドをリードしたBain Capital VenturesのマネージングディレクターSalil Deshpandeによると、この分野でエンタープライズ級のソリューションを見たのは、これが初めてだそうだ。“現代のソフトウェア開発のトレンドは、スピードの向上とリスクの増大の両方を抱えている。ライセンス管理の自動化はもはや、あればいいねの段階ではなく、なければ危険の領域だ”、と彼は声明文で述べている。

今やコード中に正しい権利情報が書かれていないと、コードの無断使用で訴えられることすらある。Wangは自分のソリューションが完璧だとは言わないが、開発チームが手作業で正しい完全なコンプライアンスをやるのはほとんど不可能だ、と述べる。一つのソフトウェアが、サードパーティ製のプラグインやライブラリを何百も使っているからだ。“そして結局は、責任を顧客に押し付けることになる。でも私たちは、最小の努力で実現できる、できるかぎりのコンプライアンスを提供していきたい”、とWangは語る。

FOSSAは2014年に創業し、今では10名弱の社員がいる。シード資金は、技術者と営業の増員、そしてマーケティング努力に充てたい、とWangは言っている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Googleが近くGoogle Earth Enterpriseをオープンソース化、ユーザーのクラウドへの移行を誘導

2017-01-31_0935

Google Earth Enterpriseは10年あまり前にローンチし、Google EarthとGoogle Mapsのプライベートバージョンを作りホストして、自前の地理空間的アプリケーションを提供したいと考える企業のツールとして利用されてきた。2015年に同社は、そのサービスを2017年に閉鎖すると発表したが、廃れるプロダクトの通例としてGoogleは今週、Google Earth Enterprise(GEE)の中核的なツールのすべてをオープンソースにする、と発表した

これによりGEE Fusion, Server, そしてPortable Server(全部で47万行のコード)がGitHub上で3月からApache 2のライセンスで利用できる。GEE ClientやGoogle Maps JavaScript API V3、およびGoogle Earth APIはオープンソースにならないが、Enterprise Clientのアップデートは今後も継続する。

screen-shot-2017-01-26-at-2-51-24-pm

Googleとしては、既存のGEEユーザーはGoogle Cloud PlatformとGoogle Earth Engineに移行してもらいたいところだが、近く廃止されてもGEEから離れたくないユーザーもいる。当然ながら同社が今回の発表をしたのも、同社のクラウドベースの地理空間的サービスを宣伝し、この新しいアプローチがパブリックなデータセットへのより柔軟性に富んだ、そしてより容易なアクセスをユーザーに提供する、と言いたいからだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Mozillaがレンダリングエンジンとロゴを一新

2017-01-18_1344

Mozillaは、今年を大きな節目の年にするつもりだ。たとえば、この団体のメインのプロダクトであるFirefoxブラウザーは、レンダリングエンジンを一新する。ここ数年、Firefox OSやHelloの例が示すように、何もかもちぐはぐに見えたMozillaだが、同団体がオープンWebエコシステムの柱であることに変わりはない。しかし2017年が始まるにあたってMozillaは、そのルックスも一新しようとしている。その取り組みは、これまでのブランドイメージからの、思い切った決別だ。あの、元祖Mosaicブラウザーと、世界的な人気キャラ、ゴジラとの合体であるネーミング‘Mozilla’を表す恐竜のロゴも、永遠にさよならだろう。

Mozillaの新しいロゴ’moz://a’は、URLの形をしている。“まるでURLのような新しいロゴは、インターネットがMozillaの中核であることをあらためて強調している。われわれはリンクというものの当初の意図に、あくまでもこだわる。それは、インターネットの豊富なコンテンツへの、途中の選別や加工などのない、自由なアクセスを意味している”、とMozillaは説明している。

  1. mozilla-12jan-1500px_environmental.jpg

  2. mozilla-12jan-1500px_architecture.jpg

  3. mozilla-12jan-1500px_imagery.jpg

  4. johnsonbanks_mozilla_zilla_type_2.jpg

  5. mozilla-12jan-1500px_apps2.jpg

この新しいロゴに使われている“Zilla”フォントは、いかにもMozillaらしく、オープンソースのライセンスで無料で入手できる。これをデザインしたTypothequeは、かつてのWebの暗黒時代に、Webのためのフォントというものを初めてリリースした活字工房だ。

ぼくはマーケターではないので、今のMozillaに本当に新しいブランドイメージが必要なのか、それはわからないけど、でも、Webそのものをストレートに強調し、それが同団体の中核的ミッションであることを表す新しいロゴは、それまでのゴジラの頭よりは良いと思う。ここ数年Mozillaは、モバイルOSやIoTにまで色気を示したりして、自分を見失っているのではないかと危惧された。しかしMozillaは、非営利団体として、Webの同業者たちに、誠実でオープンという姿勢の見本を示している。昔ほど大きなマーケットシェアを持っていないFirefoxも、依然としてオープンWebエコシステムの心臓部であり続けている。今年もその点だけは、変わらないでほしい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

KickstarterがそのAndroid/iPhoneアプリのコードをオープンソース化…公益法人化を契機に

img_1096

クラウドファンディングのトップサイトKickstarterが、そのアプリケーション開発過程を開示しようとしている。今朝(米国時間12/14)同社は、その技術系のブログ上で、AndroidとiOSのネイティブアプリのコードをオープンソースにし、同社の目標であるスタートアップ支援の一環とする、と発表した。

同社によると、この考えがひらめいたのは、昨年の9月に同社が公益法人になったことが契機で、広い意味でのデベロッパーコミュニティに何かを還元していくという、企業としての大きな社会的視野を持つべき、と考えた。

コードは今日から、同社のGitHubレポジトリで提供され、アプリのエンジニアリングとデザイン両面の、内部的仕組みや構造に、それらに関心のある人たちがアクセスできるようにする。

今日のローンチに先駆けてKickstarterのエンジニアBrandon Williamsは本誌にこう語った: “チームとしてのわれわれは、かなりユニークな仕事をしている、とかねてから感じていた。でも、エンジニアが自分の仕事を互いに共有できる機会は、そうめったにあるものではないからね”。

オープンソース化してとくに有益と考えられるのは、Kicstarterのアプリが、関数型プログラミングの手法で書かれていることだ。その開発過程やプロトタイピングの過程が目で見て分かることは、かなり参考になるだろう。

とくに同社は、次のような点を強調している:

  • Screenshotsディレクトリには500近いスクリーンショットがあって、すべての言語やデバイス、つねに真であってほしいエッジケース状態などのさまざまな画面を収めている。たとえば、Kickstarter上で支援者がフランス語のプロジェクトを見ていたり、クリエイターがドイツ語のダッシュボードやiPadのページを見たりしている。
  • われわれはSwift Playgrounds〔参考記事〕を使って反復型(iterative)開発とスタイリングを行っている。アプリケーションの主な画面の多くに、それに対応するプレイグラウンドがあって、そこで多様なデバイスや言語やリアルタイムのデータを見られる。われわれのプレイグラウンドのコレクションを、ここで閲覧できる。われわれはビューモデルを、副作用を隔離し、 アプリの中核的部分に取り組んでいくための、軽便な方法として使っている。
  • われわれはこれらを、入力信号を出力信号に純粋にマッピングするためのものとして書いている。テストは、ローカライゼーションのテスト、アクセシビリティのテスト、イベント追跡のテストなど、いずれもしっかりと行っている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Kubernetesによるコンテナ管理をステートフルなアプリケーションにまで広げるCoreOSのOperatorデザインパターン…最初の2つの実装をオープンソース化

Old Cord Switchboard Operator

CoreOSが今日(米国時間11/3)、コンテナ管理の新しいコンセプトOperatorsを発表した。同社によるとそれは、コンテナの管理をより一層自動化することによって、Kubernetesを使用するプロジェクトの進捗を早める。しかも同社は、この技術をオープンソースにする。

CoreOSのCTO Brandon Philipsはこう説明する: “Operators(オペレーター)はその名のとおり、システムのオペレーション(運用)の部分を担当し、自動化する。具体的にはそれは、エンジニアやデベロッパーがスクリプトやランブック(run book, 操作指示書)の中に書く大量の知識、とくにドメイン固有の知識を、自動化するソフトウェアだ”。

Googleのオープンソースのコンテナ管理プロジェクトKubernetesは、広く使われている。小さなマイクロサービスをコンテナに収めることによって、デベロッパーは複雑なアプリケーションを独立した部品に分割し、これまでのプログラミングデリバリ技術に比べてはるかに効率的に動かすことができる。

CoreOSがOperatorsでやろうとしているのは、生半可なことではない。従来の作業では、一連の複雑なタスクを取り上げて、それらをユーザーのプロジェクトのホワイトボードビュー(構造図・流れ図)にまとめる。そのプロジェクトが、3つのサーバーから成るクラスターを必要とするとしよう。すると各サーバーのIPアドレスを知り、構成ファイルを作り、それを3つのマシンにコピーする。以上は多くのデベロッパーがかなりの時間を投ずる作業であり、プランが変わったときには手作業で調整しなければならない。Operatorsを使うと、デベロッパーはこれらの手作業のすべてを、一つの宣言文: “Launch three clusters”(3つのクラスターをローンチせよ)に要約できる。あとはいっさい、 Operatorがやってくれる。

データベースやモニタリングツールなどの複雑なアプリケーションでは,このことがとくに重要だ。Philipsの説明によると、Kubernetesは、単純でステートレスなアプリケーションのスケーリングは得意だが、もっと複雑なステートフルなアプリケーションでは、大量のスクリプトを人間が書かなければならない。Operatorsは、そのたいへんな作業をなくすことが目的だ。

たしかに、昨年本誌TechCrunchのCrunchNetworkでゲスト記事I want to run stateful containers too(ステートフルなコンテナも動かしたいね)を書いたDean Peterson(abecornの協同ファウンダーでミネソタ州雇用経済開発部のソリューションアーキテクト)も、こんな嘆きを述べている:

今のぼくの考えでは、MongoDBのようなステートフルなアプリケーションも、ステートレスなクライアントやサービスと一緒にコンテナで動くべきだ。そう言うぼくは、馬鹿かもしれないが、でもコンテナの価値はアプリケーション全体を容易にスケールできることにある、と思う。

今日の発表で、Petersonの素朴な夢が実現への一歩を踏み出した。それには、二つのOperatorsのオープンソース化が含まれる。最初のetcd Operatorは、etcdのクラスターを管理し分散化する。etcdはKubernetesのためのキー-ヴァリューストアで、CoreOSが作った。もうひとつのPrometheus Operatorは、オープンソースのモニタリングツールPrometheusで使って、Kubernetesのリソースをモニタする。

Philipsによると、この二つのローンチがきっかけとなって、コミュニティによるそのほかのOperatorsの開発が盛んになることを期待したい。この二つを実際に使ってみたら、誰もがその気になるだろう、と彼は言う。

“Operatorの基礎部分の多くは、Kubernetesのコミュニティが作った。彼らとうちとの、初めての協働で、ドメイン固有の知識をKubernetesの上で管理するやり方が、だんだん分かってきたんだ。これをいわばパターン(‘デザインパターン’)として、この便利な仕組みをもっと広げてほしい”、と彼は語る。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Googleがドメインの登録に使っているNomulusをオープンソース化して一般公開へ

DUBLIN, IRELAND - APRIL 19:  (FRANCE OUT) A general view the Google European headquarters, on April 19, 2016 in Dublin, Ireland.  (Photo by Vincent Isore/IP3/Getty Images)

Googleが今日、Nomulusリリースした。このJavaで書かれたクラウドサービスは、ユーザーに代わってトップレベルドメインの登録や管理を行う。Google自身も、.googleや.fooなどのTLDをこれで管理している。

Googleによると、同社がNomulusの開発に着手したのは、2012年に同社が数多くのジェネリックなTLDsの申請や運用を開始したときだ。それまでは、ドメインネームはもっぱら.comと.netや、国別を表す.deや.ukなどに限られていた。しかしICANN(Internet Corporation for Assigned Names and Numbers)が.app, .blog, .guruなどのいわゆるジェネリックなTLD(generic TLDs)を認めて以来、Googleは.googleをはじめ数多くのTLDを申請してきた。

Googleは、ドメインの登録データのすべてをNomulusのプラットホーム上で管理している(たとえばblog.google)。またこのプラットホームは、ドメインの購入や変更、移送などの事務も行う。GoDaddyなどのドメインサービスを利用してドメインネームを買っておられる方も多いと思われるが、その場合はそのサービスが、Nomulusのやることを人力でやっているのだ。

NomulusはApache 2.0のライセンスでオープンソースになっているが、同時にこれはGoogle Cloud Platformのれっきとした一員でもある。それはApp Engineでも使われ、またバックエンドのデータベースとしてはGoogle Cloud Datastoreを使っている。

Googleによると、Nomulusは、300あまりのジェネリックTLDを保有しているDonutsのコードも利用しており、近く一般公開バージョンのテストバージョンの提供を開始する。

〔参考ドキュメント: NomulusのGitHubページより:〕

Overview

Nomulus is an open source, scalable, cloud-based service for operating top-level domains (TLDs). It is the authoritative source for the TLDs that it runs, meaning that it is responsible for tracking domain name ownership and handling registrations, renewals, availability checks, and WHOIS requests. End-user registrants (i.e. people or companies that want to register a domain name) use an intermediate domain name registrar acting on their behalf to interact with the registry.

Nomulus runs on Google App Engine and is written primarily in Java. It is the software that Google Registry uses to operate TLDs such as .GOOGLE, .HOW, .SOY, and .みんな. It can run any number of TLDs in a single shared registry system using horizontal scaling. Its source code is publicly available in this repository under the Apache 2.0 free and open source license.

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

OpenStackが14回目のバージョンアップ、スケーラビリティと自己回復力、ベアメタル上のコンテナに注力

openstack_planet-1-of-1

OpenStackは、企業がこれを使って自分のデータセンターにAWSのようなクラウドプラットホームを構築運用できる大規模なオープンソースプロジェクトだ。それが今日(米国時間10/6)、その14度目のメジャーバージョンアップをリリースしたNewtonと呼ばれるニューバージョンは、ここ数年間における、OpenStackのさらなる成熟を示している。そして今回は、OpenStackのコア的サービスの一部の、スケーラビリティと自己回復力の強化に力が入れられている。またそれと同時に、重要な新しい機能が二つ加わった。そのひとつは、コンテナとベアメタルサーバーのサポートの改良だ。

Newtonに寄与貢献したデベロッパーとユーザーは2500名あまりに達する。その数からもそれがビッグプロジェクトであることが分かるが、コンピュート、ストレージ、ネットワーキングといったデータセンターの中核的サービスをサポートするだけでなく、多様な小規模サービスも各種提供している。

OpenStack FoundationのCOO Mark Collierによると、Newtonの力点は新しい機能よりもむしろ、新しい種類のワークロードをサポートするためのツールの充実に置かれている。

CollierとOpenStack Foundationの上級役員Jonathan Bryceが強調するのは、OpenStackの仕事はあくまでも、ユーザーが自分のワークロードを動かすために必要とするインフラストラクチャを提供することだ、という点だ。ワークロードの種類やタイプ、そのために求められるツールは、いっさい特定しない。“クラウドと仮想マシンが同一視されることは、最近ではなくなった”、とCollierは述べる。むしろ今多いのは、ベアメタルとコンテナの併用だ。OpenStackはそんなユーザーに、すべてを一元管理できるための、単一の制御インタフェイスを提供しなければならない。

しかし企業の変革の歩みは遅くて、OpenStackを使っているアーリーアダプター的企業でさえ、コンテナの採用はまだ始まったばかりだ。Bryceは曰く、“アーリーアダプターの中には、すでにコンテナをプロダクションで(本番運用で)使っているところもある。しかし私の考えでは、OpenStackである・なしを問わず、コンテナをプロダクションで使うのは時期尚早だ”。しかしそれでも、彼によると、最近ではOpenStackのさまざまなコンポーネントを活用して、コンテナの採用を早めたい、というユーザーが増えている。

networktopology

OpenStackのコア・フィーチャーであるNovaコンピュートサービスや、Horizonダッシュボード、Swiftオブジェクト/blobストアなどは、今回のアップデートでスケーラビリティが向上した。OpenStack上のコンテナ管理プロジェクトMagumuは、すでにDocker Swarm, Kubernetes, およびMesosをサポートし、オペレーターがKubernetesのクラスターをベアメタルサーバーの上で動かすこともできる。またそういうベアメタルサーバーのプロビジョニングフレームワークIronicは、Magnumとよりタイトに統合化され、マルチテナントのネットワーキングもサポートする。

今回のリリースには、そういった多様なアップデートや改善改良が含まれる。その圧倒的な全容と各プロジェクトの詳細は、ここで見られる。

OpenStackはすでに、6か月先の次のリリースにも取り組んでいる。それは、今月後半にバルセロナで行われるOpenStack Summitまでには準備段階を終えて、来年2月に一般公開されるだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Facebookの人工知能研究所がオープンソースで公開したfastTextは深層学習の遅さを克服したテキスト分類ソフトウェア

facebook-search

Facebookでは毎日、何十億ものコンテンツがシェアされている。その膨大な量とペースに漏れなく遅れなく対応できるためにFacebookは、さまざまなツールを駆使してテキストを分類している。多層ニューラルネットワークのような従来的な方法は正確だが、ニューラルネットワークは訓練が大変である。

分類に正確さと容易さの両方をもたらすために、Facebookの研究部門Artificial Intelligence Research(FAIR)ラボはfastTextというものを開発した。そして今日(米国時間8/18)はそのfastTextがオープンソース化され、デベロッパーはどこででも、そのライブラリを使ったシステムを実装できることになった。

fastTextはテキストの分類と、語のベクタ表現の学習の両方をサポートしている。後者には、bag of wordssubword information(部分語情報)*などのテクニックが用いられる。skip-gramモデルに基づいて語は文字のn-gramのバッグとして表現され、それらは各文字のn-gramを表すベクタで表現される。〔*: 部分語情報、‘あかい’なら、あ、か、い、あか、かい、などが部分語。〕

“カテゴリー数のとても多いデータベース上で効率的であるために、fastTextは階層的な分類を用いる。そこではさまざまなカテゴリーがフラットなリストではなく二分木構造に編成される”、FacebookのArmand Joulin, Edouard Grave, Piotr Bojanowski, Tomas Mikolovらがドキュメンテーションでそう述べている。

bag of wordsのbag(バッグ)は、配列やリストや木(ツリー)などなどと並ぶコンピューター上の一般的なデータ構造の一種で、名前(“袋”)の名のとおり、データに順序性がなく、この場合は各語の出現頻度を各語が情報として持つ。“語(words)”は多次元空間として表現され、クェリとカテゴリー分けされた語の集合との関係を線形代数を使って計算する。コンピューターにテキストを投じたとき、それはゼロからのスタートになる。それに対して人間の大人はすでに文法知識を持ち、どこが語の始まりで終わりかを知っている。コンピューターの計算力は強力だが、そのままでは“I love TechCrunch”と“CrunchLove iTech”の違いを認識できない。そこでこのような方法では、ことばに対する定性的な分析を、統計的手法などにより、定量的な分析へと強制的に変換する。

そして数を操作する処理が主体なので、fastTextは従来の深層学習の方法(多層ニューラルネットワーク)よりも速い。下図は、Facebookが作った比較表だ。実行時間が「秒」の単位なのは、fastTextだけである:

fastTest

fastTextは英語だけでなくドイツ語やスペイン語、フランス語、チェコ語などに対しても使える。

今月の初めにFacebookは、クリックベイトをやっつけるアルゴリズムを同社のNewsfeedに実装した。そのアルゴリズムは言葉以外の要素(繰り返しパターンなど)も点検するから相当複雑だが、デベロッパーはfastTextを利用して同様のツールを自作できる。

Facebookによると、fastTextなら、“ふつうのマルチコアのCPUを使って、10億語を10分弱で学習できる。また、50万のセンテンスを30万あまりのカテゴリーに5分弱で分類できる”、という。これはすごい、かもしれない。

今日(米国時間8/18)からFacebookのfastTextは、GitHub上で入手できる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

MicrosoftがPowerShellをオープンソース化しLinuxやOS Xにも提供…Bash on Windowsとの差別化は?

microsoft-data

Microsoftが今日(米国時間8/18)、同社のPowerShellをオープンソース化し、LinuxやOS Xでも使えるようにする、と発表した。

PowerShellは、WindowsのパワーユーザーのためのMicrosoft製のコマンドラインシェルで、タスクを自動化するための拡張可能なスクリプト言語(シェル言語)のインタープリタでもある。シェルとしてはLinux上のBashとあまり変わらないが、Windowsという固有のシステムに深入りしている部分もある。なおBashは今や、Windows上にもある。Microsoftは今変わりつつあり、CEOのSatya Nadellaが折りにふれて繰り返すのは、今の同社が“マルチプラットホーム、マルチクラウド、そしてマルチOS対応”であることだ。今の同社では、数年前にはあり得なかったようなことがふつうに行われている。Windows 10の中にLinuxのサブシステムを作り、その中核的ツールの一部をオープンソース化する。そんなことが、今や日常茶飯事だ。

11524380

Microsoftのテクニカルフェローで同社のEnterprise Cloudグループの主席アーキテクトであるJeffrey Snoverによると、Nadellaが全社的に訴えたいのは、顧客とのコミュニケーションを充実し、顧客が求めているものの実現を、売上と利益の源泉にしていくことだ。“顧客はサーバーもクライアントもクラウドも自分で選びたい、自分で決めたいと思っている。そんな顧客の親身なパートナーになってあげることがMicrosoftと顧客の共通の利益であるべきだ”、と彼はNadellaの主張を要約する。今のそんなMicrosoftがPowerShellの対応の幅を広げることは、顧客が、“どんなクライアントを選んでも…それがWindowsであってもOS XであってもLinuxであっても…単一の管理スタックを使える”ことに通ずる。まさに、Nadellaが主張するマルチOS対応だ。

Microsoftは今日の発表に先駆けて.NETフレームワークをオープンソース化し、.NET CoreをLinuxとOS Xでも可利用にした。PowerShellは.NETベースのツールなので、それが今回Linux/OS X対応になるのは自然な流れだ。

PowerShellを強力にしているのは、シェル本体だけではない。マルチOS化の一環としてPowerShell Editor Serviceが提供されるので、デベロッパーはシェルの機能をテキストエディターの中から利用できる。またVisual Studio Codeもサポートされ、そしてSublime(TypeScriptプラグイン)はすでに可利用だ。

PowerShellは拡張性が高いので、VMwareや、クラウドではライバルのAWSといったパートナーたちですら、PowerShell用のcmdlet(s)というものを作り、シェルやスクリプトから、たとえばAWSの場合は、EC2のインスタンスを直接管理できるようにしている。

PowerShellはMicrosoftのOperations Management Suite(OMS)を統合しているので、Azure, AWS, GoogleのCloud Platform、あるいはオンプレミスのデータセンターなど、アプリケーションやワークロードがどんなプラットホーム上にあっても、それらを管理できる。

Windows上にBashがあることと、LinuxやOS Xの上でPowerShellが使えることの違いについてSnoverは、前者(Bash on Windows)は、オープンソースのデベロッパーがWindows上で仕事ができるための措置だ、と言う。

Snoverも認めるように、オープンソースプロジェクトの管理についてMicrosoftはまだ‘学習中’だが、彼のチームはすでに、パートナーたちとその件で多くの会話を重ねている。今後はコミュニティを適正に統治することにより、コードの変更がコミュニティから得られるようにしたい、ともいう。もちろんPowerShellのコードも、その対象に含まれる。

Ubuntu, CentOS, Red HatなどのLinuxユーザーとOS Xのユーザーは、PowerShellを動かすために必要なものを、GitHubのPowerShellリポジトリからダウンロードできる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))