Cloud | SEO-LPO.net

UberがLinux Foundationに加盟してオープンソースツールへのコミットを強化

Uberが今日の2018 Uber Open Summitで、同社がLinux Foundationにゴールド会員として加盟し、オープンソースのツールの利用と寄与貢献にコミットしていくことを発表した。

UberのCTO Thuan PhamにとってLinux Foundationは、同社がオープンソースのプロジェクトを育（はぐく）み開発していくための場所だ。“オープンソースの技術はUberの中核的サービスの多くを、そのバックボーンとして支えている。会社の成熟とともに、これらのソリューションはますます重要になっている”、と彼はLFへの加盟を発表するブログ記事で述べている。

意外なのは同社が参加したことでなく、それまでに要した年月の長さだ。Uberはかなり前から、その中核的ツールにオープンソースを多用していることで知られていたし、同社の資料によると、これまで320あまりのオープンソースプロジェクトとリポジトリに関わり、1500名のコントリビューターが70000あまりのコミットに関わっている。

Uberのスポークスパーソンは次のように語った: “Uberは何年も前から、オープンソースによる共有的ソフトウェア開発とコミュニティのコラボレーションに有意義な投資をしてきた。その中には人気の高いオープンソースプロジェクト、分散トレーシングシステムのJaegerへのコントリビューションもある。また2017年にはLinux Foundation傘下のCloud Native Computing Foundationに加盟している”。

Linux Foundationの事務局長Jim Zemlinも、Uberの加盟を喜んでいる。声明文に曰く: “彼らの専門的な技能や知識は、これからクラウドネイティブ技術やディープラーニング、データ視覚化など今日のビジネスにとって重要な技術の、オープンなソリューションを進めて行かなければならないわれわれのプロジェクトにとって、きわめて有益である”。

Linux Foundationは数多くのオープンソースプロジェクトがその傘下にある支援組織で、Uberのような企業がオープンソースのプロジェクトをコミュニティに寄与貢献しメンテナンスしていくための、組織構造を提供している。そしてその傘の下には、Cloud Native Computing Foundation, Cloud Foundry Foundation, The Hyperledger Foundation, そしてLinuxオペレーティングシステムなどの専門的組織が並んでいる。

これらのオープンソースプロジェクトをベースとして、コントリビューターの企業やデベロッパーコミュニティが改良やフォークを重ね、自分たちのビジネスに活かしていく。Uberのような企業はこれらの技術を使って自分のバックエンドシステムを動かし、サービス本体は売らないけどオープンソースのオープン性を利用して自社の将来の要求も満たしていく。その際はコントリビューターとして貢献することになり、取るだけでなく与える側に回る。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

DropboxのExtensionsでストアしたコンテンツへの仕事がDropboxに居ながらにしてできる

Dropboxには前から、そこに保存したファイルにプログラムからアクセスするためのAPIがある。また同社は、Adobe, Google, Autodesk, Microsoftなどの大企業とパートナーシップを結んできた。そして今日（米国時間11/5）は、サードパーティのパートナーとのワークフローの構築と統合を（Dropbox内で）していくための、Dropbox Extensionsと呼ばれるサービスをローンチした。

Dropboxでエンジニアリングとプロダクトとデザインを担当しているSVP Quentin Clarkによると、同社はかねてから、ユーザーがDropboxに保存したコンテンツを、彼らが使っているそのほかのツールと統合するニーズがあることを、認識していた。“Dropboxだけに限定されないもっと広いエコシステムを支えることに、最大の価値がある。Extensionsはそのための障害を取り除き、エンゲージメントを広く深くしていくための方法の一つだ”、とClarkは語る。

彼によると、APIを使えば、コンテンツを取り出して、それで何かをして、結果をDropboxの置くことは可能だが、ExtensionではユーザーがDropboxの中で直接、アクションできる。ほかのアプリケーションを開かなくても、ユーザーが今いるところで何でもできる、というエンタープライズツールは目下のトレンドであり、Dropboxもそのトレンドに乗りたいのだ。

またそのやり方で、ある種の自動化が可能になる場合もある。その一つの例として、Dropbox Extensionsを電子署名のサービスAdobe Sign, DocuSign, HelloSignなどと統合すると、契約書をDropboxに保存し、それをあちこち送って署名を求め、すべての署名が集まったら、すべての署名入りドキュメントが自動的にDropboxへ返される、という使い方がありえる。そのとき、そのプロセスを始動した者には、完了通知が行く。

今日のリリースに含まれているそのような統合は、Vimeoでビデオの編集、Pixlrで画像の編集、NitroやairSlate, SmallpdfなどでPDFの編集、HelloFaxでFAXを送る（まだFAXが必要なところへ！）、などだ。Clarkによると、これら初期に導入した統合は、ユーザーが、Dropboxとのディープな統合を一番多く望んでいたアイテムだ。

Dropboxのパートナーチームは、Extensionsのそのほかの使い方も追究していくが、実装はエンジニアリングチームとの協働になるので、ユーザーの要望が多いと思われるものから順に着手していく、という。

Extensionsの発表は今日だったが、一般公開は11月27日だ。企業ユーザーだけでなく、すべてのユーザーが利用できる。それは、Dropboxでは単なるストレージだけでなく、いろんな使い方ができることを、広く知ってもらいたいからだ、とClarkは言っている。また、このやり方によって、統合の便利さが知れ渡り、今後の企業ユーザー、企業向けプロダクトのユーザーも増えるであろう、という皮算用もしている。

画像クレジット: TechCrunch

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

データサイエンティストたちのモデルの活用度を高めるGoogle CloudのKubeflowパイプラインとAI Hub

今日（米国時間11/8）Google Cloudが、KubeflowパイプラインとAI Hubを発表した。この二つのツールは、データサイエンティストが、自分の作ったモデルをいろんな組織や企業で共通的に利用できるようにすることが主な目的だ。

Google CloudでAIとML製品を担当しているプロダクトマネージメントのディレクターRajen Shethによると、同社は、データサイエンティストたちが、モデルを作るけどそれが一度も使われない、という経験をしょっちゅうしていることを知っている。Googleによると、機械学習を団体競技にたとえるなら、モデルはデータサイエンティストから、それらを使ってアプリケーションを作るデータエンジニアとデベロッパーにパスされなければならない。

対策としてGoogleが発表したのが、Kubeflowパイプラインだ。それはKubeflowのエクステンションで、KubeflowはKubernetesをベースとするオープンソースの機械学習用フレームワークだ。パイプラインは要するにコンテナ化されたビルディングブロックのことで、機械学習のエコシステムに属する人たちを連係させて機械学習のワークフローを作り、管理する。

そうやってモデルをコンテナに入れたら、その後データサイエンティストは必要に応じてその中のモデルを単純に調整し、継続的デリバリのようなやり方で再ローンチできる。Shethによると、これによって企業内のモデルの利用の可能性がさらに広がる。

“Kubeflowパイプラインはユーザーに、いろんなパイプラインで実験する方法を提供し、信頼性があって再現可能な環境の中で最良の結果を作りだすものはどれか、を決められる”、とShethは、この新しい機械学習機能を発表するブログ記事に書いている。

同じく今日発表されたAI Hubは、その名のとおり、データサイエンティストがそこでいろんなMLコンテンツを見つけられる場所だ。そこには、KubeflowパイプラインやJupyterノートブック、TensorFlowモジュールなどなどがあるだろう。それは一種の公開リポジトリになり、Google Cloud AIやGoogle ResearchなどGoogleのさまざまなチームが素材を提供し、研究開発に関わるGoogleの専門的知識技能をデータサイエンティストが利用できる場になる。

しかしGoogleはこのハブに、公開ライブラリ以上のものを求めている。同社の見方では、そこはチームが自分たちの企業内で情報をプライベートに共有できる場にもなって、二重の目的に奉仕する。これによって、重要なビルディングブロックが中央的なリポジトリで可利用になるから、モデルの利用の拡大に大きく貢献するだろう。

AI Hubは今日からアルファで利用でき、Googleからの初期的コンポーネントの一部や、内部的リソースを共有するためのツールが提供される。そして今後は徐々に、提供物と能力の拡大が定常的に行われる予定だ。

Googleによると、これによってモデルが汎用のビルディングブロックになり、それによりモデルを容易に共有できる方法が提供され、モデルがさまざまに実用される機会が増えるだろう。これらのツールは、それを達成するための第一歩だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Google Cloudがマネージドcronサービスを提供、自分でcronするより楽？

Google Cloudに、バッチジョブを動かすためのマネージドcronサービスが登場する。そのサービスはCloud Schedulerと呼ばれ、たぶんあなたが悪戦苦闘することもあるコマンドラインの標準コマンドcronの、すべての機能を提供するが、クラウドで動かすマネージドサービスとしての信頼性と使いやすさも兼備している。

Cloud Schedulerのジョブのターゲットは、すべてのHTTP/SエンドポイントとGoogle自身のCloud Pub/Subトピック、そしてApp Engineのアプリケーションだ。デベロッパーはこれらのジョブを、Google Cloud ConsoleのUIやコマンドラインインタフェイス、あるいはAPIから管理できる。

GoogleのプロダクトマネージャーVinod Ramachandranが、今日（米国時間11/6）の発表声明でこう説明している: “cronのようなジョブスケジューラーはどんなデベロッパーの道具箱の中でも主役級の存在で、タスクのスケジューリングやシステムメンテナンスの自動化を助けている。しかしジョブスケジューラーにも、そのほかの従来的なITサービスと同じ課題がある。つまりインフラを自分で管理しなければならないし、失敗したジョブはいちいちマニュアル（手作業）でリスタートしなければならない、そして、ジョブのステータスを目で見ることができない”。

Ramachandranの説明によると、今まだベータのCloud Schedulerは、ジョブをターゲットに確実にデリバリすることを保証する。重要なジョブは確実に始動し、ジョブをAppEngineやPub/Subに送るとサクセスコードやエラーコードが返される。そして同社が強調するのは、何かがおかしくなったらCloud Schedulerに容易にリスタートさせられることだ。

もちろんこのコンセプトはGoogleが初めてではない。同様のサービスを提供しているスタートアップも数社あるし、またGoogleのコンペティターであるMicrosoftにも、同様のサービスがある。

料金は、1か月に3ジョブまでは無料、その先は1ジョブごとに月額10セントだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Cockroach Labsが複数のクラウドにまたがるデータベースCockroachDBのマネージドサービスを開始

Cockroach LabのオープンソースのSQLデータベースCockroachDBは、昨年の立ち上げ以来徐々に伸びているが、しかしオープンソースの技術が成熟して市場により深く浸透するためには、アーリーアダプターを超えたもっと一般的なオーディエンスに採用されていく必要がある。そのために同社は今日（米国時間10/30）、CockroachDBのマネージドサービスを発表した。

このサービスはクラウドを特定しないが、手始めとしてAmazon Web ServicesとGoogle Cloud Platformで利用できる。2015年にローンチしたCockroachはつねに自分を、Oracleや、さらにAmazonのAuroraデータベースなどをも代替する現代的なクラウドデータベースと位置づけている。

CEOのSpencer Kimballによると、それらの先輩データベースたちは、ベンダーロックインが強すぎて彼の趣味ではない。それに対抗するオープンなデータベースとして立ち上げたのが、Cockroachだ。“Cockroachのクラスターは、クラウドAからクラウドBへダウンタイムなしで移行できる”、と彼は言う。

そのような柔軟性は、他のベンダーが提供しているものと比べて、大きなアドバンテージがある、と彼は信じている。そして今日の発表は、そのアドバンテージをさらに大きくする。データベースと関連インフラストラクチャのセットアップや管理という重い仕事を、これからはサービスとしてのCockroachDBが代わってやってくれる。

Kimballの認識では、このやり方により同社の市場も拡大するだろう。“これまでにもOracleやAWS Aurora、Cassandraからのマイグレーションが相当あったが、これからは、それをためらっていたような企業もManaged CockroachDBにより容易にマイグレーションできるから、うちの市場はより快調に大きくなるだろう”、という趣旨をKimballは声明文で述べている。

そのデータベース本体には、自己回復力の強さというアドバンテージもある。いろんな条件下で安定的に動くから、これまでのデータベースに比べて有利だ、という。大きなアップタイムをレプリケーションによって保証し、ひとつのインスタンスがダウンしたら、すぐに身代わりが動き出す。

これまではエンタープライズ向けの商用バージョンが収益源で、それは通常のオープンソース版にないバックアップやサポートなどのサービスを提供していた。しかしこれからは、“Datbase as a Service”の契約会費収入が主な収益源になる。

1年前に同社は、CockroachDBのバージョン1.0をリリースし、シリーズBで2700万ドルを調達した。そのラウンドはRedpoinがリードし、Benchmark, GV, Index Ventures, そしてFirstMarkが参加した。そのお金が有効に使われた結果、今日発表のマネージドサービスが完成したのだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Googleの開発プラットホームFirebaseのサミットがチェコのプラハで開催、エンタープライズ指向を強調

今日（米国時間10/29）プラハで行われたFirebase SummitでGoogleは、そのアプリケーション*開発プラットホームFirebaseのさまざまなアップデートを発表した。それにより同社は、同プラットホームを、個人や小さなチームのための環境であるだけでなく、本格的なエンタープライズ開発ツールにも仕立てようとしている。〔*: 開発プラットホーム; 主にWebアプリケーションとモバイルアプリが対象。参考記事。〕

Googleは4年前にFirebaseを買収して、デベロッパーがそのSDKを使って重要なクラウドツール…データベースやストレージなど…に容易に接続できるようにした。その後同社は、その上に、モニタリングなどの高度な機能を加え、パフォーマンスの問題を解決し、アプリのユーザーのエンゲージメントを知るためのアナリティクスを加えたりしてきた。でも、これまでのそれらツールキットは、必ずしも大企業を視野に入れたものではなかった。

Firebaseのプロダクト担当Francis Maが、こう語る: “今日の発表は主に、モバイルアプリの構築と成長を志向しているエンタープライズと高度なアプリチームのための、機能とアップデートが中心だ”。

たぶん今日の最大のニュースは、企業対象のサポートが加わったことだろう。毎月150万のアプリおよびアプリケーションがFirebase上で作られているというが、しかしエンタープライズに深く入り込むためには、企業のITが問題にぶつかったとき電話できるところが必要だ。そのため同社は年内に、各種のサポートパッケージをベータで発表する予定だ。それらが、さらに幅広いGoogle Cloud Platformのサポートと組み合わさる形になる。

“すでにGCPの有償サポートを受けているユーザーは、そのGoogle Cloud Platform(GCP) Support ConsoleからFirebase関連の質問に答えてもらえる。またGCPのサポートパッケージには、ターゲットのレスポンスタイムや、専用のテクニカルアカウントマネージャー（Enterprise Supportの場合）などが含まれている。Firebaseのサポートに関して、別料金は発生しない”、とMaはGoogle Cloudとの一体性をブログ記事で強調している。

また、大きなチームや企業はさまざまな管理ツールを必要とするので、Googleは今日、Firebase Management APIを発表した。これによりIDEからFirebaseへの、プロジェクトのワークフローを、プログラムにより管理できるようになる。Maによると、これにはWebベースのIDE、StackBlitzとGlitchの統合も含まれている。“これらのプラットホームがFirebaseでアプリが作られていることを自動的に検出し、ボタンひとつでそれをFirebase Hostingへデプロイできるようにする。彼らのプラットホームを去る必要はない”、とMaは書いている。

そのほか、5月に発表されたGoogle　MLキットの顔認識ツールへのアクセスの改良をはじめ、たくさんの発表があった。パフォーマンスモニタリングツールCrashlyticsが改良されて、PagerDutyの統合が行われた。アナリティクスツールFirebase Predictionsは、ベータを卒業して一般公開された。

これらの発表はすべて、Firebaseプラットホームの成熟を示すと同時に、単なるデベロッパーツールから、エンタープライズも視野に収めたツールへの機能拡張を、はっきりとねらっている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

DropboxがコラボツールPaperにタイムラインを加えてプランニングツールとしても使えるように

Dropboxはその、ドキュメント・コラボレーション・ツールPaperを、2015年の発表以来一貫して、多機能化してきた。今日（米国時間10/25）加わったのはタイムライン機能で、これにより単純なコラボレーションだけでなく、Paperを軽量級のプロジェクトプランニングツールとしても使えるようになる。

Dropboxの顧客は前から、Paperに計画立案機能がほしい、と要望を寄せていた。この新しい機能を発表する同社のブログ記事は、こう述べている: “プランニングには、さまざまな可動部品を調整する面倒な作業があります。今回Dropbox Paperでは、新しいタイムライン機能により、その苦痛を取り除きます”。

そういうツールに誰もが期待するように、タイムラインを作ってその上にマイルストーン（スケジュール項目）を置いていくが、土台がPaperなので各マイルストーンをチームメンバーに割り当てることができる。いろんな情報のノートも付記できるが、それには関連ドキュメントのリンクがあってもよい。

タスクを割り当てられた人のためのトゥドゥリストをタイムラインに埋め込んで、その仕事の無事完了を補佐できる。それが、プロジェクトを割り当てられた全員のための単一のアクセスポイントになる。

Gif画像提供: Dropbox

発表のブログ記事にはこうある: “トゥドゥや@mentionや締め切り（予定日）などによってチームメンバーはお互いが容易にプロジェクトを調整できる。しかも、この一歩進んだタイムライン機能では、チームメンバーの誰もが、いつ・何が・誰の担当で起きるかということを、明確に視覚化できる”。

Dropboxが最近理解しているのは、ストレージツールが単なるストレージツールでは仕事の役に立たない、ということだ。だからコラボレーションやコーディネーションに手を広げて行かざるをえない。Dropbox Paperは、まさにそのためにある。タイムラインが加わると、その多機能化がまた一歩前進する。

Constellation Researchで“仕事の未来”を研究しているAlan LepofskyはPaperについて、コラボレーションツールの変化の兆候、と言う: “こういう新種のコンテンツクリエーションツールは、いわばデジタルのキャンバスのようなものだ。複数のソースからのコンテンツを統合する作業を、単純化してくれる。ワードプロセッサの進化形、と言えるかもしれない”。

プロジェクトマネージャーのもっと完全なプランニングツールを今日明日にもリプレースするわけではないが、少なくとも、Dropboxのユーザーがそこに保存したコンテンツからさらなる価値を作り出せるためのツール、とは言えるだろう。

画像クレジット: Dropbox

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Googleの作成アクションによりGmailの中でいろんなSaaSアプリケーションを利用できる

最近Googleは、メールを送るときの省エネ省時間化に励んでいる。たとえばスマートレスポンス機能は、定型的な返事なら既製品で間に合わせようとする。先行入力(type ahead)機能は人間が文字をタイプする前にコンピューターが先回りしてその文字を入力する（意外と正確だ）。そして今日から一般公開で立ち上げたのが、作成アクション(compose actions)*と呼ばれる省時間機能だ。〔*: ‘作成’は、メールの‘作成’(compose)の意味。〕

それはG Suiteに導入される一種のコネクターで、メールの作成をしながらその中でほかのSaaS（Box, Dropbox, Egnyte, Atlassian Jiraなどなど）にリンクできる。ソフトウェア企業はよく、ほかのアプリケーションに切り替えなくても、自分のアプリケーションで仕事を続けながら、その中でほかのアプリケーションも使えることを強調するが、それと同じことを作成アクションはねらっている。

GmailとChatのプロダクトマネージャーAakash Sahneyが、ブログにこう書いている: “作成アクションにより、Gmailの中でメールを作成しながら、添付ファイルや参考データをどこかのクラウド上から加えたり、お気に入りのサードパーティアプリでこれから作るコンテンツで、メールを楽しくすることなどが容易にできるようになる”。

サービスへの接続はG Suiteの中でGmail Add-onツールを使って行なう。Gmailのワークフローの中にサードパーティ製のツールを簡単に統合できるために、GoogleはGmail Add-onを作った。目的のツールをアドオンとして認可したら、それがメールの作成ウィンドウにオプションとして現れる。それをクリックすればGmailから出ずにそのツールを使える。G Suiteのアドミンが、それらのアプリ/アプリケーションを、限定することもできる。

たとえば、BoxやDropbox、Egnyteなどのファイルやフォルダーを取り入れたいときは、そのアプリを認可してから、メールの作成ウィンドウに表示される作成アクションをクリックしてサービスにアクセスし、ファイルを利用する（下図）。

Gif画像提供: Google

Atlassianを統合すると、プロジェクトのファイルを直接、メールに挿入できる（下図）。

Gif画像提供: Google

それほどすごい機能ではないかもしれないが、これによって節約されるキータイプの量や操作の回数は、一日の作業量としては相当なものだ。目的のサービスとコンテンツを別ウィンドウで開くのではなく、メールの中で目的のコンテンツそのものをメールにコピペできたりするのだ。作成アクションをクリックしてGmailから直接、そのサービスにアクセスして。

作成アクションは、7月にGoogle CloudのNextカンファレンスで発表された。G Suiteのユーザーは、それを今日（米国時間10/18）から利用できる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

MITで開発されたメモリ分割方式により未来のMeltdown/Spectreバグを防げる

今年、研究者たちがIntel, AMD, そしてARMのチップに、設計上の根本的な弱点を見つけたときには、今の世代のコンピューターのプロセッサーのほとんどすべてに対し、極刑が求刑されたようだった。その設計ミスによって、コンピューターのメモリーから機密データを盗むことが可能だからだ。

そのMeltdownおよびSpectreと呼ばれる脆弱性は1995年まで遡（さかのぼ）り、アプリケーションがシステムのメモリーの、自分にパーミッションのない部分にアクセスできないようにしている壁に穴を開けた。それにより有能なハッカーは、パスワードや暗号鍵などの機密データが保存されている場所を見つけることができる。多くの企業がその欠陥の一部を緩和してきたが、真の長期的な解決は、コンピューターのプロセッサーの設計の最初からのやり直しであることも知っていた。

このたび、MITのComputer Science and Artificial Intelligence Laboratory(CSAIL)の研究者たちが、将来にわたって、MeltdownやSpectreのような欠陥を防止できる方法を見つけた。

アプリケーションが何かをメモリーに保存したくなったら、置くべき場所をプロセッサーに尋ねる。しかしメモリーの探索は遅いので、プロセッサーは“speculative execution”（投機実行）と呼ばれるトリックを使って、複数のタスクを同時に動かし、正しい空きメモリーを探そうとする。しかし悪質なハッカーは、その同じテクニックを使って、アプリケーションが自分に許されていない場所のメモリーから読めるようにする。

MITのCSAILによると、彼らのテクニックはメモリーを分割することによって、データが同じ場所に保存されないようにする。それを彼らは、“secure way partitioning.”（安全な方法によるパーティショニング）と呼んでいる。

彼らはこの方式をDAWG、“Dynamically Allocated Way Guard”（ガードを動的に割り当てる方法）と名付け、それは滑稽な名前のようにも聞こえるが、IntelのCache Allocation Technology, CAT（キャッシュ割り当て技術）を補完する意味を持つ。彼らの研究論文によると、DAWGはCATと同じような仕事をし、使うにあたってデバイスのオペレーティングシステムの変更箇所も少ない。したがって、Meltdownのフィックスとして問題のコンピューターにインストールするのも容易である。

ペーパーの著者の一人Vladimir Kirianskyによると、このテクニックは“共有が起きるべきところと、起きるべきでないところとの、明確な境界を確立し、機密情報を扱うプログラムがそのデータをまあまあ安全に保てるようにする”。

この技術は通常のコンピューターを保護するだけでなく、クラウドの脆弱なインフラストラクチャも保護できる。

DAWGはすべての投機的攻撃を防げるわけではないが、今研究者たちは技術の改良に取り組んでおり、すべての攻撃ではないものの、これまでよりも多くの攻撃を防げるようになる、と言っている。

しかし彼らの技術を実際にIntelなどのチップメーカーが採用すれば、DAWGのようなテクニックは“パブリッククラウドのインフラストラクチャに対する信頼を再興し、ハードウェアとソフトウェアの共同設計によりパフォーマンスのオーバヘッドも最小化できる”、という。

Kernel panic! What are Meltdown and Spectre, the bugs affecting nearly every computer and device?

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

サーバーレスのインフラをモニタするEpsagonがステルスを脱して正式ローンチ

イスラエルのEpsagonが今日（米国時間10/17）ローンチしたサーバーレス開発のためのツールは、そのインフラストラクチャのモニタリングを支援する。それが、どこにある何かをデベロッパーが知らなくても。

デベロッパーがインフラのことを知らないのは、サーバーレスの本質でもある。サーバーのリソースは短時日で変わることもある。デベロッパーは一連のイベントトリガーを作り、クラウドのベンダーが必要なサーバーのリソースを動かす。このやり方の美点は、プログラマーがインフラストラクチャのことを気にせずにコードを書けることだ。でも欠点は、オペレーションにとってインフラストラクチャをコントロールしたり理解する方法がないことだ。

Epsagonはこの問題を、サーバーレスのアーキテクチャを見える化することによって解決する。CEOで協同ファウンダーのNitzan Shapiraはこう語る：“うちがやることを一言で言えば、サーバーレスのための分散トレーシングと観察性とコストのモニタリングだ。これまではこそこそとやってきたけど、今日からは会社を正式にローンチする”。

サーバーレスではエージェントを使えない。それをどこへ置けばよいか、分からないからだ。それを置くための固定的なサーバーはない。だから、従来的なログツールも使えない。Epsagonはこの問題を、ライブラリを使うエージェントレスの方式で迂回する。Shapriaによると、同社はそのライブラリをオープンソース化して、それらをデベロッパーにとってより魅力的にしたいと考えている。

同社が最初にサポートするのはAWS Lambdaだが、来年はそのほかのクラウドプラットホームもサポートする予定だ。EpsagonにサインアップしたらAWSの認証情報を入力する。するとただちに、パフォーマンスに関する情報をEpsagonのダッシュボードに表示し始める。ただしShapiraによると、本当の価値はライブラリにある。“このライブラリこそが、うちの道具箱だ。つまり、エージェントと同じ働きをする”、と彼は言う。

スクリーンショット提供: Epsagon

提供するものは、従来的なモニタリングデータだけではない。顧客が費消している費用も分かる。サーバーレスでは、クラウド企業が必要に応じてリソースを提供するが、それゆえにユーザー側のコスト管理が難しい。Epsagonは、今実際にどれだけ使っているかを見せてくれる。

Epsagonの利用料金はまだ確定していないが、最初はセルフサービス方式を採用している。同社のWebサイトにサインアップすると、無料から始まっていろんな料金オプションが並んでいる。いずれも、最初の2週間は無料の試用期間だ。

テルアビブに拠を置くEpsagonは、現在の社員数が11名、営業とマーケティングとサポートの体制ができたら、アメリカにオフィスを持ちたい。同社は1月に、Lightspeed Venture Partnersがリードするラウンドで400万ドルを調達した。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Google CloudがCloud NAT、Firewall Rules Loggingなどネットワーキング機能を充実

今日（米国時間10/10）は、ロンドンでNextイベントを開催しているGoogle Cloudからのニュースで、忙しい日だった。このイベントで同社は、いくつかの新しいネットワーキング機能をローンチした。それらの中でも今日の主役はCloud NAT、これによりデベロッパーは、一般的に公開されるIPアドレスがなくて、企業の仮想プライベートクラウドの中にあるアプリケーションからのみアクセスできる、クラウドベースのサービスを容易に構築できる。

Googleも言うように、このようなセットアップは前から可能だったが、しかし容易ではなかった。でも、よくあるユースケースなのでGoogleは、Cloud NATにより、ネットワークアドレス翻訳(network address translation, NAT)のすべてを取り扱う完全に管理されたサービスを提供することになった。そしてCloud NATのゲートウェイの背後にあるプライベートなインスタンスへのアクセスを、デベロッパーに提供する。

Cloud NATはGoogle Compute Engineの仮想マシンと、Google Kubernetes Engineのコンテナをサポートし、デベロッパーが手作業でIPを指定できるマニュアルモードと、IPが自動的に割り当てられるオートマチックモードの両方を提供する。

今日は新たに、Firewall Rules Loggingがベータでリリースされた。アドミンはこの機能を利用してファイヤーウォールのルールの効果を監査し確認できる。たとえば、ファイヤーウォールがブロックする接続の試みが何度も繰り返されるときには、それらを分析して、誰かが良からぬことをしようとしているのか、それともファイヤーウォールの構成ミスかを判断できる。データの遅れは5秒程度なので、ほとんどリアルタイムに近い点検が可能だ。また、これをほかのサービス、Stackdriver Logging, Cloud Pub/Sub, BigQueryなどと統合してアラートやデータ分析もできる。

さらに今日の発表の中には、HTTPSロードバランサー用に証明を提供するマネージドTLSがある。これは、ロードバランサーを使っているときのTLS証明の管理に伴う煩雑さを解消することが目的で、これによりエンドユーザーのブラウザーがデベロッパーのアプリケーションに安全に接続できるようになる。この機能も、現在はベータだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Dropboxにユーザーのすべての画像とPDFを自動的にOCRする機能が登場

Enterprise Dropboxに、一部のユーザーが待ち焦がれていたと思われる便利な機能がやってきた。それは画像やPDFファイル中の文字を自動的にテキストデータへ書き起こす光学式文字認識(optical character recognition/reader, OCR)機能だ。これからは、セーブした写真をかき回してレシートを探さなくてもよいし、目的の情報を探してたくさんのファイルを開かなくてもよい。単純に、テキストで検索できるのだ。

Dropboxのテキスト認識エンジンは今後数か月で、DropboxのPro, Business Advanced, そしてEnterpriseアカウントに実装されるが、アーリーアクセスがあるかもしれないから、ときどきチェックしてみよう。

このOCR機能は、ユーザーのすべての画像やPDFをスキャンしてテキストを取り出し、それらをメタデータに加えるので、ユーザーはそれを検索できる。もちろんそのデータは、正規のドキュメントとして安全に保存される。便利だが、問題は書き起こしの精度だ。OCRはときどき、気難しいからね。

Dropboxに永久につきまとう、もっと簡潔な名前のコンペティターBoxは昨年、多機能なOCRを導入した。多機能というのは、文字だけでなくオブジェクト（物）も認識するからだ。これに比べてDropboxのは、機能的にやや劣るかもしれないが、でも日常のOCRニーズには十分だろう。

これまで、指定したドキュメントをOCRすることはできたが、もちろんこっちの方が便利だ。Dropboxの技術情報のブログには、この自動化OCR機能の開発史が語られている。Boxは、GoogleのOCR機能を下敷きにしたらしい。〔訳注: Google Drive -> Google DocsにもOCRがある（全自動ではない）。〕

Dropbox Enterpriseのようなグループアカウントのメンバーは、全員がこの機能を利用でき、しかもこの機能が有効になったときは自動的に、既存のドキュメントもすべてOCRされる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

GitHubがJira Software Cloudの統合を改良、パフォーマンスとユーザー体験をアップ

AtlassianのJiraは、多くの企業で、大きなソフトウェアプロジェクトを管理するためのスタンダードになっている。しかしそれらの企業の多くがソースコードのリポジトリとしてはGitHubを利用しており、JiraとGitHubを統合する公式な方法も、かなり前からある。しかしその古いやり方は、遅くて、能力も限られ、今多くの企業がGitHubで管理しているような大きなコードベースを扱うには、向いていないことが多かった。

しかしMicrosoftに買収されたあとでもGitHubは、オープンソースのエコシステムにコミットしていることを証明するかのように、今日（米国時間10/4）同社は、二つの製品の改良された統合を発表した。

GitHubのエコシステムエンジニアリング担当ディレクターKyle Daigleは、こう語る: “Jiraに関してAtlassianと協働することは、われわれにとってきわめて重要だった。われわれの顧客であるデベロッパーには、彼らが使っているこのオープンなプラットホーム〔GitHub〕から最良の体験を確実に得てほしいからだ。彼らが今、ほかにどんなツールを使っていようともね”。

そこで二か月前にGitHubのチームは、Jiraとの独自の統合を、完全にゼロから再構築することに決めた。そして今後は、それをメンテナンスし改良していくことにした。Daigleが言ってるように、改良の重点はパフォーマンスとユーザー体験の向上に置かれた。

この新しい統合により、JiraのIssue（課題）に結びついているすべてのプルリクエストやコミット、ブランチなどをGitHubから容易に見ることができる。GitHubからの情報に基づいてIssuesを検索できる。そしてまた、開発ワークのステータスをJiraの中でも見ることができる。GitHubで行った変更がJiraのアップデートもトリガーするので、そのデータはどんなときでもアップツーデートに保たれる。

いわゆるJira DVCSコネクターを利用するJiraとの古い統合は非推奨になり、GitHubは、数週間以内にアップグレードするよう、既存のユーザーへの告知を開始する。新しい統合はGitHubのアプリケーションなので、このプラットホームのセキュリティ機能をすべて装備している。

画像クレジット: TechCrunch

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Cloudflareが低価格のドメイン登録サービスをローンチ、セキュリティ機能満載で

Cloudflareにとっては、多忙な週だった。同社は誕生日の週にさまざまなニュースを約束し、そしてそのニュースを配達した。昨日（米国時間9/26）はBandwidth Allianceを発表し、今日（米国時間9/27）はCloudflare Registrarを発表した。この新しいドメイン登録サービスは、トップレベルのドメイン登録所（Verisignなど）が課金するホールセール料金しか課金しない、と約束している。ふつう、登録サービスはその上に独自の料金を課金し、ホスティングのプランやそのほかの不必要なサービスを抱き合わせで売ろうとする。

CloudflareのCEOで協同ファウンダーのMatthew Princeはしかし、この新サービスはロスリーダーではない、と言う: “Cloudflareの顧客はみな、自分のドメインを登録する必要がある。それなのに、既存のドメイン登録サービスに満足している顧客は一人もいない。だから、世界で初めての、誰もが好きになるドメイン登録所（レジストラ）を作りたいのだ”。

このサービスの展開は、Cloudflareの顧客歴の長いところからスタートする。Cloudflareは8年前にTechCrunch Disruptでローンチしたが、そのときユーザー登録した人は早めにできるだろう。でもCloudflareは、Girls Who Codeに寄付をしたら順番が早くなる、と言っている: “われわれの今度のサービスで得をするぶんを、Girls Who Codeに寄付するといいね”。

Cloudflareのサービスだから当然、この新サービスにも、二要素認証の内蔵、ドメインロックの自動化、などのセキュリティ機能がある。Whoisのプライバシー保護もある。

これらのことをすでに知ってる読者は、たぶんCloudflareエンタープライズレジストラをご存知なのだろう。それは同社の、大企業向けのドメイン登録とドメイン保護サービスだ。

〔関連記事: CloudflareのワンクリックDNSSECセットアップ（未訳）〕

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Chefの標準ツールと最新ツールがMicrosoft Azureへ深く統合、安心のマイグレーションを担保

DevOpsオートメーションサービスChefが今日（米国時間9/25）、Microsoft Azureとの新しい統合をいくつか発表した。その発表は、フロリダ州オーランドで行われているMicrosoft Igniteカンファレンスで行われ、企業がレガシーアプリケーションをAzureへ移行する際の支援に焦点が絞られた。それに伴い、Chef Automate Managed Service for Azureのパブリックプレビューや、ChefのコンプライアンスプロダクトInSpecをMicrosoftのクラウドプラットホームに統合する例などが提示された。

Azure上のマネージドサービスとなるChef Automateは、コンプライアンスとインフラの構成の、管理とモニタリングを単一のツールでできる能力をopsのチームに与え、またデベロッパーは、Chef AutomateとChef ServerをAzure Portalから容易にデプロイし管理できる。それは完全なマネージドサービスであり、初めてのユーザー企業でも30分で使えるようになる、と同社は主張している。この数字には、やや宣伝臭があるかもしれないが。

構成を変えるときにはAzure上のChefユーザーは、AzureのコマンドラインインタフェイスであるAzure Cloud ShellでChef Workstationを使える。WorkstationはChefの最新の製品のひとつで、構成の変更を即席でできる。また、Chefが管理していないノードでも、対応できる。

コンプライアンス堅持のために、ChefはセキュリティとコンプライアンスツールInSpecのAzureとの統合をローンチした。InSpecは、MicrosoftのAzure Policy Guest Configuration（誰だ？こんな名前をつけたやつは！）と協働し、それによりユーザーはAzure上のすべてのアプリケーションを自動的に監査できる。

Chefのプロダクト担当SVP Corey Scobieはこう語る: “Chefは企業に、彼らが確信を持ってMicrosoft Azureに移行できるためのツールを提供する。ユーザーは単純に自分たちの問題をクラウドへそっくり移すのではなく、状態や状況をよく理解したうえで移行を行なう。事前に構成やセキュリティの問題を検出できるから、移行後の成功が確実になり、正しい、そして着実なペースで、移行できる実力を企業に与える”。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

GoogleのCloud Memorystore for Redisが一般公開、ミリ秒以下のレスポンスを約束

Googleは今日（米国時間9/19）、5か月の公開ベータを経たCloud Memorystore for Redisを一般公開した。それは、完全な管理を伴うインメモリのデータストアだ。

このサービスはRedisプロトコルに完全に準拠していて、インメモリのキャッシングを必要とするアプリケーションにミリ秒以下のレスポンスを約束する。そしてRedis準拠なので、デベロッパーは自分のアプリケーションをコードをどこも変えずにこのサービスへマイグレートできる。

Cloud Memorystoreには二つのサービスティアがある。シンプルなキャッシング用のベーシックと、高可用性のRedisインスタンスを必要とするユーザーのためのスタンダードだ。スタンダードではGoogleは、99.9%可用性のSLAを提供している。

最初にベータでローンチして以来Googleは、このサービスにできることを徐々に増やしてきた。たとえば今ではさまざまな性能数値をStackdriverで見ることができる。また、カスタムのIAMロールや、改良されたログ機能も加わった。

課金は時間と容量の従量制で、サービスのレベルや使用するキャパシティによって異なる。完全な料金表がここにある。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

GoogleのGitHub競合製品Cloud Source Repositoriesが検索機能を大きく改良

Googleが今日（米国時間9/19）、最近再び立ち上げたGitベースのソースコードリポジトリ Cloud Source Repositoriesのアップデートを発表し、とくに検索機能が大幅に改良された。この新しい検索機能はGoogleの技術者たちが毎日使っているツールをベースとし、今日からCloud Source Repositoriesのベータリリースで提供される。

かなり前からインターネットを使っている人なら、Google Code Searchをご存知だろう。これを使ってインターネット上のオープンソースのコードなら何でも検索できたが、残念ながら2012年に閉鎖された。今度の新しい機能はそれの復活ではなくて、自分の（もしくは会社の同僚の）コードしか検索できない。でもそれはGoogle自身の検索に劣らず高速で、正規表現などの高度な検索機能もある。

またJava, JavaScript, Go, C++, Python, TypeScript, Protoで書かれたコードに対しては、検索で見つかったものがクラスか、メソッドか、列挙型か、フィールドか、というタイプ情報も返す。

Googleは、コードの検索をローカルにやるのは、古いコードも検索されてしまうので良くない、と主張している。

さらにGoogleによると、GitHubや（Atlassianの）BitbucketにあるコードをCloud Source Repositoriesにミラーできる。検索だけのために、そんなことをするデベロッパーがたくさんいるとは思えないが、でもGoogleにとってはユーザー獲得の手段になるだろう。この世界はGitHubの独壇場だから、何もしなければ単なる負け犬になってしまう。

Cloud Source RepositoriesのプロダクトマネージャーRussell Wolfが、今日の発表声明で書いている: “重要な利点は、ユーザーのすべてのリポジトリをCloud Source Repositoriesにミラーないし加えておくと、一回のクエリーでそれらすべてを検索できることだ。それは、小さなウィークエンドプロジェクトでもよいし、Googleのような巨大なコードベースでもよい。しかもそれは速い。一瞬で答が得られ、前の検索機能に比べると大違いだ。そのため、検索でコーディングが中断しない。インデクシングも、超速い。新しいコードを加えたらすぐにそれが検索対象になり、つねに最新の検索ができる”。

画像クレジット: TechCrunch

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Googleが日本で複数のAI関連事業を立ち上げ、UNIQLOとパートナーシップ

Googleが今日（米国時間9/18）東京で行われたCloud Next 2018イベントの場を利用して、日本市場にフォーカスした二つのイニシアチブを発表したのは、当然のことだ。このイベントはメインのカンファレンスがサンフランシスコで行われ、複数の国際的イベントが東京など各地で行われる。

発表には、ベーシックなアップデートとしていくつかの日本語ローカライゼーションも含まれ、その中には、CourseraのコースMachine Learning with TensorFlow on Google Cloud Platformの日本語化や、クラウド技術者の資格検定Associate Cloud Engineerの日本語化、50種のクラウド実践演習（各30分）Qwiklabsの日本語化などがある〔日本語化の例はここで〕。

さらにGoogleは、東京にAdvanced Solutions Labを立ち上げる。同様のラボは、アイルランドのダブリンとカリフォルニアのサニーベール、そしてニューヨークにもある。それらはGoogleのエキスパートたちによる4週間の機械学習教育訓練コースを軸として、機械学習のさまざまな学習オプションとコラボレーションによる演習経験を提供する。

(写真: Hitoshi Yamada/NurPhoto via Getty Images)

Googleは今日、新しいテクノロジーの採用をめぐって、ユニクロの親会社Fast Retailingとのパートナーシップを発表した。社名が示すように同社は小売業の高速化に関心があり、成長の加速化のためにGoogleのG Suiteや機械学習ツールを利用していきたいようだ。このパートナーシップ事業の名前は、’Ariake’である。

Fast RetailingのCEO Tadashi Yanaiはこう言っている: “全社員が情報にアクセスできるようにすることが、Ariakeプロジェクトの基盤のひとつだ。それによって社員たちは、論理や判断、共感といった人間の特性を生かした意思決定ができるようになる。毎シーズン、事業計画を書いているが、G Suiteのような共同作業ツールを使えば、それらを全社員が共有できる。Google Cloudとのパートナーシップは、需要予測のようなものをとっくに超えて、全社員の協働的な仕事のやり方を抜本的に変えた”。

画像クレジット: Tomohiro Ohsumi / Getty Images

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

NvidiaがローンチしたTesla T4は最速のデータセンター用推論プラットホームだ

Nvidiaが今日（米国時間9/1）、データセンターにおける機械学習と推論のための新しいGPUを発表した。そのTesla T4 GPUs（TはNvidiaの新しいアーキテクチャTuringを指す）は、クラウドコンピューティングのメジャーなプロバイダーのほとんどが現在提供しているP4 GPUsの後継機種だ。Nvidiaによると、GoogleはT4 GPUsをクラウドプラットホームで採用する最初の企業のひとつだ。

Nvidiaによると、T4はP4よりも相当に速い。たとえば言語の推論では、T4はCPUを使うよりも34倍速く、P4より3.5倍速い。T4のピーク時性能は4ビットの整数演算で260TOPS、浮動小数点演算で65TOPSだ。T4は、標準的な75ワットのLow Profile PCI-eカードに載っている。〔関連記事〕

しかしもっとも重要なのは、Nvidiaがこれらのチップを、AIの推論専用に設計したことだ。NvidiaのVPで同社のTeslaデータセンター事業部のGM Ian Buckはこう語る: “Tesla T4が推論用としてこれほど効率的なGPUであるのは、Turingアーキテクチャの新しいテンソル・コアのせいだ。CEOのJensen Huangがすでに述べたように、そのTensorコアはゲームやレンダリングやAIにも有効に利用できるが、設計の前提は推論だ。トータルでこのチップには、320のTuting Tensorコアと2560のCUDAコアがある”。

Nvidiaは今回、新しいチップのほかに、同社のソフトウェアTensorRTの、ディープラーニングのモデルを最適化するアップデートをローンチした。この新しいバージョンには、TensorRT推論サーバーも含まれており、それはデータセンターの推論のための完全にコンテナ化されたマイクロサービスとして、既存のKubernetesインフラストラクチャにシームレスに接続する。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Atlassianがopsチームのためのインシデント管理ツールJira Opsをベータでローンチ

Atlassianが今日（米国時間9/3）、同社の旗艦製品であるJiraの新しいエディションの最初のベータと、opsのチームがインシデントを迅速効率的に処理できるための問題追跡ツールを発表した。

そのツールJira Opsは、OpsGenie, PagerDuty, xMatters, Statuspage, Slackなど他のツールをいろいろ統合している。多くのチームがすでに、自分たちのサービスがダウンするとこれらのツールを使っているが、Atlassianによると、現状では、その場しのぎ的な使われ方が多い。Jira Opsは、同じページ上の全員をまとめる糊になり、現在進行中のインシデントを可視化することをねらっている。

AtlassianがJiraを使って、その中核的なオーディエンスであるデベロッパーから逸れた方向へ脇道するのは、これが初めてではない。たとえばJira Service DeskとJira Coreは、もっと広いオーディエンスを対象としている。しかしOpsは、きわめて限定された層が対象だ。

Atlassianでソフトウェアのチームを率いるJens Schumacherはこう述べる: “Service Deskが、最初の一歩だった。そして、Jiraで対応できるそのほかの特定層を、探していた”。Schumacherによると、同社は社内のopsチームのためにこれまでたくさんのツールを作ってきたが、それらは主に、インシデントを追跡し管理するために必要な、いろんなピースを糊のようにまとめることが目的だった。Jira Opsはそんな糊的ツールを、正規のプロダクトにしたものだ。

しかし、Jira Opsを使うことはある意味で、パズルのピースがまた一つ増えることだ。でもSchumacherの主張では、プロセスを管理する単一の場所を作ることがねらいだった。“インシデントが起きたら、そのインシデントに関係のあるものをすべて見つけられる、センター的な場所へ行けばよい、…それがねらいだ”、と彼は語る。“そのページに誰がいて、誰がアラートされているかが分かる。必要と思えば、さらにもっと多くの人にアラートできる。Slackのどのチャネルでそのインシデントが議論されているか、も分かる”。

Atlassianの他のプロダクトと違うのは、Jira Opsのセルフホスティングバージョンを出す計画は今のところないことだ。その理由は、単純明快だ: ユーザーのインフラがダウンしたら、Jira Opsもダウンするかもしれない。…そうなると、そのダウンタイムを管理するツールがない。

Jira Opsは今、アーリーアクセスのベータとして無料で利用できる。バージョン1.0の立ち上げは、2019年の初期の予定だ。もちろんそのときには、料金体系も明確になっているだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）