機械学習のモデルのデプロイを標準化するツールGraphpipeをOracleがオープンソース化

オープンソースのコミュニティと仲が良いとは必ずしも言えないOracleが今日、Graphpipeと呼ばれる新しいオープンソースのツールをリリースした。それは、機械学習のモデルのデプロイを単純化し標準化するツールだ。

そのツールは、ライブラリの集合と、スタンダードに従うためのツールを合わせたものだ。

このプロジェクトは、NASAでOpenStackの開発に関わり、その後2011年にOpenStackのスタートアップNebulaの創業に加わったVish Abramsがリードした。彼によると、彼のチームが機械学習のワークフローを手がけたとき、あるギャップに気づいた。一般的に機械学習のチームはモデルの開発には大量のエネルギーを注ぎ込むが、そのモデルを顧客が使えるようにデプロイすることが苦手だ。そのことが、Graphpipe誕生のきっかけになった。

彼曰く、機械学習のような新しい技術は、誇大宣伝に踊らされてしまう部分がある。開発プロセスは改良を続けていても、デプロイに頭が向かわない人が多い。

“Graphpipeは、機械学習のモデルのデプロイを改良する努力の中から生まれた。また、この機械学習の分野全体を改良するためには、デプロイのためのオープンなスタンダードがぜひ必要だ、と考えた”、そうAbramsは語る。

これがOracleのプロジェクトになったとき、彼らは三つの問題に気づいた。まず最初に、機械学習のAPIをサーブするための標準的な方法がない。各フレームワークが提供しているものを、そのまま使うしかない。次に、デプロイのメカニズムにもスタンダードがないので、デベロッパーは毎度カスタムでそれを作らなければならない。そして第三に、既存の方法はパフォーマンスの向上に真剣に取り組んでいない。パフォーマンスが、‘ついでの問題’でしかない。機械学習にとっては、それは重大な問題だ。

“Graphpipeを作ったのは、これら三つの課題を解決するためだ。それは、ネットワーク上でテンソルデータを送信するための標準的でパフォーマンスの高いスタンダードを提供する。またどんなフレームワークを使っても、機械学習のモデルのデプロイとクエリーが簡単にできるための、クライアントとサーバーのシンプルな実装も作った”、…AbramsはGraphpipeのリリースを発表するブログ記事で、そう書いている。

同社は、これをスタンダードとしてオープンソースにすることによって、機械学習のモデルのデプロイを前進させたい、と決意した。“Graphpipeは、ビジネスの問題解決と、技術の高度化の推進という、二つの方向性が交差するところに座っている。そしてそれを進めていくためのベストの方法が、オープンソース化だと考えている。何かを標準化しようとするとき、それをオープンソースで進めなかったら、最終的にはいろんな競合技術の混乱状態になってしまう”、と彼は語る。

Oracleとオープンソースのコミュニティの間には長年の緊張があることをAbramsも認めるが、最近ではKuberenetesや、オープンソースのサーバーレス・ファンクション・プラットホームOracle FNへのコントリビューションなどを通じて、そんなイメージを変える努力をしてきた。そして彼によると究極的には、技術が十分におもしろいものであれば、誰がそれを提出したかとは関係なく、人びとはそれにチャンスを与えるだろう。そしてそのまわりにコミュニティができれば、オープンソースのプロジェクトとして自然に適応されたり、変えられたりしていく。それを、Abramsは望んでいる。

“このスタンダードが、今後幅広く採用されてほしい。実装は誰がやっても易しいから、Oracle独自の実装を広めたいとは思わない。人気の実装は、そのうちコミュニティが決めるだろう”。

GraphpipeはOracleのGitHubアカウントのGraphpipeのページで入手できる。

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

FIDOアライアンスおよびW3C、「パスワード」無用の仕組みを提案

「パスワード」という仕組みは、非常に脆弱だ。極端にいってしまえば、セキュリティ対策としては「意味のない」仕組みであるということに、多くの人が同意してくれることだろう。しかし、われわれは依然としてパスワードに頼りきって生活している。パスワードは、覚えておく利用者自身にも負担になるだけでなく、盗むのも難しくなく、重要な場面で役に立たないものなのだ。そのような中、FIDOとW3Cが、WebAuthnというウェブ閲覧時のパスワードを不要とするプロトコルを開発している。

Google、Mozilla、およびMicrosoftも、仕様が定まった段階で本プロトコルの採用を表明している。セキュリティキーやスマートフォンなどの外部デバイスを利用して認証処理を行うようになっている。このプロトコルでは、認証を必要とするウェブサイトと、BluetoothやUSB、あるいはNFCなどを通じて直接通信を行うことにより、利用者の介入をなくす仕組みになっている。これによりフィッシングなどの可能性を0にできるとうたっている。

そう、新しい仕組みに移行することで、数週間毎に新しくする、20文字程度のセキュリティ神への捧げもの(パスワード)から開放されるだけでなく、流行のセキュリティリスクをなくすこともできるわけだ。パスワードを入力しない以上、フィッシングや介入者攻撃(man-in-the-middle attack)などにより、セキュリティ情報を奪われる可能性もなくなる。認証のためのトークンは必要なときにのみ生成されることとなり、それ以外のときには必要なくなるのだ。

WebAuthnの仕様は、ユースケースについても詳しく説明している。たとえば、ノートパソコンを利用して認証を要するウェブサイトにアクセスする場合についても記述されている。この場合、IDとパスワードを入力する従来の方法に変わり、スマートフォンを利用して認証を行うようになっている。利用者は、スマートフォンに表示されるメッセージに応答するだけで、パスワードなどの入力は無用となるのだ。

FIDO Allianceのエグゼクティブ・ディレクターであるBrett McDowellも、新たな仕組みのメリットを語っている。すなわち、情報漏えいや信用情報の盗用が行われる中、パスワードないしワンタイムパスワードなどという脆弱なシステムに頼るのをやめることを目的としているとのこと。ウェブやアプリケーションで、新たな認証システムを採用することにより、これまでに比べてはるかに安全な認証システムを実現できるのだとのことだ。

ただし、今のところはWebAuthnもファイナル段階に至っていない。しかし勧告候補(Candidate Recommendation:CR)段階となっている。すなわち、最終段階の直前にまで達しているというわけだ。

もちろん、どんなセキュリティ対策にも「完ぺき」はないだろう。新しいプロトコルに対しても、欠陥を突く仕組みが登場してくるのは時間の問題なのだろう。しかし、パスワードを排除しようとする流れ自体は正しいものだと思われる。多くの人が、パスワードという仕組みからの脱出を狙ってきたわけだが、WebAuthnはその流れの中から出てきたシステムなのだ。

原文へ

(翻訳:Maeda, H

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))

コンテナ化という大きな趨勢にとってはスタンダードがきわめて重要、AWSは自らその意思を示す

AWSが今日(米国時間8/9)、コンテナの標準化団体Cloud Native Computing Foundation(CNCF)の正会員になったとき、同社の重要なマイルストーンが刻まれた。GoogleやIBM, Microsoft, Red Hatなど、この分野の有力企業の仲間入りをすることによって、コンテナの管理に関してはスタンダードを無視できないことを、認めたのだ。

なにしろ、これまでもっぱら我が道を行くだったAWSである。しかもAWSは今や、その強力な巨体で広大なマーケットシェアを支配しているから、さまざまな面で自分流を貫いても平気だ。しかし、コンテナは違った。今コンテナを支配しているのは、かつてGoogleで生まれたオープンソースのコンテナ管理ツールKubernetesだ。

聡明なAWSは、Kubernetesが業界標準になりつつあることと、作るか買うかオープンソースで行くかの三択に関しては、戦いがすでに終わっていること、とっくに結論が出ていることを悟った。

コンテナ管理におけるGoogleの優勢を認めたからには、次の論理的ステップはCNCFに加わり、業界全体が使っている同じコンテナの規格に従うことだ。人生には戦うよりも自分を変えた方が得策なこともあり、これがまさに、その典型的な例だ。

そしてAWSがCNCFに加わったことによって、業界全体としてのコンテナ化に向かう路程が明確になった。今それは、とくに大企業において大きなブームになっている技術だが、それには十分な理由がある。アプリケーションをいくつもの離散的な塊に分割して構築していくので、メンテナンスとアップデートがきわめて容易である。そしてDevOpsのモデルにおいて、デベロッパーのタスクとオペレーションのタスクを明確に分離できる。

いくつかのスタンダードが、コンテナを開発し管理するための共通基盤を提供している。その上で各人が、独自のツールを作ることもできる。GoogleのKubernetesも、最初はそのひとつだったし、Red HatのOpenShiftやMicrosoftのAzure Container Serviceなども、そんな独自ツールの例だ。

しかしスタンダードがあると、誰が何を作っても、その構造や動作の共通性をあてにできるし、したがってその利用も楽だ。どのベンダーもサービスのベースはほぼ同じであり、違いは上位的な機能や構造にのみ現れる。

業界の大半がスタンダードに合意すると、その技術は離陸していく。World Wide Webは、その偉大なる例だ。それは、Webサイトを作るスタンダードな方法だから、完全な共通技術へと離陸できた。ビルディングブロックに関して多くの企業が合意したら、そのあとはすべてがうまく行く。

スタンダードの欠如が、技術の足を引っ張った例も少なくない。全員が共通のビルディングブロック(構築部材)を持つことは、きわめて有意義なのだ。しかしときには、だんとつのマーケットリーダーが合意に参加しないこともある。今日のAWSは、そんなリーダーにとってもスタンダードが重要であるという認識を、示したのだ。

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

SMSを使った二要素認証を非推奨〜禁止へ、米国立技術規格研究所NISTの新ガイダンス案

nix-2fa

二要素認証(2-factor authentication, 2FA)は優れものだから、それを標準的機能として採用するサービスが増えている。しかし二要素認証のいちばん多い実装方法のひとつであるSMSを、NISTは除(の)け者にしようとしている。

NISTは計測や測定に関する全国共通のガイドラインや規則を作るお役所だが、当然ながらその関連技術分野は多く、セキュアな電子的通信に関連する技術にも、目を配っている。

このお役所が近く発表する二つの公式声明は、認証やセキュリティに関連するさまざまな推奨をアップデートし、またそれらのドキュメントを公開意見聴取(public preview)にさらす。つまり声明の内容は推奨の変更に関する公開草案だから、意見に対しては、NIST自身からの公式の応答を要する。

しかしNISTは、それがお役所仕事になるのを防ぐために、草案に対する意見やコメントを述べる新たな場としてGitHubを選んだ。それについて、“すでに関連コミュニティが集まってコラボレーションしている場にわれわれも参加することは、きわめて妥当である”、と説明している

ただしその公開意見聴取は、テキスト本体に質問や意見を書き込むという、ちょっとひどいやり方だ。すでに、“これじゃあ難しすぎるよ”、という内部者のコメントが記入されている。

いずれにしても、変更箇所はものすごく多い。でも、われわれ平均的アメリカ人にとっていちばん重要なのはたぶん、これからは“帯域外認証の手段(out of band authenticator, OOB)”としてSMSを使うな、というくだりだろう。2FAのための使い捨てコードの送付に、SMSを使うな、というのだ。

公共的移動(モバイル)電話ネットワーク上でSMSメッセージを使って帯域外確認を行うのなら、確認者は、その電話番号が実際にモバイルネットワークに結びついていること、VoIP(などのソフトウェアサービス)に結びついていないことを、確認しなければならない。それから確認者は、SMSメッセージをその既登録の電話番号へ送る。その既登録の電話番号の変更は、変更時に二要素認証を不能にしないかぎり、不可能である。そこで、SMSを用いるOOBを非推奨とする。またこのガイダンスの今後のリリースにおいては、不許可とする。

当面は、電話番号が仮想番号でないかぎり、SMSの利用は続けられるが、通信内容の露見や変造の危険性は、SMSの場合とても大きい。NISTは今は黙っているが、みんながコメントを書き込む期間が終われば、もっといろんなことを言うだろう。でも、上の太字の部分が明確に示しているように、SMSメッセージの利用は遠からず、“良からぬ行い”と見なされることになる。

代わりに、2FAの専用アプリケーション、Google AuthenticatorやRSA SecurIDなどを使うか、ドングルを使用するセキュリティサービスを利用するとよいだろう。SMSが使えなくなっても、代わりの選択肢はたくさんある。SMSは、簡単、だけがメリットだった。

NISTの変更提案の、そのほかの主なものは、以下のとおり:

  • LOAを構成部品のそれとする〔製品の全長とはしない〕
  • アイデンティティ証明を完全に改訂する
  • パスワードに関するガイダンスを完全に更新する
  • トークンなどセキュアでない認証手段を廃止する
  • フェデレーション〔複数サービス連合、≒SSO〕を要件とし推奨する
  • バイオメトリクスの適用対象を拡大
  • プライバシーの要件(作成中)
  • 有用性に関する検討事項(作成中)

さてみなさまは、ドキュメントそのものを見た方がよいかもしれない。リンクは序文の冒頭にある。コメントしたい人は、GitHubのイシュートラッカーを使おう。その詳細はここにある

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

標準化はエンタープライズソフトウェアに秩序をもたらす

16929503420_2fcbcb983f_k

今週、Hilton at Torrey Pinesで行われたCloud Identity Summitの会場をさまよって、はっきりしたことが一つある。企業の規模が大きくなるとあらゆる物事が複雑化し、その複雑化に対抗する一つの方法は標準を制定することである。

実際、カンファレンスを横断する永続的テーマは、このアイデンティティー(個人認証)に関わるあらゆる物事を行うための標準的方法が必要だということだった。それは業界がOAuth等の一連の標準によって解決しようとしている問題だ。OAuthは、Twitter等の識別情報を使って他のサービスに容易にサインインできるシステムだ。

他にも様々な略語からなるサービスが山ほどあり、私はGoogleで調べるのに多くの時間を費した。

ID管理の第一人者、Ping IdentityのCEO、Andre Durandはこれらの標準を、あらゆる会社がアイデンティティ事業を構築できるプラットフォームだと考えている。もし、みんなが基本的方法に同意すれば、彼の会社のように、その標準の上に作ったもので差別化することができる。実際オープンなプラットフォームは、業界発展における証明された方法である。

Salesforceのアイデンティティー担当シニアディレクター、Ian Glazerは、ユーモラスだが当を得たキーノート講演でこう言った。標準を守らないことは、有毒廃棄物をたれ流しているのと同じだ。そんなやり方で運営する者は自らの顧客がよほど嫌いに違いない、とも彼は言った。

最終的に、同じルールとライブラリーに基づいて運営することが誰にとっても理にかなっている。その結果、企業は永遠に車輪を再発明し続ける― あるいは何十種類もの車輪を使う ― という顧客にもデベロッパーにもカオス的な状態を避けることができる。

「大企業ユーザーは、アイデンティー標準が自分たちの展開あるいは利用するサービスの自然な一部になることを望むだろう」とGlazerは言った。そうした標準を実装しようとすることに対して何人も料金を請求すべきではない、むしろその逆だ。「悪い習慣をサポートし続けることに対して料金を課すべきだ」と彼は言った。

アイデンティティーに関して言えば、アプリ毎に新たなパスワード検問を設置できないのは明らかだ。誰にとっても維持困難な状況だからだ。そこで登場するのが連合アイデンティー、デジタルパスポートを持って国境を越えるように、個人がアイデンティティーを持ち歩く概念だ。

「境界には防衛上の役割がある」とDurandは言い、しかしサミットのメインテーマを繰り返してこう言った、「アイデンティティーはボーダーレスだ」。

「アイデンティティーは新しい境界、この概念はあらゆる分野に適用できる」と彼は言った。

これまで見てきたように、標準化はアイデンティーだけでなくあらゆる業界に秩序をもたらし、その秩序は概して良い結果を招く。Identerati ― Pingはゲストたちをこう呼ぶ ― はそれを知っている。これはあらゆる業界が学ぶべきことだ。

[原文へ]

(翻訳:Nob Takahashi / facebook

WebCLでWebデベロッパもGPUやCPUのマルチコアをブラウザ内で有効利用(==並列処理)できるようになる

Webブラウザは多くの場合、コンピュータやモバイルデバイスの能力をフルに利用できない。コードがハードウェアから抽象化されたサンドボックスで実行されることが多く、ブラウザが直接ハードウェアにアクセスすることはない。デスクトップ用のソフトウェアはたとえばCPUのすべてのコアを使い、また現代的なGPUに並列処理をさせて画像のフィルタリングなどを高速化できるが、ブラウザ内で動くJavaScriptのコードにはそれができない。でも、それがもうすぐ変わる。

WebGLやOpenGL、COLLADAなどの標準規格を作っている業界団体Khronos Groupが今日(米国時間3/19)、WebCL 1.0の規格の最終決定と一般公開リリースを発表した。WebCLはOpenCLのブラウザバージョンで、Webブラウザの中からGPUやマルチコアを利用する方法をWebデベロッパに与える。

WebCLのベースであるOpenCL(Open Computing Language)は、同様の能力をデスクトップで提供する。

WebCL作業部会の議長Neil Trevett(Khronosの理事長でNVIDIAのモバイルコンテンツ担当VP)によると、ブラウザのベンダがこの規格を採用すると、デベロッパはこれらの能力を利用してWebGLゲームのための物理演算エンジンや、リアルタイムのビデオ編集ツール、視野像全体(vision)の処理、高度なフィルタのある写真編集ツールなどを、ブラウザ上に実装できるようになる。

基本的に、複数のコードを並列に動かす必要のあるアプリケーションを、ブラウザ内で動かせるようになる。規格そのものはアプリケーションを特定しないが、あえて分かりやすく言えば、ゲームや画像処理がこれらの能力を利用するアプリケーションの筆頭だ。

そういうアプリケーションにとっての障害がブラウザに存在しなくなるので、これまで往々にしてブラウザのせいにされていたパフォーマンスのペナルティも、なくなる。

ChromeのNative Clientやプラグインのようなものを使わずに、ブラウザ内でWebアプリケーションをネイティブかつ高速に動かしたいと思うと、今のところFirefox上のJavaScriptスーパーセットasm.jsぐらいしか方法がない。しかし、ネイティブに近い速度を誇るasm.jsも並列処理はサポートしていないから、高速化にも限界がある。Trevettによると、asm.jsとWebCLの関係は排他的というよりむしろ相補的であり、WebCLのJavaScript結合(バインディング)も提供されるので、デベロッパはいつでも、asm.jsベースのアプリケーションからWebCLを呼び出すことができる。

下の(やや古い)Samsungのビデオを見ると、WebCLにできることがよく分かる:

WebCLはOpenCLとほとんど同じなので、お互いのあいだのコードのポートも容易だ。

ハードウェアを直接操作するコードが増えると、新しいセキュリティの問題も現れる。そこでWebCLのチームは、OpenCLにある機能の一部をあえて不採用にしている。Web上では、それらのセキュリティが保証できないからだ。このプロセスの一環としてチームは、オープンソースのカーネルバリデータ(カーネル検査ツール)を開発し、それが逆に、OpenCLチームのセキュリティ強化につながった、という。

WebCLはデベロッパに対して新しい可能性の世界を開き、これまでは実装困難だった種類のアプリケーションをWebに持ち込めるようになる。しかしそれと同時に、これまでWeb専門でやってきたデベロッパにとっては、未知の世界が開けることになる。Trevettによると、今WebGLのエコシステムが、グラフィクスエンジンの高度な専門家たちが作った比較的使いやすいフレームワーク主導型になっているように、今度は並列処理のエキスパートたちがWebCLのために同様のことをしてくれるだろう。どちらも、低レベルの複雑な細部から、デベロッパを解放してくれるのだ。

WebCLを完全にサポートしたブラウザがいつ登場するか、それはまだ未知数だが、2011年から始まったWebCL作業部会には業界の主だった企業のほとんど…Adobe、AMD、Nvidia、ARM、Intel、Opera Software、Mozilla、Google、Samsung、Qualcomm…が参加している。そしてNokiaはすでにFirefox用のWebCLエクステンションを提供しているから、実際に試してみたい人はそれを利用するとよいだろう。

画像クレジット: Nvidia

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