米国土安全保障省が脆弱システムの利用者開示をISPに義務づけへ、法改正を準備中

TechCrunchの情報源によれば、米国の国土安全保障省(DHS)はインターネットプロバイダー(ISP)に対して脆弱性あるシステムの利用者が誰であるか明かすよう義務付けることができるようにする法改正を準備中だという。

昨年11月に議会は満場一致でCISA法を成立させた。これにより国土安全保障省内に、CISA(サイバーセキュリティおよびインフラストラクチャ庁)を設置。CISAはISPおよび重要なインフラストラクチャを運営する企業に関する電子的セキュリティの維持、向上を図ることが目的であり、脆弱性あるシステムのユーザーの身元を含め、脆弱性情報を合法的に取得できる権限が与えられた。

この権限に基づき、システムに脆弱性がある場合、CISAは政府機関、民間企業の双方に対して警告を発してきた。一方で、脆弱性あるシステムを利用しているユーザー企業に対し直接その危険性を通知できない場合が多いことに対して密かに不満を訴えていた。これは脆弱性あるシステムを誰が使っているか明らかでない場合が多いためだった。

CISAが準備している改正案は、CISA法に盛り込まれた権限を生かし、脆弱性あるシステムを利用しているインフラ運営者に対して直接に危険性を通知できるようにするものだという。ハッカーは発電所、電力グリッド、水道、石油コンビナートなどのインフラ産業のシステムをターゲットにしつつある。こうしたインフラ企業のシステムはますます複雑化しており、被害が及ぶ範囲もますます拡大している。

法の定めるところによれば一部の連邦機関は、裁判所に図ることなく召喚状などの強制力ある手続きによって、ISPから利用者に関するデータを得ることができる。ところがCISAはこの強制力を欠いているため、現在は他の連邦捜査機関に依頼して脆弱性あるシステムのユーザーを特定している。さらに捜査機関が召喚状を発することができるのは現に行っている捜査に関連した場合に限られる。そのため、CISAは特定の犯罪を捜査していない場合でも脆弱性あるシステムのユーザーを特定し警告する合法的な権限を得たいとしている。

CISAの法改正の動きは、連邦政府は民間セクターのインターネットの安全性にどこまで関与すべきなのかという以前からある議論にまた直面することになるだろう。連邦政府は独自のイニシアチブで民間企業に対して安全性の警告ができるのかという問題だ。

企業にインターネットの安全情報や防衛研修を提供するRendition Infosecの創業者で元NSAの専門家であるJake Williams(ジェイク・ウィリアム)氏はCISAの動きを「権限強化が狙いだ」とし、不適切に利用される危険性があると主張する。ウィリアム氏はTechCrunchに対して「これは議会がCISA設置法を通過させたときに想定していた権限ではない」と述べた。

ただし、CISAが求めている行政機関が召喚状を発する権限はさほど異例なものではない。米国では多くの省庁部局が民間企業に情報提供を義務付ける権限を持っている。もちろんこうした権限には行政機関に司法の審査、監督なしに大量の情報を収集を許すものだという批判が出ている。

FBIはこの種の安全保障を理由とする行政命令(NSL、National security letter)発行権限を有しており、電話会社や大手テクノロジー企業から密かに加入者データを得ている。電子フロンティア財団はNSLを合法だとした連邦地裁の決定に不満を表明している。

TechchCrunchに背景を説明したCISA担当者は、この改正案はすでに議会の送付済みであり、「インフラ企業は政府担当部局から直接警告を受けた場合、(脆弱性対策に)より積極的になるはずだ」と述べた。担当者によれば「CISAは不当、不正な権限の利用が起きないよう(予防措置を盛り込むために)議員と密接に協力している」という。

国土安全保障省事案を監督する下院委員会の広報担当者、Adam Comis(アダム・コミス)氏コメントを求めたがまだ回答がない。

【Japan編集部追記】subpoena(サピーナ)は暫定的に「召喚状」としたが、英米法の手続きで「人に証言を義務付ける命令」と「人または組織に物理的証拠の持参を義務付ける命令」の2種類がある。正確にいえば証言を求めるのは前者であり、記事中のsubpoenaはISPに対してユーザーの身元情報を明かすよう義務付ける命令であるため後者となる。ただし後者に定訳はない。subpenaはラテン語で「制裁の下に」の意味で、従わない場合は法廷侮辱罪などの罪となる可能性がある。

原文へ

(翻訳:滑川海彦@Facebook

使い慣れたプログラミング言語を使ってクラウドのインフラストラクチャを管理できるPulumiが商用バージョンを開始

シアトルのPulumiを使ってデベロッパーは、自分が知っているプログラミング言語を使ってクラウドインフラストラクチャを指定しそれを管理できる。同社は今日(米国時間10/22)、Madrona Venture GroupがリードするシリーズAのラウンドで1500万ドルを調達したことを発表した。Tola Capitalがこのラウンドに参加し、同社のマネージングディレクターSheila GulatiがPulumiの取締役会に加わる。Madronaからはすでに、元Microsoftの役員でMadronaのマネージングディレクターS. SomasegarがPulumiの取締役会に加わっている。

資金調達の発表に加えてPulumiは今日、その商用プラットホームをローンチした。それは、同社のオープンソース製品をベースとするものだ。

Pulumiの協同ファウンダーでCEOのEric Rudderはこう語る: “これまでは企業とコミュニティの両方からの関心がどちらも大きくて、彼らから大量のオープンソースのコントリビューションが寄せられている。たとえばVMwareとOpenStackのサポートは、コミュニティの尽力によるものだ。だからうちでは、オープンソースのコミュニティの活力が大きいが、それと同時に、商用化への関心も大きかった。つまり企業のチームはPulumiの運用面の充実を求めており、それを彼らのプロダクションに入れることと、プロダクトとして購入できることを要望していた”。

そこで、その機会に応えるべく同社は、チームとプロダクトの両方に底入れするために、新たな資金調達を決意した。そして今では、そのプロダクトには商用バージョンの‘team edition.’(チームエディション)が含まれ、この新しいエンタープライスバージョンには、ユーザー数を限定しないサポートと、サードパーティツール(GitHub、Slackなど)の統合、ロールベース(役割に基づく)のアクセスコントロールとオンボーディング(研修など)、そして12×5のサポート(月-金、昼間のみ)が含まれる。無料でシングルユーザーのコミュニティエディションと同様、このチームエディションもSaaSプロダクトとして提供され、すべてのメジャーなパブリックおよびプライベートクラウドプラットホームへのデプロイをサポートする。

Pulumiへの投資の動機を聞くとTolaのGulatiはこう答えた: “クラウドは今や規定の結論だ。でもエンタープライズがクラウドへ行こうとすると、厄介な問題を多く抱える。しかも、今のエンタープライズは、仮想マシンとコンテナとサーバーレスのすべてを理解し使いこなせねばならない。しかもそれを、1)単一のツールセットで、2)実際のプログラミング言語を使って、3)今日的な最新のスキルを使い、そして4)企業にとってもっとも有効にクラウドを利用しなければならない。率直に言ってPulumiは、このような複雑な課題と、それらをめぐるデベロッパーとITの現実によく応えている。デベロッパーとITは、ランタイムとデプロイの両側面から良好な関係を築かなければならない。それを助けるプラットホームとしては、私の知る限りPulumiがベストだ”。

オープンソースのツールは、今後も開発を続ける。また、コミュニティの構築にも厚く投資していく。同社によると、Pulumiにはすでにこれまでも相当な勢いがついていたが、新たな資金によりその努力を従来の倍にできる。

新たな資金により、オンボーディングのプロセスを容易にし、それを完全なセルフサービス型にしたい。でもそれをすべて企業任せにすることはできないから、Pulumiとしては売る前と売った後のお世話も充実させる必要がある。今現在は、この段階のスタートアップの多くがそうであるように、同社の社員はほぼ全員がエンジニアだ。だから営業の充実が、当面の優先課題になる。

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

Verizon、2019年にロサンゼルスに5G導入へ――CEOがテレビ番組で明らかに

今朝(米国時間5/15)CNBCの番組で、TechCrunchの親会社の親会社、VerizonのCEOがアメリカで新たに5Gサービスを展開する4都市の2番目の地域としてロサンゼルスを選定したと語った

VerizonのCEO、Lowell McAdamはアメリカにおける5Gネットワークの建設について「実現は一般に考えられているよりずっと近い。今年われわれは4都市を選んだ」と述べた。

McAdamはまたロサンゼルスはVerizonがアメリカで5Gネットワークを建設する4都市のうち2番めの都市になると述べた。「われわれは光ファイバーケーブルを5700万キロメートル分も買った。セルタワーに大量のデータを流すのに十分な量だ。5Gの多様なサービスに対応する帯域幅も確保していく」という。

また「Verizonは国際基準に合致したセルタワーを1000基建設する」とも語った。

McAdamは新しいネットワーク・テクノロジーを導入するにあたってもっとも熱心で協力的な自治体のリーダーとしてボストン市長の名前を挙げた。

Verizonは今年に入って5Gネットワーク建設をスタートさせることを明らかにし、カリフォルニア州の州都、サクラメントが最初の都市になるとした。

McAdamの発言からすると、5Gネットワークの導入は厳密なスケジュールに従って実施され、来年、2019年の第1四半期にはモバイル向けに先立って家庭内の固定デバイス向け5Gサービスが開始される。

この2月にAT&Tは5Gを導入することを決めた12都市のうち、アトランタ、ダラス、ウェイコの3都市が最初になると発表している。一方、Sprintが5Gを建設するのはカンサスシティー、フェニックス、ニューヨークの3都市からだ。

[原文へ]

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

企業はネットのインフラをどうやって買うのか、シードで$3Mを調達したInflectがそのための正しいデータを提供

企業が自社のためのインターネットのインフラストラクチャをもっと容易に買えるようにするサービスInflectが、300万ドルのシード資金を獲得した。そのサービスはまだプレビューだが、企業がデータセンターのための場所や、ネットワークサービス、エクスチェンジプロバイダーなどを買おうとしているとき、購買の意思決定をするために必要なデータを揃えてあげることが、メインのお仕事だ。

シードラウンドの投資家は、Greenpoint TechnologiesのJon Buccola Sr, WeeblyのCTO Chris Fanini, Server CentralのCEO Jordan Lowe, Global Communications NetworkのCEO Chris Palermo, そしてやや意外ながらCruise AutomationのCTO Kyle Vogt(Twitchの元CEO)だ。

Inflectの協同ファウンダーでCEOのMike Nguyenは、声明文の中でこう言っている: “この業界の買う側と売る側の両方をよく知っている方々からご投資いただいたことは、まことに幸運である。彼らは、コロケーションやマネージドサービス、ネットワークサービスなどを買うことの難しさを、熟知しておられる。業界のインサイダーである彼らは、正しいソリューションを得るために必要な正しいデータと、適正なサービスプロバイダーへのコンタクトが、欠落していたことに由来する失敗と損失を、全員が経験しておられる”。

Inflectはまだしばらくプレビューだが、しかしそこには、世界中の40あまりのサービスプロバイダーや約4000のデータセンターから得た検証済みのデータがある。同社の推計によると、これはグローバルに可利用でパブリックなインフラストラクチャの約80%に相当する。

なお、このようなデータの収集は難事業であり、それを集めたからといってAPIで他へ公開しようとする企業はあまりいない(Cruise AutomationのKyle Vogtは、この業界は“腹立たしいほど不透明だ”、と言う)。データサービスや通信サービスは手作業的に買うのが従来のやり方だったが、しかし、インフラストラクチャのベテランたちが創業したInflectは、それを変えようとしている。目下、データの収集が主な仕事だが、今後はユーザーが同社のカタログから直接、サービスを購買できるようになるだろう。

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

OpenStack FoundationがOpenStack以外のオープンソースプロジェクトもホストする方向へ

【抄訳】
最近の数年間で、Cloud Native Compute FoundationやCloud Foundry Foundationなど、オープンソース関連の団体がいくつか立ち上げられた。これらの多くはLinux Foundationの一員になっているが、その仲間に加わっていない大きなオープンソース団体のひとつが、OpenStack Foundationだ。ここは、少なくともこれまでは、クラウドコンピューティングプラットホームOpenStackの開発にフォーカスしてきた。

しかし、時代は変わりつつある。隔年で開催されるOpenStack Summitの最後の数日につき合ってみて明らかに感じたのは、OpenStack FoundationがOpenStackプラットホーム以外のものにも目を向け始めていて、将来この組織はLinux Foundationに似たものになるのではないか、という感触だ。ただしそのビジョンはもっとシンプルで、現在の関心に沿ったオープンなインフラストラクチャにフォーカスするだろうが、それらは必ずしもOpenStackプラットホームの一部である必要はなく、プロジェクトも今のガイドラインに縛られないものになるだろう。

OSFのこの多様化路線がうまくいけば、Linux FoundationやApache Foundationなどと並ぶ、大きくて総合的なオープンソース団体がもう一つでき、彼らのOpenStack関連の知識と経験がコミュニティをサポートしていくことになって、オープンソースのコミュニティに変動をもたらすだろう。またOpenStack Foundationが従来ならLinux Foundationに行ったようなプロジェクトもホストするようになると、二者間に興味深い競合関係が生ずるかもしれない。

その初期からOpenStackを採用しているMirantisの協同ファウンダーでCMOのBoris Renskiによると、OSFのこの新しい動きを引っ張るにふさわしい人物は、CTOのMark Collierと事務局長のJonathan Bryce、そしてマーケティングとコミュニティサービス担当のVP Lauren Sellだ。Renskiの見解では、OSFが多様なプロジェクトを手がけていくのは良いことであり、OpenStackが安定期に入りつつある現在は、新しいことに取り組む時期としても適している、と。

では、OSFが今後新たにフォーカスしていくべきテーマは、なんだろうか? Bryceによると、今計画に上(のぼ)っているのは、データセンターのクラウドインフラストラクチャ、コンテナのためのインフラストラクチャ、エッジコンピューティング(Collierがとくに関心を持っている)、継続的インテグレーション/継続的デリバリ、そして可能性としては機械学習とAIの分野だ。

Linux Foundationが主にLinuxユーザーの便宜のためにさまざまなプロジェクトを傘下に収めてきたのと同様、OSFも主にOpenStackでメインのシステムを構築しているユーザーの便宜を図っていく。だから団体の名称はOpenStack Foundationのままでよい、とBryceらは考えている。

【後略】

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

地理空間画像分析サービスのEnviewが$6Mを調達、老朽化したパイプラインネットワークを救う

過去20年間でアメリカでは、国内を縦横に走る石油やガスのパイプラインで11459件の事故が起きている。

その被害額はおよそ60億ドルと言われ、死傷者数は1660名にのぼる。

しかし新進スタートアップのEnview.に言わせると、オペレーターたちがパイプの亀裂や歪みなど事故の兆候に早期に気づくことができれば、その被害は防げたはずだ、という。

今、石油やガス、電力会社などは、同社が開発した地理空間的分析ツールを使って、そのパイプラインネットワークをモニタし管理し始めている。

Enviewはこのほど、Crosslink CapitalがリードしLemnos, Promus Ventures, Skypeの協同ファウンダーToivo Annusらが参加した投資家グループより、600万ドルの資金を調達した。

この投資に伴い、Crosslink CapitalのパートナーMatt BiggeとLemonsのパートナーHelen Boniskeが、同社の取締役会に加わった。

Enviewの協同ファウンダーでCEOのSan Gunawardanaが、声明文で述べている: “私たちの社会は、送電線やパイプ、ケーブルなどの大きなネットワークに依存している。このインフラストラクチャが損傷すれば、爆発や火災、停電、生態系の汚損などの被害が生ずる。今回の新たな資金により、弊社の技術をより大規模に展開して、北米地区で最大のパイプラインや送電線を運用する企業の需要に応じ、社会の安全性と信頼性を強化できる”。

  1. story4_3-veg-undergrowth.jpg

  2. story4_2-classified-3d-data-with-veg-health1.jpg

  3. story4_1-visual-3d-data.jpg

  4. story2_1-aerial-imagery-before.jpg

  5. story2_2-aerial-imagery-after.jpg

  6. story2_3-3d-topographic-change.jpg

エネルギー省の2017年の白書によると、今アメリカには720万マイル(1160万キロメートル)の送電線と260万マイル(418万キロメートル)の石油や天然ガスのパイプラインがある。

American Society of Civil Engineers(アメリカ土木工学会)の報告書は、アメリカの石油とガスのネットワークの大半が、50年という想定寿命のもとに1950年代に構築されている、と述べている。つまりこれらは、緊急のアップグレードが必要であり、電力企業らはそのパイプや送電線の劣化を自覚する必要がある。

Enviewのソフトウェアを使えば、そのような実態を目視できると言われる。同社のソフトウェアは国のデータセットを処理して、大手石油、ガス、電力企業のインフラストラクチャに関するレポートを作成できる。

これらの企業はこれまで、2Dの地図は見ていたが、それらは今日の、LIDARと呼ばれる、高周波レーザースキャン技術によって作られる三次元画像に比べると、あまり有用ではない。これらのスキャンが作り出す大量のデータはしかし、これまでの方法では処理が困難だった。

“地理空間分析の市場は、2016年の310億ドル規模から2021年には740億ドルに成長する、と予測されている”、とCrosslink CapitalのBiggeは声明で述べている。

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

スマートシティは道半ばだ、私たちが目指すのはダイナミックなレスポンシブシティなのだ

【編集部注】著者のColin O’DonnellはIntersectionの主任イノベーションオフィサーである。

都市テクノロジーの専門家として、私は実際に人びとが使っている魅力的なスマートシティアプリケーションの例を教えてくれ、と頼まれる機会が多い。しかし正直なところ、実際に指し示すことができるものは多くない ― 少なくとも今の段階では。都市はますます賢くなっている筈だが、利用者の眼から見ると目立って変化しているようには見えない。

これまでの都市のデジタル進化のほとんどは、人びとが見たり、触れたり、使ったりできる部分ではなく、むしろ目に見えないところで進み、市の運営そのものに焦点が当てられて来たのだ。もちろん、行政が水漏れをより良く検知できたり、建物検査の失敗予想の精度を向上させることはとても重要だ。しかし都市居住者たちに対する直接的で個人的な便益としては現れていない。従って、あまりこの分野には進展はないと考える人がいても、不思議ではない。

都市居住者としての私たちが、革新的スマートシティアプリケーションにまだ驚かされていないのは、スマートシティは退屈なものだからだ。これはデータウェアハウスの概念に対して、人びとが顔を輝かせないことと同様の理由だ(OK、そこの人たち落ち着くように)。スマートシティとはゴールへ向かうための手段に過ぎない。真のデジタルシティへの道の、途中の1ステップに過ぎないのだ。

都市が、その住民たちに実際に有形の利便性を提供し、インターネットの可能性完全に実現した都市へ進化していくためには、以下の3つのフェーズを通過することになる。1)まず環境に関するデータを収集する必要がある。2)次にそのデータを処理する必要がある。そして最後に、3)リアルタイムのアクションで反応する必要があるのだ。これを縮めて言うなら:See、Think、Do(見よ、考えよ、行動せよ)ということになる。

See ― インストゥルメンテッドシティ

ここ数十年というもの、私たちはずっとインストゥルメンテッドシティ(センサーなどの機器が行き渡った都市)に住んできた。センサー、センサー、そしてセンサー。今やセンサーはそこらじゅうに溢れている。オフィスのドアから自転車置場、そして街角の信号にもセンサーは埋まっている。全てが定量化されており、これが将来の都市開発の礎になる。何かを変えるためには、まずそれを測定することができるようにする必要がある。

Think ― スマートシティ

さて、そうして集めたデータをどうするのだろうか? ここが、GEやIBM、そしてAT&Tのような企業たちが、ここ数年注力してきた領域だ。スマートシティでは、センサーが行き渡った都市から発生するデータから洞察を得る。これはデータプラットホーム、アルゴリズム、そしてデータサイエンスを活用して行われる。私たちが測定したものを理解するだけではなく、なぜそれが重要なのかも理解できるようにできる。

私たちは、相関関係と因果関係の構築を行い、人間の行動を予測してテストするためのモデルを作り、なぜある出来事が起きたのか、そして変更がどのような影響を及ぼすのかに関する洞察を得る。AIは、膨大な量のデータを分析し、都市の状況を理解する上で、大きな役割を果たすようになって行くだろう。しかしそれらは皆、今のところ「舞台裏」の仕掛けだ。ちょうど誰もが電子メールやWeb1.0サイトを使い始める前の、インターネットのようなものだと考えてみれば良い。もちろん、それは重要で、世界の働きを変えつつあると思うが、どうして私がそれを気にしなければならないのか? 私には何ができるのか?

Do ― レスポンシブシティ

さて、ここから物事は面白くなる。何かが本当に起こり、人びとが違いに気付き、感じるようになる。開発と新製品のチャンスが最も多いステージだ。レスポンシブシティ(反応型都市)とは、その名前が表すように、市民の要求、願望、そして欲望に反応する都市である。この場合の「市民」は労働者でも居住者でも、単なる訪問客でも構わない。すべてがリアルタイムに実行され、アプリケーションを用いたアクティブでリッチな体験となる。

インストゥルメンテッドシティで発生したデータと、スマートシティで得られた洞察を用いて構築されるレスポンシブシティは、ハードウェア、データ、そして基礎サービスの上に載った、アプリケーションレイヤーのようなものだ。

都市では、これらのアプリはインフラストラクチャを操作したり、都市を動的に最適化する振る舞いに影響を与えたりすることに焦点を当てている。目標となる成果は、安全性、利便性、そして効率性はもちろんだが、発見、喜び、そしてコミュニティも対象となる。これらのすべてが、都市を魅力的にするものたちをサポートする。多様な背景を持ち、共通の時間を共有する市民たちにとって、魅力ある場所にするのだ。

これはすべて、デジタル化された制御可能なインフラストラクチャに依存している。そしてそれは急速に実現されつつある。UberとLyftは、予想される輸送ニーズに基づいて、自分たちを先行してデザインしたコネクテッドカーの例だ。

デジタルスクリーンとダイナミックな街頭施設も、レスポンシブなインフラストラクチャの初期の例だ。都市の中で拡張現実レイヤーのように振る舞う可能性と同時に、こうしたプロダクトは街頭の風景内にリアルタイムに情報を挿入し、人びとに情報と影響を与える。そして人びとを様々な方法で支援する:少し考えるだけでも、市民がよりよい移動を行えるようにしたり、市からのお知らせを表示したり、リアルタイムに緊急事態を知らせたり、といった例を挙げることが可能だ。

都市はこうしたトランスフォーメーションへの準備が整っている。デジタルインフラストラクチャー、オートメーション、そしてマシンラーニングによって、要求に対して予測とともに反応する能力が登場し、数百万人の人びとを相手にした結果を最適化することができるようになるだろう。

現代は、都市管理者、社会活動家、そして起業家たちに、大きなチャンスが与えられているのだ。それは新しい経済機会を創造し、行動を変革し、現代都市を真に再定義するために資源を再配分するためのチャンスだ。この革命に必要とされるインフラストラクチャーは、整備されつつあるが、どのようにすれば都市は最終的に、このレスポンシブな最終ステージに進むことができるのだろうか?

効率的なレスポンシブシティへの道を切り拓くためには、都市には以下のものが必要である:

リソース、アクセス、そして成果に対するパートナー

私たちは、都市で可能なことに対する私たちの先入観を捨てて、望ましい成果を考えるところから始めなければならない。都市の管理者たちは、改革の必要がある未使用のリソースやインスラストラクチャーをまず同定する必要があり、それらを民間部門と提携したり協力したりして、利用しやすいものにしなければならない。官民のパートナーシップは、相互の利便性に基いて整理されなけれなならない。例えば、どんな心身状態の人たちに対しても幅広いアクセスを許し、特定の解決方法や、事前に決められた調達手段に固定されないというようなことだ。

人びとのグループを理解し、その行動に影響を与えること

レスポンシブシティはその中に暮らす人びとを反映したものだ。インターネットは私たちに、ビデオや製品、あるいは友人たちを推薦することで、パーソナライゼーションで可能なことを垣間見せてきた。他でもない、あなたという個人 に対して。しかし、都市の体験は本質的に1対多だ。50人が1つの表示を見て、それらを一緒に体験する。しかし個々人は異なる背景を持ち、またおそらく個々人の目的は異なっている。これは興味深い研究分野を拓くものだ。すなわち人びとのグループを理解すること、そして環境の変化に対して彼らがリアルタイムにどのような反応を示すのかを理解するということだ。

環境の変化とは、例えば、オンデマンド歩行者天国のための動的な道路閉鎖のようなものだったり、異なる移動能力を持つ人びとをイベントに向けて最適な経路で案内したり、オープンしたばかりのお店を案内したりというものかもしれない。いずれにせよ、人びとの要求と都市側の要求の間のバランスを、リアルタイムで調整することは、探究すべき新しい刺激的な領域となるだろう。それは都市計画と、ユーザーエクスペリエンスと、行動科学の融合だ。

リアルタイムに行なうこと

レスポンシブシティになることは静的な目標ではなく、常に変化する目標だ。私たちは、過去の固定された単一目的のインフラストラクチャの概念を乗り越える必要がある。人間と都市の変化に合わせて動的にリアルタイムに変化するインフラストラクチャに焦点を当てる必要があるのだ。この焦点は何年もかけて都市が変化するマクロレベルなものだけに対応するのではなく、一瞬一瞬、例えば朝の通勤からランチまでの間という短い単位にも対応する必要がある。

クラウドネットワークサーバーのコンセプト

インターネットは、私たちがやっているすべてのことを変えて来た。すなわち私たちが生活する方法、働く方法、遊ぶ方法、情報へのアクセス方法、そしてお互いのコミュニケーションを変えたのだ。しかし、それは常に、その変革の可能性の期待に応え続けて来られたわけではない。私たちはインターネットが、不寛容さを育て、隔離され視野狭窄に陥ったグループを生み出すところを目撃してきた。

そして、現在の住民が生まれる遥か昔に死んでしまった人びとによってデザインされて、その変化が何十年も掛かる都市計画によって測られる都市は、淀んで柔軟性を失ったものになる可能性がある。都市は、それを実際に利用したり、働いたり、生活している人びとを代表するものではない。

しかし、インターネットが都市の中に進出す​​るにつれ、私たちはインターネットをより人間的に、そして都市をよりダイナミックにする機会を得た。

私たちは、異なる文化や背景や能力を持つ人々が、都市に対してだけでなく、人びと同士でもデジタルな相互作用を共有できる、真のコミュニティ体験を構築することができる。私たちは、環境を形作り、リアルタイムで情報を共有し、人びとやリソースをお互いにより良く繋ぎ合わせることができる。私たちには包括的なデジタル都市体験を作り上げる機会が与えられている。そしてそれは、レスポンシブシティから始まるのだ。

FEATURED IMAGE: PRASIT PHOTO/GETTY IMAGES

原文へ
(翻訳:sako)

Googleの親会社Alphabetが気球を使い、プエルトリコの携帯電話ネットワークの復旧をしようとしている

FCCは、Googleの親会社Alphabetに対して、プエルトリコならびにバージン諸島における無線サービス復旧の支援をする許諾を行った。同社は高い高度に浮かぶプロジェクトルーン(Project Loon)の気球を使用して、LTE接続を可能にしようとしている。

速報:FCC は、プロジェクトルーンの気球をプエルトリコに緊急の携帯電話サービスを提供するために、Googleに実験的ライセンスを発行します。

先月島を襲ったハリケーンマリアは、食料や飲料水のような基本的な供給へのアクセスを破壊した。今週出されたレポートによれば、まだ83%の人びとが携帯電話を使うことができていない。

「ハリケーンマリアに襲われてから2週間以上過ぎても、何百万人というプエルトリコの人びとは、必要なコミュニケーションサービスを失ったままなのです」と語るのはFCC議長のAjit Paiだ。「だからこそ私たちは、島内の接続を復旧するために、革新的なアプローチを取るする必要があるのです」。

ルーンはAlphabetのイノベーショングループの1つであるXによって開発されたものだ。  それは今年の初めには激しい洪水に襲われたペルーを支援ために用いられており、そのときの成功を再現することが期待されている。とはいえプエルトリコでその計画を進めるためには、ルーンはパートナーを組むキャリアをまず探す必要がある。ルーンは既にペルーのTelefonicaと協力していて、このことによりプロセスが加速されることだろう。

同社の広報担当であるLibby Leahyは以下のようなステートメントを述べた。「私たちは、FCC およびプエルトリコの当局のサポートに感謝します。私たちは、ルーンの気球がこの火急の時期に、島に通信をもたらすことができるように懸命に働いています。人びとのデバイスに信号を提供するために、ルーンを通信パートナーのネットワークと統合する必要があります。気球単独でそれを行なうことはできません。私たちは、この次のステップでも着実に進歩しています。手を貸していただいている、全ての皆さまに感謝いたします」。

ルーンプロジェクトは、気象観測気球のように18キロ以上の高さに上る、高高度気球のネットワークで構成されている。ルーンの気球は「風に乗って」目的地に着き、成層圏で100日以上耐えられるように、超高圧がかけられています。

信号は直接LTEを利用するデバイスに届けられ、地元のキャリアへと回線が繋げられる。また望ましい方向に吹く風によって気球の高度は調整される。

Teslaもまた、プエルトリコを支援する作業を行っている。

既に何百ものTesla Powerwallバッテリーシステムが既にプエルトリコに持ち込まれ、Teslaの従業員たちが、各地域で設置と保守のための訓練を行っている。

TeslaとGoogleによる島のインフラを再構築する作業には、Facebookも加わり、復旧と復興のために、島に連携スタッフが送られることが約束されている。

[原文へ]
(翻訳:sako)

FEATURED IMAGE: U.S. DEPARTMENT OF AGRICULTURE/FLICKR UNDER A PUBLIC DOMAIN LICENSE

DropboxがAWSを捨てて独自のインフラとネットワークを構築した理由

企業内には、必要なものは何でも、自社で作るかあるいは購入するかについての緊張が常にある。数年前Dropboxは、必要とするインフラストラクチャの大部分をAWSから自社のデータセンターに移行することを決定した。想像できるように、それには大変な努力を要したが、自らの運命をコントロールできることの利点は、そこに到達するまでに直面する、すべての困難に見合う価値があると彼らは信じていたのだ。

まず第一に、Dropboxのような会社は、莫大な量のデータを保存している多数の顧客を扱っている。最新の数字によれば、5億人のユーザーと20万のビジネス顧客がいる。彼らが移行を行ったときには、AWSサーバーに置かれていた500ペタ(5のあとに0が17個続く)バイトという真に膨大な量のデータを移動させる必要があった(AWSはまだ一部のワークロードで使用されている)。

最初のステップは、それを置き換えるインフラを構築することだった。ここで話題にしているのは、わずか数十人のインフラチームを抱える、総勢1500人の会社のことだ。これは超大規模な作業ではなかったが、彼らがやろうとしていたのは、それまでは遥かに大きなチームを抱えたわずかな会社だけが成し遂げていたことを、自力で行なうということだった。

それには米国内の3つのデータセンターの建築と運用が含まれていた。またそれは、米国のデータセンターと世界中に散らばる他の施設の間をつなぐネットワークバックボーンの構築も意味していた。Dropboxを開いてファイルをリクエストしたなら、利用者はファイルが待ち時間なくほぼ即座にダウンロードされることを期待するだろう。古いシステムから新しいシステムへの移行が行われている最中も、それが確実に行われるかどうかはチームの腕次第だった。

「バックボーンについて見られる素晴らしい点は、おそらくGoogleやFacebookの中でも見つけることができるでしょう。しかし私たちはそれを彼らよりも小さなチームで成し遂げたのです」とTechCrunchに語るのは、Dropboxのプロダクションエンジニアリング責任者のDan Williamsだ。そしてその小さなチームは、すべてのサービスを継続的に運用しながら、バックボーンを構築して、すべてのコンテンツを移動しなければならなかった。

とはいえ同社は、インフラストラクチャーのコントロールを切望していたので、この大規模な作業を喜んで行ったのだ。Williamsは、このような決定を下す際には常に譲歩が必要なことは認めていたが、最終的にそれらのトレードオフは意味のあるものだった。「私たちの場合、それは品質とコントロールと管理に関するものでした。高い品質と性能を備えたしっかりした第三者がいることは分かっていますが、私たち自身のシステムも同じか、あるいは更に良いものだと感じています。なぜなら自分たちのシステムなのでその中身を良く知ることができるからです」。

Williamsによれば、Dropboxにとって、ネットワークを構築することはビジネス上の決定であり、全体的なビジネスにプラスの影響を与えたと語った。「このようなかなり規模のネットワークを実際に構築した者は、ビジネス上によい影響があると考えています。本当にユーザーの信頼を獲得することができますし、この高い品質のサービスに基く、更なるプロダクトやサービスへユーザーを迎えることができるからです」とWIlliamsは説明した。

新しいシステムは、確かに企業ITにおけるDropboxの評判にプラスの影響を与えた。過去を振り返ると、Dropboxは大規模な組織内での未許諾利用によって、しばしばIT部門から悪評を招いていた。今日では、Dropbox Businessの製品ラインが、企業のインフラストラクチャとネットワークを組み合わせて、これまでにないレベルの信頼性を実現している。Williamsは、Dropboxがネットワーク運用の詳細な洞察を得ていること、そして今回の変更でユーザーに新たな負担は求めなかったものの、その運用データはセールスに活用できていると語った。

「私たちの信念の1つは、高性能で低コストの製品を提供することです」彼はこれによって、この移行を通じて古い顧客を維持しつつ、ユーザーベースを増やすこともできたのだと信じている。

所有コストが実質的に下がったかどうかにはかかわらず、同社はそれを自ら構築することによって目標を達成できた考えている。「コストは常に考慮していますが、私たちのネットワーク拡張の目標は、ユーザーのためにパフォーマンス、信頼性、柔軟性およびコントロールを向上させることでした。これには成功することができたのです」と同社広報担当者はTechCrunchに語った。

自作するか購入するかの意思決定は決して簡単ではない。特に移行中に2つのシステムの間でバランスをとらなければならなかったDropbox程度の規模の会社にとっては。しかし現在振り返ってみれば、彼らにとっては十分に価値があったようである。

[ 原文へ ]
(翻訳:Sako)

FEATURED IMAGE: KYNNY/GETTY IMAGES

インフラストラクチャのマーケットプレースInflectがサービスプロバイダー30社データセンターとピアリングロケーション2200を新たに加える

サンフランシスコのInflectは、企業が適切なコロケーションファシリティやネットワークサービス、エクスチェンジプロバイダーなどを見つけようとしているとき、それをより容易にしてくれるスタートアップだ。2か月前にローンチしたばかりの同社は今日(米国時間8/24)、そのデータベースに新たに30あまりのサービスプロバイダーと約2200のデータセンター、およびネットワーキングのピアリングロケーションを加えたことを発表した。新しいサービスプロバイダーには、CenturyLink, Cogent, Comcast, Equinix, Level 3, T5, Telstraなどこの業界のヘビー級のプレーヤーたちも含まれる。

ネットワーキングやコロケーションのプロバイダーの詳細情報や課金情報は、あまり簡単には得られない。データや通信の企業は、非常に古いタイプの営業過程を経て契約が決まることが多く、その過程は透明性が乏しい。シードで200万ドルを調達したInflectは、そういった過程を21世紀にふさわしいものにしたい、と考えている。同社はデータをプロバイダーやPeeringDBのデータベースから自分で集める。後者は、ネットワークのピアリング情報を得るためのデファクトスタンダードだ。InflectはPeeringDBのデータをもらい、それを同社独自の検証処理にかける。そして情報のどこをどう変えたかを、PeeringDBと共有する。

協同ファウンダーでCEOのMike Nguyenはこう語る: “ここまで数週間のローンチ直後の反応は、嬉しいものであると同時に、反省を迫られるものでもあった。ユーザーは私たちに、正確で特定ベンダーに傾かないデータを低コストで提供するInflectのようなプラットホームをずっと求めていた、と言う。しかし同時に、サービスプロバイダーたちは、実際にこれから買おうとしている買い手の目の前に、自分たちのサービスを置いてくれるようなプラットホームを探していた、と言うのだ”。

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

Dropbox、独自ネットワークの運用開始――パフォーマンス向上とコスト半減を期待

昨年、DropboxがAWSから離れ、独自のデータセンターを建設する計画を明らかにしたとき、Dropboxのネットワーク自体も大幅に改革されるはずだ推測された。今日(米国時間6/19)、Dropboxは世界のネットワークの大きなアップデート計画を発表した。これによりユーザーは同期速度が大きくアップし、Dropboxにとってはコストが節減されるという。

この大胆なプランにはいくつかの側面がある。一つはGoogle、Amazon、Facebookのような世界的インターネット企業のものに似たカスタムメイドのデータセンターの建設だ。しかしDropboxのようなサービスの場合、ハードのインフラの整備だけでは十分ではない。ストレージ処理をスピードアップするためにはできるだけユーザーに近い場所でサービスを提供できるようにする必要がある。これはコンピューティングをネットワークのエッジに近づける手法と呼ばれている。

Dropboxによれば同社はすでに3大陸、7カ国、 14都市でネットワーク拡張の努力を開始している。 Dropboxのエンジニア、Raghav Bhargavaは同社のブログで、「〔迅速なサービスを実現するために〕われわれは地域的、世界的なISPと契約して数百ギガビットものインターネット接続を追加してきた。またISPを通さず直接データをやり取りするピア・パートナーも数百に上る」と書いている。

同社はこの努力を次のレベルに進めることとし、オープンソース・ソフトを全社的に採用してカスタム・プロキシを開発した。 「エッジ・プロキシはサーバーのスタックでユーザー側から見た最初のゲートウェイとなり、TLS/TCPのハンドシェイクを実行する。これはPoP(point of presence)に導入され、ユーザーが世界中どこにいてもDropboxへのアクセスのパフォーマンスを向上させる」とBhargavaは書いている。

このタイプのネットワーク・アーキテクチャは通常AkamaiのようなCDN(Content Delivery Network)によって提供されることが多かった。しかしDropboxの規模でサービスが提供されるようになると、独自の必要に対応するカスタム・ソリューションを開発する必要があると認められた。

イラスト: Dropbox

今日からDropboxはアメリカのデータセンターでカスタム・プロキシの運用を開始するが、今後世界のデータセンターに導入していく。まずシドニー、マイアミ、続いて第3四半期にはパリ、第4四半期にはマドリッドとミラノが予定されており、今年の末までに4カ国25カ所の施設すべてに導入される。

このネットワークのアップグレード計画には2つの理由がある。一つはユーザー体験の改良で、ユーザーが世界のどこにいようと処理スピードをアップさせる。Dropboxによればユーザーの75%はアメリカ国外からアクセスしているという。したがってコンピューティングをユーザーが存在する場所に可能な限り近付けるエッジ・プロキシの手法は、Netflixも採用しているが、きわめて重要となる。ネットワークのアップグレードが完了し、PoP数も大幅に増加すれば、多数のユーザーを抱える地域でのパフォーマンスの向上が期待できる。

第2の理由は、独自のハード、ソフトを構築することにより大幅なコストの削減が可能になる点だ。同社によればこのアプローチはネットワーク・コストを半減させるという。そうであればDropboxの経営に大きな影響を与える節約となるだろう。

Dropboxには上場の噂が絶えない。ネットワークのインハウス化の進展によるサービスの向上とコストの削減は投資家に対するアピールとして有効だろう。.もちろんユーザーにとってのメリットも大きいはずだ。

画像: download.net.pl/Flickr UNDER A CC BY-ND 2.0 LICENSE

[原文へ]

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

脱クラウドして自前のインターネット・インフラストラクチャを構築する企業を助けるInflect…難しい買い物の最適解を提供

AWSのような快適安全なパブリッククラウドから、自前のインフラに移ることになると、面倒なことがたくさんある。たとえばデータセンターやネットワークやエクスチェンジ・プロバイダーを選ばなければならない。でも、これらのインフラストラクチャサービスを迅速に買い整える能力の持ち主が、チームにいないことのほうが、むしろふつうだろう。

今日プレビューでローンチしたInflectは、その全過程を容易にしてくれる。サンフランシスコの同社が顧客としてねらうのは、パブリッククラウドで大きくなり、そして今やそのサービスの一部を、プライベートクラウドへ移す必要が生じた企業だ。移行の理由は、経費節減や特別のニーズなど、さまざまだ。COOのCharles Stewartはこう語る: “そんな幸運な少数者は、なにもかも一つのクラウドに放り込んでおける状態ではなくなってる。成長の過程でそんな曲がり角(inflect)に来ると、そんな厳しい驚きに見舞われるのだ”。

これまでは、データセンターや通信企業を買うことは手作業だった。たくさんの情報を調べ、それらを検証して、それから数社の営業に会う。でも企業のインフラストラクチャチームにとっては、これが彼らの足を重く引っ張る。

Inflectは、そんな企業に一つの中立的なツールを与え、それを使って正しいソリューションを見つけてもらう。そして、正しいインフラストラクチャプロバイダーを紹介する。

Stewartが強調するのは、Inflectが中立を志向することだ。データをさまざまなソースから集め、ユーザーが情報に基づく決定をできるように導くが、決めるのはあくまでもユーザーだ。それどころか、同社のサービスは今のところ無料だが、今後はユーザーが行う買い物(例: データセンター)を同社のプラットホーム上からできるようにして、それを収益源にしたい、と考えている。

以上はきわめて単純明快なサービスに思えるから、これまでそんなサービスがなかったことが不思議だ。同社が言うその理由とは、多くのサービスプロバイダーからデータを集めることが、たいへんな作業だからだ。簡単容易にデータにアクセスできないところも、ざらにある。外部に対してデータを出し渋るサービスプロバイダーもあるし、自分のサービスが必要としないかぎりはAPIすら作らないところもある。この公開APIをめぐる状況は、ぜひ変わってほしいとInflectは望んでいる。同社は通信企業とはすでに親密な仲を築いており、データも他社に比べれば得やすくなっている。また、PeeringDBからのデータも使っている。

目下Inflectは、AmazonのAWSプラットホームから自己サーバーへ移行しようとする企業を顧客としてねらっている(戻りたければAWSに素早く戻れるように、というニーズもある)。将来的には、ほかのプラットホームのユーザーもサポートしていきたい。ユーザーが自社の既存のインフラストラクチャに関する情報をタグを付けてInflectにアップロードすると、それを基に最適解を選び出す。

Inflectはこれまで、200万ドルのシード資金を調達している。その資金で同社は、今年の第三四半期の終わりごろまでにサービスを一般公開へ持って行きたい、と考えている。そしてその次は、サービスを拡張するための新たな資金調達を目指す。

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

GoTenna Proのメッシュ無線は、救助、火災、セキュリティチームの支援を狙う

コミュニケーションのインフラが、何らかの理由で失われてしまった時に、連絡し続けることができるなら、個人間の場合でも素晴らしいことだが、災害対応、森林火災対応、そして軍事行動の場合にはとても重要なことである。GoTennaは、既存のパッケージに比べて遥かに小さくて軽い新しいProデバイスを、そうした際に役立つ強力で信頼性の高いオフグリッド通信手段として、提供しようとしている。

オリジナルのgoTennaを覚えている人もいるだろう。これは携帯電話とBluetoothで接続されるキャンディ菓子程度の大きさのデバイスで、トランシーバーの周波数を使って、他のgoTennaに接続された携帯電話との間でメッセージやGPS情報を交換することを可能にするものだ。これは、バックパッキングや停電といった状況などで便利なデバイスだ。しかし、goTennaのCEOであるDaniela Perdomoは、より深刻な状況での利用に関心を寄せる利用者たちが、プロダクトの発表後文字通り数分で現れたと語った。

パークレンジャー、消防士、そして貧困地帯や戦闘によって破壊された地帯に赴くNGOたちは、モトローラやBAEそしてロッキードなどが提供する既存のメッシュ無線システムを補完するものとして、goTennaのアイデアを気に入ってくれた。大企業の提供する無線システムは、まずベースステーションを設置し、そこから離れて小さなユニットを人びとが持ち歩くこととで、お互いの通信を可能にする。これで、自分たちのチームだけがアクセスできるネットワークの出来上がりだ。しかしこうしたデバイスは一般に不格好なだけではなく、とてつもなく高価だ。基本的な構成のユニットでも数千ドルの出費を考えなければならない。市場規模は数百億ドルに及ぶ。

「捜索と救助、軍事、援助機関…彼らはこうした機器を毎日使っています。これが彼らの主要な通信モデルなのです」とPerdomoは言う。「しかしそこでは、例え大きなNGOでさえも、高額すぎて買えずにいる場合もあるのです。時には、それぞれのグループや団体が使っている製品が海外では利用できない為に、お互いが協力する際に通信できない場合もあるかも知れません」。

どうやら、真面目な競合相手が求められていたそうしたシステムに対して、Perdomoが名乗りを上げているようだ。

Proは大部分がオリジナルのgoTennaに似通っている。ただし、オリジナルは消費者向けデバイスであったために、(例えばFCCの規制などによって)使える周波数や通信出力などが制限を受けていた。Proは文字通りプロ向けに設計し製造したことで、ソフトウェアで制御される無線機能はVHF並びにUHFの周波数帯(142-175MHz並びに445-480MHz)へのアクセスと、より大きな通信出力(5W)が可能になった。

また、さらなる耐久性と60時間以上の動作が可能な大容量バッテリーが与えられている。またそれはSMAアンテナ標準を採用しているので、そこに大きなアンテナを接続して、特別な基地局なしに数マイルの距離間で通信が可能になる。Proは十分に軽いので、ドローンに搭載することでさらに通信距離を稼ぐことも可能だ。

ある会社はProに興奮するあまり、公式発表の前に記事を書いてしまったほどだった (Perdomoは特に腹を立てなかったようだが)。記事トップに示したTechnosylvaによるイラスト(火災対応ロジスティックスシステム)には、LTEや他のアプリなどの範囲外で、メッシュコミュニケーションがヘリコプターや基地局をカバーし、情報が届く様子が示されている。ここでは沢山の相互運用が行われている。

1つあたり500ドルという価格は、1度に1台ずつではなく、1度に複数台を購入することを可能にするだろう。その価格ならNGOが破産することもなく、軍事用途なら実用上使い捨ても可能だ。音声通信は行えないが、ほとんどの場合にはテキストと位置情報だけで事足りる。とにかく、誰かがこれ以上誰かを通話で呼び出す必要があるだろうか?

ちょっとした難点がある。このデバイスは、業務用または公共安全用無線帯域向けのライセンスを持つ人たちだけに対して、FCCが承認している。こうしたライセンスを所有していない者が、このデバイスを所有することは想定されていない。もちろん正確に言えば、このデバイスを購入すること自体は可能だしかしそれを運用することは、厳密に言えば違法である。

よく言われる事だが、備えあれば憂い無し。なお既にgoTenna Proの事前予約を同社のウェブサイトで行うことができる。

[ 原文へ ]
(翻訳:Sako)

パブリッククラウドプラットホームにおけるAWSの王座は今後も揺るがず

img_20161130_104056

Amazonは木曜日(米国時間2/2)の決算報告の中で、同社のクラウド事業部Amazon Web Servicesの収益についても発表したが、それらは意外性とはほど遠いものだった。AWSの成長率そのものは、そのライバルのように突出してはいないが、それでも47%の高率、142億ドルという驚異的な四半期売上で35億3000万ドルの利益を上げた。

Microsoft Azureなどの方が成長率が高い、とはいっても、彼らはそもそも、最初から分母が小さい。AWSは巨体になりすぎて、子どもの体の敏捷さを失っているだけだ。

MicrosoftやIBM, Google, そしてOracleやAlibabaまでも、クラウドの高い成長率を誇っているが、彼らを全部合わせてもマーケットシェアではAWSに及ばない。しかも彼らが今後どれだけ売上を稼いでも、市場そのものがものすごい高率で成長している。つまり長期的に見れば、彼らは一定のサイズのパイの分け前を争っているのではない。

今ではいろんな市場予測があって、どれが正しいのかよく分からないけど、IDCの数字では、昨年のパブリッククラウドの市場規模は950億ドルだ。同社は、3年後にはこの倍以上、すなわち2020年には1950億ドルと予想している。これが正しければ、どのクラウド企業にも巨大な市場機会があることになる。

同じくIDCが予測する2020年の全企業のIT支出の総計は、2兆7000億ドルだ。少なくとも当面は、全IT支出の中でクラウドサービスへの支出が、微々たる比率であることが分かる。

これよりも楽観的なForresterは、2020年のパブリッククラウドの市場サイズを2360億ドルと予測している。どんな数字になるにせよ、市場そのものが急成長していることは明らかである。

それはマーケットシェアを争う各社にとっては良いニュースだが、AWS自身も急成長していくわけだから、それに追いつくのは難しい。Amazonは10年以上も前に業界で初めて、パブリッククラウドをInfrastructure as a Service(サービスとしてのインフラストラクチャ)、すなわちIaaSとして市場化したが、その後数年間にわたり、この新しい業態に挑戦する競合他社は一社も出現しなかった。

今日では、Synergy Researchの数字によれば、マーケットリーダーであるAWSのマーケットシェアはとてつもなく大きい。変化の激しい市場だから一概に言えないとはいえ、Synergy ResearchのチーフアナリストJohn Dinsdaleの説では、AWSに追いつくことはMicrosoftにとってすら、非常に難しい。

screen-shot-2017-02-02-at-1-12-09-pm

Dinsdaleは語る: “単純に数字だけから言っても、AWSと二位以下との差があまりにも大きいから、短期的には首位争いと言えるほどの競争はありえない”。しかもAWSは、大きなマーケットシェアに安住することなく、次々と新しいイノベーションを打ち出している。

“AWSはインフラへの巨大な投資を継続しており、サービスの幅の拡大と実行性能の向上にも継続的に努めている。そのビジネスは顧客企業の成長と共に成長し、また今では重要な存在であるAWSを、母体であるAmazonが長期的に支えている。数字から言っても、ビジネスの論理から言っても、規模とマーケットシェアでAWSに匹敵するような競合他社は、近未来においては存在し得ない”、とDinsdaleは言葉を継ぐ。

だから今後しばらくは、すべてのパブリッククラウドベンダが、驚異的な業績をあげるにしても、それはAWSのシェアを奪ってのことではない。むしろ、今でもAWSのマーケットシェアは拡大を続けており、新しい機能やサービスを非常に頻繁に加え続けているから、資本力と企業力で負けていないMicrosoftやGoogleでも、AWSのマーケットシェアに食い込むことは、当分のあいだ難しいだろう。

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

いまさら聞けないコンテナ入門

wtf-containers

いまどき開発者会議に行って、ソフトウェアコンテナについて聞かずに済ますことはできない:Docker、Kubernetes、Mesos、その他多くの海事にちなんだ名前が耳に入ってくる。Microsoft、Google、Amazonそして他の皆も、昨年あたりからこのバンドワゴンに飛び乗っているようだ、だが皆が夢中な理由は何だろう?

コンテナがこのように大変な注目を集める理由を理解するために、まず物理的コンテナのことを少し考えてみよう。現代の海運業界が、現行の形で機能しているのは、私たちが輸送用コンテナサイズに対して、限られた数の標準化をしているおかげである。この規格が出現する前には、大量に何かを出荷することは、複雑で面倒なプロセスだった。たとえばスマートフォンが載せられたパレット(フォークリフトですくい上げることのできる荷台)を、船から降ろしてトラックに積むときに、どれほど苦労するか想像してみると良いだろう。アジアからスマートフォンを持って来る際に、特化した船を使う代わりに、私たちは、荷物を全てコンテナに収納することができる。そうしたコンテナがどのコンテナ船にもフィットすることは保証されている。

ソフトウェアコンテナの背後にある考えは基本的に同じだ。完全なオペレーティングシステムとソフトウェア(およびあなたのソフトウェアが依存するソフトウェアも)を出荷する代わりに、単にあなたのコードとそれが依存するものだけをコンテナへパックすれば、どこでも動作させることができる ‐ それらは通常かなり小さいため、1台のコンピュータ上に多くのコンテナを詰めることができる。

なぜこれが、そんなに大したことなのだろう?コンテナが普及する前には、いわゆる「仮想マシン」が、1台のサーバーで互いに独立した多くの異なるアプリケーションを実行させる手段として、有力なものだった。それこそが第1世代のクラウドアプリケーション(そしてウェブホスティングサービスまでも)を可能にしたテクノロジーだったのだ。すべてのアプリケーションのために、いちいち新しい物理サーバーを立ち上げていたら、コストが屋根を突き破ってしまっていただろう。

仮想マシンの動作は、オペレーティングシステムとコードを一緒にパッケージすることで行われる。仮想マシン上のオペレーティングシステムは、自分自身の専用サーバー上で動作していると思っているものの、実際には、サーバーを多くの別の仮想マシンたちと共有しているのだ ‐ それぞれの仮想マシンがそれぞれのオペレーティングシステムを持ち、そしてお互いを知ることはない。それら全ての仮想マシンの下にあるのが、ホストオペレーティングシステムで、これら全てのゲストそれぞれに、自分が世界の中心だと思わせる役割を果たしている。しかしこれが問題であることはおわかりだろう。ゲスト仮想マシンは基本的にエミュレートされたサーバー上で動作し、そのことは多くのオーバーヘッドを生み出し、動作を遅くする(まあその代わり、同じサーバー上で沢山の異なるオペレーティングシステムを実行できるのだが)。

輸送用コンテナの話に沿うならば(そしてそのメタファーを不条理まで突き詰めるならば)、これは巨大なコンテナ船を所有することに似ている。その巨大なコンテナ船には沢山のプールがあり、そのプールにはそれぞれ特別なコンテナ船が浮かんでいるのだ。

それぞれのコンテナは全く異なる動作をする。それらは単にアプリケーションと、それが依存するライブラリやフレームワークなどだけを含むので、1つのホストオペレーティングシステム上に沢山のコンテナを置くことができる。サーバー上のオペレーティングシステムは、1つのホストオペレーティングシステムだけで、コンテナたちはそれと直接対話をすることができる。これによって、コンテナを小さく、オーバーヘッドも著しく低く保つことが可能になる。

仮想マシンは、ゲストとホストオペレーティングシステム間のエミュレーション層として、いわゆる「ハイパーバイザー」を使用する。コンテナの場合、コンテナエンジンが大雑把ではあるがこれに対応している。中でもDockerエンジンが現在最も人気の高いものである。

コンテナは、ずいぶん昔にLinuxのコア機能となったのだが、それらはまだまだ使うことが難しかった。Dockerはコンテナを使いやすくするという触れ込みで立ち上がり、開発者たちは素早くそのアイデアを理解した。

コンテナは、開発者たちが、自分のコードがどこにデプロイ(配備)されても、変わらずに実行できるようにすることを容易にする。そしてそれは、しばしば「マイクロサービス」と呼ばれるものを実現可能にする。ひとかたまりの大きなモノリシックなアプリケーションにする代わりに、マイクロサービスはアプリケーションを互いに対話できる小さな部分に分割する。これが意味することは、異なるチームがアプリケーションのそれぞれ異なる部分に対して作業をしやすくするということだ。それぞれの部分が対話する方法を大幅に変えない限りは、という条件付きだが、チームは独立して仕事を進めることができる。これにより、ソフトウェア開発が加速され、起き得るエラーを簡単にテストすることができるようになる。

これらのコンテナすべてを管理するには、他の専用ソフトウェア群が必要だ。その1つの例がKubernetes(当初Googleによって開発された)で、これはコンテナを異なるマシン上に送り出す手伝いを行い、きちんと実行されることを保証し、需要が高まった際に特別なアプリケーションを載せた幾つかのコンテナを自動的に立ち上げる。そしてもしコンテナ同士にお互いを認識させたいのなら、それぞれのコンテナにIPアドレスを割り当てる、仮想ネットワークを設定する手段が必要となる。

コンテナは、あらゆる種類のアプリケーションを実行することができるものの、仮想マシンとはかなり異なっているために、大企業がいまだに使っている多くの古いソフトウェアが、このモデル上には移行していない。しかしながら、仮想マシンは、そうした古いアプリケーションをAWSやMicrosoft Azureなどのクラウドサービスに移行させる役に立つ。このため、コンテナには多くの利点があるにも関わらず、仮想マシンも簡単にはなくなることはないだろう。

[ 原文へ ]
(翻訳:Sako)

ChefのHabitatは多様なインフラストラクチャへの対応雑務からアプリケーションデベロッパーを解放する

Chefが今日(米国時間6/14)、Habitatをローンチした。それはアプリケーションを、いろんなインフラストラクチャの上でそのまま動けるようにパッケージする、オープンソースのプロジェクトだ。

Habitatは基本的に、アプリケーションを独自の軽量ランタイム環境で包み、それらをどんな環境でも動けるようにする。ベアメタルのサーバー、仮想マシン、Dockerコンテナ(+そのコンテナ管理サービス)、Cloud FoundryのようなPaaSシステム、などなど。

2016-06-14_1038

“アプリケーションをインフラストラクチャへの依存性から解放して、DevOpsが本来の仕事をできるようにすべきである”、とChefの協同ファウンダーでCTOのAdam Jacobが今日の声明で述べている。“オープンソースソフトウェアは世界中でこれからもどんどん作られていく。そんな中へHabitatを送り出すことは、たいへんすばらしい。アプリケーション中心の自動化が、現代の開発チームに彼らが本当に望むものを与える。それは、新しいアプリケーションを作ったら、ややこしいインフラの工事をいっさいしなくても、それをすぐに動かせることだ”。

Chefのチームによると、最近のソリューションはどれも、あまりにもエンタープライズへ視野狭窄していて、どの企業の環境も独自に深くサイロ化しているので、“われわれはソフトウェアを個々のサイロに合わせていちいち再設計しなければならない”、という。一方GoogleやFacebookのようなWebスケールの企業は独自のプラットホームをスクラッチから作り、それを作ることが彼らのビジネスになっているが、それはどんな企業にもできるやり方ではない。

そこでHabitatは、アプリケーションの見地から見て、アプリケーションを作り、デプロイし、管理するためのベストの方法は何か?、という問に答えようとする。それは、インフラストラクチャを定義するのではなく、アプリケーションが動くために何を必要とするか、を定義し、そこから出発する。そして、一種の“スーパーバイザー”であるHabitatがデプロイを担当し、またあなたがそこにデプロイしたいと考えている環境の、アップグレードやセキュリティポリシーの面倒も見る。

Chefのチームによると、レガシーのアプリケーションをHabitatに移植するのは、かなり簡単だそうだ。

Habitatのそんな約束は、そもそも、かねてからコンテナについて言われていたことと似ている。でもChefによると、Habitatはコンテナ体験を改良し、コンテナ管理の複雑性を大幅に減らした。そこで、ある意味ではこのプロジェクトは、コンテナに対するChefの反応のようでもある。コンテナは、少なくとも部分的には、同社のコアビジネスを脅(おびや)かしているのだ。そして当然ながらHabitatは、Chefの既存のDevOpsツールと問題なく併用できる。

Habitatを試してみたい人のために、Chefはチュートリアル集対話的なデモを提供している。

2016-06-14_0844_001

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