Facebook、JavaScriptの新パッケージマネージャ、Yarnをリリース―Google他が協力

OAKLAND, CA - NOVEMBER 30:  A FedEx worker sorts packages being uloaded from a truck on a conveyor belt at the FedEx Oakland Airport sort facility November 30, 2005 in Oakland, California. FedEx and UPS are beginning to feel large volumes of packages as the holiday shipping season gets underway with a high level of online shopping.  (Photo by Justin Sullivan/Getty Images)

今日(米国時間10/11)、FacebookはJavaScriptの新しいパッケージマネージャーYarnをローンチした。読者が日頃JavaScriptとNode.jsを使っているなら、 既存のコードを探して再利用する(あるいは自分で開発したライブラリを公開する)ためにnpmパッケージマネージャを利用している可能性が高い。

しかしnpmはFacebookのような巨大な規模の企業の業務を処理するには能力が足りなかった。そこでFacebookは社内のデベロッパーの意見に従って独自のパッケージマネージャを部内用に開発した。その後開発チームはGoogle、Exponent、Tildeなどの外部のエンジニアの協力も得るようになった。

こうして開発されたのがYarnだが、特に重要なポイントは以下の点だ。つまりYarnはFacebookのような巨大企業以外のデベロッパーにも画期的な効率アップを約束するものの、あくまでnpmレジストリを利用しているユーザーが対象であり、npmクライアントをドロップインで代替するプロダクトだという点だ。

Facebookのソフトウェア・エンジニアのSebastian McKenzie、エンジニアリング担当マネージャーのTom Occhinoが私に語ったところによれば、Facebookは社内でnpmを中心として多くのインフラを構築してきたという。McKenzieによれば、「しかし時間が経つうちに、npmに新しい機能やツールを次々に付け加えていくやり方ではうまくいかなくなってきた。そこでnpmの能力の限界をハッキングして拡張しようとする代わりに、Facebookは新しいパッケージマネージャをゼロから作ろうと決めた」という。

数百万人のデベロッパーのところでnpmが役に立っているのに、なぜFacebookでは問題が起きたのだろうか?  Facebookの開発チームの話によれば、同社のワークフローに適合しない根本的な問題がいくつかあったのだという。ひとつはパフォーマンスが低すぎたことで、Yarnはローカルに保存されたファイルを得るのが効率化されている。つまりネットワークへのアクセス回数を従来よりずっと減らし、負荷をかけずにすむようになった。Yarnはまたいくつかの作業を平行化することができ、新しいモジュールのインストールが高速になった。

Facebookのワークフローでは常時新しいモジュールが統合されている。npmはこのプロセスのネックとなり、スピードをダウンさせていた。当初、Facebookのエンジニアはマニュアルでnpm installコマンドを入力していたが、これはサンドボックスやセキュリティーや信頼性への配慮からネットワークから孤立した環境でのモジュール統合では作動しなかった。レポジトリにあるすべてのモジュールをチェックする仕組みも、どんなわずかな変更でも巨大なコミットを引き起こすことになったので非効率だった。たとえばReact Nativeモジュールには68の依存関係があり、依存先もまた独自に依存関係があり、合計すると12万1358個のファイルになる。これらをすべて引き出してくるのは効率的とはいえない。

Facebookが直面したもうひとつの問題は、npmは本質的にノン・デターミニスティック(非決定性)のデザインだという点だった。FacebookのエンジニアはDevOpsのワークフローで一貫性と信頼性のあるシステムを必要としている。npmの場合、すでにインストールされたモジュールとの依存関係によって、あらゆるプロジェクトに存在するにもかかわらず、node_modulesのディレクトリはマシンごとに全く違った見え方となる。Yarnではロックファイルとデターミニスティックなインストール・アルゴリズムを用いることにより、すべてのマシンを通じて統一的なファイルを構造を得ることができるという。

またnpmはデフォールトでデベロッパーがインストールの過程で必要になれば他の場所にあるコードを参照して実行できるようパッケージを書くことができる。これはセキュリティー上の問題を引き起こす原因になるため、Yarnではこの機能は削除された。

McKenzieが私に話したところによると、開発チームは当初npmのこうした問題の「修正」を試みたという。だが努力を重ねるうちに、既存のnpmクライアントの機能にFacebookのワークフローで作動しないものが多数あるのはバグではなく、そういう仕様であることが分かってきた。Occhinoは「それにFacebookが必要とする機能の多くはnpmのコミュニティーに受け入れられない可能性があった」と付け加えた。

npmプロジェクトを支える商業組織であるNpmはもちろんFacebookが新しいパッケージマネージャを開発中であることを知っていた。しかしNpmのビジネスモデルはクライアントよりレジストリを中心としており、一般に想像されるよりも相互の競合ははるかに少なかったという。

YarnはすでにGitHubから利用可能だ。Facebook以外の多くの企業が協力したことをふまえ、開発チームはFacebook独自のレポジトリを利用することを避けた。ただしYarnの今後の管理体制がどのようなものになるのかについてはまだ不明な点が多い。「これまで開発に協力してくれた企業が引き続き将来の管理についても助けてくれるというのがわれわれの希望だ」とOcchinoは述べた。

画像: Justin Sullivan/Getty Images

[原文へ]

(翻訳:滑川海彦@Facebook Google+

JoyentがDockerの展開と管理を容易化する多様な複合的コンテナインフラストラクチャサービスTritonをローンチ

コンテナに特化したPaaS/IaaS Joyentが今日(米国時間3/25)、Dockerアプリケーションの展開を容易にするコンテナインフラストラクチャTritonのローンチを発表した。それはオンプレミスのクラウドや、Joyent自身のパブリッククラウド上で利用できる。ほぼ1年半前に同社が、それまでの1億2000万ドルの資金調達に加えて新たに、1500万ドルの資金調達を発表したとき、まさにこの種のサービスのリリースを目標として掲げていた。

Joyentの主張によると、Dockerは開発と展開を大幅に効率化するが、同時に、複数のコンテナやホストの管理、ネットワーキングの実装への対応、セキュリティといった複雑な問題ももたらす。

Tritonは複数のコンポーネントで構成され、その中にはJoyentの既存のプロダクトも含まれる。サービスの中心にあるのはDockerのコンテナで、それらはTriton Docker Engineが管理し、Triton Container Hypervisorの上で動く。Tritonには独自のSDN(software-defined networking)インフラストラクチャサービスと、そのサービスを管理するためのDevOps Portalがある。

下図は、オープンソースのツールも含むJoyentの提供物全体の中での、Tritonの位置づけだ。

Joyentによると、Tritonでデベロッパとdevopsのチームがデータセンターの全体を単一のホストのように扱えるようになり、コンテナにまつわる複雑性はバックグラウンドで管理される。それと同時に、仮想化レイヤSmartOSにより、Dockerコンテナにベアメタルなパフォーマンスがもたらされる。またTritonにはリアルタイムモニタリング機能とポストモーテム(post-mortem, クラッシュ直後, 検死)デバッギング機能、およびコンテナを容易にサイズ変更したりスケールする機能もある。

Joyentが他の類似サービスと異なるのは、課金が仮想マシン単位ではなくコンテナ単位で行われることだ。今回のローンチの一環として同社は、これまでのローエンドマシンよりもさらに低料金の新しいインスタンスを導入する。

JoyentのプロダクトマネージャCasey Bissonに、同社のサービスと、GoogleのKubernetesなど既存のDocker管理ツールとの相性について尋ねると、彼はこう答えた: “Joyentではコンテナをマルチテナントのベアメタル上でセキュアに動かせるため、そのパフォーマンスと料金面のアドバンテージは他と比べて別格である。ネットワークの仮想化も同様の利便性とパフォーマンスのアドバンテージを提供するが、これもまた、他の類似サービスの追随を許さないものである”。

SmartOSについては、“これらのアドバンテージを提供する弊社の能力の核心であるが、これらのアドバンテージが実際に現れるDockerコンテナのホスティングは、他に見られない新しい技術と重要なイノベーションの数々を体現している”、ということだ。

Tritonは今、Joyentのパブリッククラウドの顧客にプレビューとして提供されている。オンプレミスでこのサービスを動かしたい企業は、自分のデータセンターでTriton Enterpriseをデプロイできる。

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


Joyentがクラウドプラットホーム上のエンタプライズ級のDockerサポートのために$15Mを調達

今日まで、クラウドインフラ企業Joyentは、複数回の資金調達ラウンドにより合計1億2000万ドルを調達してきた。いちばん最近のシリーズD、2012年の8500万ドルが、額としては最大である。シリーズDまで行く企業はそんなに多くないが、しかしクラウドプラットホームプロバイダJoyentは今日、既存の投資家Intel Capital、Orascom TMT Investments、El Dorado Ventures、EPIC Ventures、LGI Venturesなどなどから、さらに1500万ドル(シリーズE)を調達したことを発表した。

Joyentの計画では、この資金は、Dockerとコンテナベースのインフラストラクチャという
最近のトレンドを、同社の機会として生かすために使われる。Joyentはプラットホームとしてのコンテナを10年あまり前から提供しているが、Dockerがクラウドインフラストラクチャの寵児としてもてはやされるようになるまでは、コンテナという技術の知名度はきわめて低かった。

JoyentのCEO Scott Hammondは今日の声明文の中で、次のように述べている: “弊社の顧客は今、我先にとDockerを採用してアプリケーションコンテナを作っている。そして彼らは、この新しい技術をJoyentの、すでに実証済みのインフラストラクチャコンテナの上で使いたいと願っている。アプリケーションコンテナとインフラストラクチャコンテナを組み合わせるという、この特別な技術により、データセンターが完全にディスラプトされ、ビジネスアプリケーションの作られ方と配布のされ方が変わる、とわれわれは信じている”。

Hammondは本誌のメールインタビューで、“市場もやっとコンテナの利点に注目するようになった”、と言っている。しかし彼はまた、今の企業はDockerと競合するようなコンテナ技術には関心がない、とも言う。“そこでうちは、これまでの経験を生かしてJoyentをDockerのコンテナを動かすための最良の場所にしたい”、と彼は語っている。

JoyentはSmartOSと呼ばれる独自のオペレーティングシステム仮想化層を使っている(OpenSolarisとLinuxの仮想化技術KVMを組み合わせたもの)。Hammondによると、この方式ではDockerのコンテナがベアメタルで動くため、“アプリケーションコンテナのためのランタイム環境として最良であり、弊社は、これらのコンテナを、エンタプライズ級のネットワーキングによりベアメタルのスピードでセキュアに動かすためにデータセンターの運用者が必要とする機能を提供する。また弊社のOS仮想化技術は高密度のワークロードを可能にする”。

Joyentは今後も、同社のコアビジネスであるパブリッククラウドプラットホームの提供を続けるが、それに加えて、ベアメタル上のコンテナを管理する必要のあるdevsやopsたち向けに新たなプロダクトやサービスを作っていく。それについてHammondは詳細を語らないが、要は、“Dockerをサポートし統合するためのプロダクトとサービスを開発していく”、ということだ。

ではなぜ、同社は、今というタイミングで増資を必要としたのか? “すべてはスピードのためだよ”、とHammondは言う。“これから技術のシフトが猛スピードで始まろうとしている”。VMWareがデベロッパのテスト環境からメジャーな普及に至るまで数年を要したが、今日の技術はもっと速いスピードで大量普及に到達するだろう。“今回のラウンドで開発をスピードアップし、ディスラプティブな技術の次の大きな波を、それに呑まれるのではなく、それを率先して動かしていく企業になりたい”。

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


Amazon Web Services(AWS)がNode.jsによるSDK/オブジェクトライブラリを提供

Node.jsは今や、アプリケーションを開発するとき誰もが使っている。それはサーバサイドのJavaScriptだ。比較的おぼえやすいので、とても人気がある。今回はAmazon Web Services(AWS)が、Node.jsによるSDKをリリースし一般公開した。

あるブログ記事によると、AWSは12月のプレビューリリース以降、さらに機能を増強した。新しい機能は、バウンドパラメータ、ストリーム、EC2インスタンスのIAM roles、バージョンロッキング、プロキシなどだ。AWSによると、このSDKはAWSのサービス(Amazon S3, Amazon EC2, DynamoDB, Amazon SWF)のJavaScriptオブジェクトを提供して、デベロッパのコーディングを単純化することが目的だ。

Node.jsはその、イベント駆動型のノンブロッキングI/Oにより、アプリケーションのスケーラビリティを支え、しかも、スレッドやタイムアウトのポーリング、イベントループなどをプログラマは扱わずにすむ。だからこそ、大きな人気を獲得した。とくにゲームデベロッパに愛好者が多く、AmazonのCTO Wener Vogelsは、3月にAWSがElastic BeanstalkでNode.jsを提供したときに書いた記事の中で、そのことを説明している。Vogelsによると、Elastic BeanstalkはElastic Load Balancing、Auto Scaling、EC2などのAWSリソースのプロビジョニングとモニタリングと構成を自動化する”。彼によると、デベロッパたちはNode.jsの機能を利用することによって、レイテンシ(ネットワーキング待ち時間)の低い複数の並列的接続を実現している。UberやVoxer、それにDataheroのようなエンタプライズ向けスタートアップはすべて、サーバの実装にNode.jsを使っている。

Node.jsのサポートを提供しているクラウドプロバイダはAWSだけではない。Joyentはこのプラットホームを企業向けサービスの一環として提供している。Windows Azureもビッグなサポーターだ。Rackspaceもサポートしている。3月にMicrosoftは、Windows Azure Service Busを使うオープンソースの寄与貢献物を提供した。それは、Node.jsによるリアルタイムアプリケーションのためのスケールアウトをサポートするライブラリだ。

AWSが今回Node.jsによるSDKを一般公開したことは、デベロッパ界隈における、Node.jsというプラットホームの実力を物語るエピソードの一つだ。つまり、デベロッパを相手にするビジネスでは、もはやNode.jsを無視できない。これで、AWSをベースに開発〜プログラミングをするデベロッパが今後増えることは、ほぼ確実だ。

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