Googleのセマンティック体験(Semantic Experiences)でAIと言葉遊びをしよう

Googleは自然言語の処理や合成で大量の研究開発をしているが、それらはアシスタント機能や音声認識/合成だけが目的ではない。その中には、AIの機能でできる範囲内での楽しいものもあり、そして今日(米国時間4/13)同社は、Webの閲覧者が言葉の連想システムで遊べる実験を発表した。

最初の実験は、膨大すぎて言及される機会も少ない本のデータベースGoogle Booksの、おもしろい検索方法だ。それは、言葉そのものでテキストやタイトルを探すのではなく、データベースに質問をする。たとえば、“なぜナポレオンは流刑になったのか?”(Why was Napoleon exiled?)とか、“意識の本質は何か?”(What is the nature of consciousness?)など。

すると、その質問の言葉と密接に結びついている文節が返される。結果はヒットもあれば空振りもあるが、でも良くできているし、柔軟性もある。ぼくの質問に答えるセンテンスは、必ずしもキーワードに直接関連していないし、とくにそれら〔物理的な言葉そのもの〕を探した結果でもない。

でも、それが人間と知識の内容が対話するとても分かりやすい方法か、というと、それは違うようだ。質問をするのは、答が欲しいからであり、質問と関係があったりなかったりするいろんな、互いに相反するような、引用を見たいのではない。だからぼくがこれを日常的に使うとは思えないけど、ここで使われているセマンティックエンジンの柔軟性を示す、おもしろいやり方ではある。しかもそれによって、今まで自分が知らなかった著作家に触れることができるが、ただし、データベースの収蔵書籍数は10万もあるから、当然、結果は玉石混交だ。

Googleが紹介している二つめの実験プロジェクトは、Semantrisというゲームだ。“なんとかトリス”というゲームは昔からどれも難しいが、これは超簡単だ。言葉のリストが表示されて、一つが高輝度になっている(下図)。それと関連があると思われる言葉〔連想した言葉〕をタイプすると、GoogleのAIが、関連性の強いと思う順に言葉を並べ替える。ターゲットの言葉を下に移動すると、一部の言葉が爆発して、新たな言葉がいくつか加わる。

これは、暇つぶしには良いかもしれないが、やってるうちに自分が、Googleの連想エージェントの訓練に使われるモルモットになったような気がしてくる。遊び方は、とてもやさしい。でも、水(water)からボート(boat)を連想しても、誰もすごいとは思わないね。でも、やってるうちに、だんだん難しくなるのかもしれない。ユーザーの応答がAIの訓練用データとして使われるのか、今Googleに問い合わせている。

プログラマーや機械学習のマニアのためには、Googleは訓練済みのTensorFlowモジュールをいくつか提供している。そしてそのドキュメンテーションは、このブログ記事の中のリンク先の二つのペーパーにある。

〔訳注: Googleはセマンティック検索の実現を目指して、これまで多くの企業〜スタートアップの買収を繰り返している。〕

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

AppleがMacの32ビットアプリケーションのサポート終了の警告を開始する

明日の太平洋時間午前0時に、AppleはあなたがMacOS 10.13.4で32ビットのアプリケーションを開くと警告の表示を開始する。それは一つのアプリケーションにつき一回かぎりの警告で、MacOSの64ビットへの完全移行をねらっている。日程は未定だが、最終的には32ビットのサポートを終了するから、アップデートしなかったアプリケーションは動かなくなる。

ただしそれは明日ではないが、Appleは警告メッセージがユーザーとデベロッパーの足元に火をつけて、その日が来る前にアップデートすることを望んでいる。そのヘルプページには、こう書かれている: “あなたが購入するアプリケーションが、それらがその上で動くMacと同じく進んだものであるようにするために、Macの将来のソフトウェアはすべて、最終的には64ビットであることを必要とする”。

それは同社がモバイルでiOS 11について行った移行と同じだが、デスクトップの場合はやや面倒だ。まず、同社のデスクトップオペレーティングシステムはiOSよりずっと前からある。さらに、AppleにはMacOSのApp Storeがあるけれども、他のチャネルからダウンロードされるデスクトップアプリケーションは依然として多い。

同社も言っているように、この移行には長い時間を要した。その開始は10年ぐらい前のデスクトップPower Mac G5からだから、それは決して、Appleがデベロッパーに対して前の晩に急に言い出したことではない。もちろんその間あなたも歳をとり、サポートされないソフトウェアが増えていくと、それらの命が終わることによって、あなたの生産性はガタ落ちになるだろう。そんなユーザーには、OS 9からOS Xへの移行にも、移行に伴う厄介事が必ずあるだろう。

警告を無視してご自分でSystem Reportボタンをクリックしてもよい。まだアップデートされてないアプリケーション(Audacity、きみのことだよ)に関しては、デベロッパーに直接頼むことをAppleは勧めている。

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

FargateによってAWSはコンテナをもっとクラウドネイティブにしたい(Kubernetesなどのインフラを完全抽象化)

AWSのデベロッパーカンファレンスre:Inventは、たくさんの発表があるので、同社自身の重要な新製品の、影が薄くなってしまうこともある。同社の待望のElastic Container Service for Kubernetesはかなり大きく報道されたが、より斬新なコンテナサービスであるFargateローンチは今もまだ、あまり知られていない。

今週たまたま会う機会があったAmazonのCTOでAWS担当VP(そしてEDMの熱心なファン) Werner Vogelsも、それを認める。彼曰く、“Fargateはそのほかの発表の下に埋もれてしまったようだ。しかしそれは、コンテナをもっとクラウドネイティブにするための重要なステップだと思うし、すでにかなりの数の顧客がFargateを採用している。”

Fargateは、AWSのコンテナサービス、Elastic Container Service(ECS)やElastic Kubernetes Service(EKS)のために、コンテナを動かすためのインフラストラクチャを抽象化する技術だ。ユーザーはコンテナオーケストレーションエンジンを指定するだけで、あとのことはこのサービスがやってくれる。個々のサーバーやクラスターをユーザーが管理する必要はない。むしろユーザーは単純に、ECSやEKSに、Fargateでコンテナをローンチすると告げ、そのアプリケーションのCPUとメモリの要求を定義し、あとはサービスにまかせる。

Fargateに関する長いブログ記事を今日(米国時間4/11)発表したVogelsにとってこのサービスは、デベロッパーが、インフラを気にせずに自分のアプリケーションだけに集中できるようにするというAWSのミッションの一環だ。彼曰く“クラウドの初期のころを、よく思い出す。AWSが登場するまでは、クラウドから仮想マシンを提供するサービスしかなかったんだ。多くの企業がそれを利用してビジネスを築き成功させてきたが、でも仮想マシンを動かすときには、依然としてハードウェアを管理しなければならない。[…] われわれがAWSのクラウドコンピューティングサービスの中核であるECSをかつて導入したときに起きたことの一つは、いろんなものをハードウェアから切り離してしまったことだ。[…]それによってデベロッパーの生産性は、ものすごく上がったと思うね”。

しかしAWSやECSの上でコンテナを動かそうとすると、初期のコンテナツールでは、コンテナを実際に動かすこととは無関係な多くのことを、やらなければならなかった。“それは、クラウドの初期と同じだ”、とVogelsは語る。“仮想マシンがコンテナにとってのハードウェアになってしまっている。デベロッパーはコンテナのオーケストレーションのために、VMを相手に大量の作業をしなければならない”。

しかしAmazonの顧客が求めるのは単純に自分のコンテナを動かすことだけだ。Vogelsの言う“ハードウェアに直接触(さわ)るような管理作業”なんか、やりたくない。“それはまるで、クラウド以前の時代に戻ったみたいだ”、とVogelsは述べ、そして今日のブログ記事では、“コンテナのオーケストレーションは、あまりクラウドネイティブではない、といつも感じていた”、と言っている。

Vogelsは、インフラストラクチャを気にしなければならないならそれはクラウドネイティブではない、と考えているようだ。彼によると、AWSの最初の約束は、インフラストラクチャに関してはAWSが面倒見るからデベロッパーはビジネスにとって重要なことだけに専念すればよい、というものだった。その哲学をさらに徹底したサービスがFargateであり、Lambdaだろう。

ECSやEKSのようなクラウドサービスがあっても、クラスターはまだ完全に自動的に動くわけではなくて、つねに必要とはしない能力や容量でも、ユーザー自身が確保(プロビジョニング)しなければならない。Fargateの約束は、そのようなスケーリングを自動化し、ユーザーは実際に必要とする能力と容量だけに支払えばよい、という状態にすることだ。

Vogelsはこう言う: “顧客は、ソフトウェアを作りたいだけだし、自分のアプリケーションを作りたいだけだ。このコンテナをどの仮想マシンに置くか、なんてことで悩みたくはない。でも今は、デベロッパーがそれをやっている。Fargateがあれば、ユーザーはタスクに対するCPUのタイプを指定するだけで、スケーリングは自動的に行われる。実際に使う能力容量に対してだけ、支払えばよいのだ”。

インフラの抽象化という点では、Fargateはコンテナのためにそれをやるのだが、AWS Lambdaのようなプロダクトはもっと徹底している。それは Vogelsにとってはひとつの連続体であり、顧客の要望が生んだものだ。今のAWSはコンテナをきわめて重視しているが、彼の現実的な見方によれば、近未来がコンテナ一色に塗りつぶされてしまうわけではなくて、VMを必要とする開発ニーズも残る、VMはなくならない、という。

Lambdaのようなサーバーレスのプロダクトでは、インフラストラクチャのことをまったく考える必要がない。コンテナのことすらも。ユーザーはただ単に、やりたい処理を指定するだけだ。そしてそのコードの実行に対して支払う。しかもVogelsの視界の中では、VMとコンテナとサーバーレスは一つの連続体の各部だ。顧客は、そのどれからどれへ移行してもよい。彼によると、今ではコンテナを完全に飛び越えて、何もかもサーバーレスで行くエンタープライズも見かけるようになった、という。

〔関連記事: 昨年のre:InventにおけるFargateの発表

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

GoogleとNetflixがオープンソースのカナリア分析ツールを共同開発、プロダクションレベルの問題発掘を目指す

【抄訳】
GoogleとNetflixが今日(米国時間4/10)、Netflixが内製したカナリア分析ツールを一般公開することになるオープンソースのプロジェクトKayentaのローンチを発表した。Kayentaは、Netflixで育った継続的デリバリのプラットホームSpinnakerに統合されており、それはパブリックかプライベートかを問わずほとんどすべてのクラウドで使える。今回のリリースはSpinnakerにフォーカスがあるが、しかしKayentaはそのほかの環境にも適応させられる。

カナリア分析は、概念としては単純明快である。その名前が示しているように、サービスやインフラストラクチャを展開またはアップデートしたときの大きな問題を防ぐための早期警戒システムだ。展開やアップデートの対象をユーザーやサーバーやネットワークの一部に絞って行うテスト的実施で、カナリア分析は新しいシステムの振る舞いが正しいこと、あるいは前と変わらないことをチェックする。各ステップでシステムはチェックを実行し、その展開やアップデートが、通常のテストでは問題ないが、もっと複雑なプロダクションシステムに投じられたときにも問題が生じないことを、それら各ステップで確証していく。

GoogleのプロダクトマネージャーAndrew Phillipsによると、すでにそれをやっているデベロッパーは多いけれども、しかしそれはしばしば、非公式に行われている。チームがアプリケーションをビルドすると、いくつかのサーバーにデプロイしてみて数分動かし、ダッシュボードに異状が出ていないかチェックする。そんなやり方は人的エラーにつながりやすいし、偏りもありうる。それに対してカナリア分析ツールは、いくつかの測度の値を求めて、そのコードの完成度を客観的に判定する。コードのテストは多くの企業が自動化しているが、その種のテストではコードをプロダクションに投じたときに起きる問題を捉えられないことが多い。とくにそのプロダクション環境がマイクロサービスの集合から成り、それらが予期せざる対話をし始めたような場合には、お手上げとなる。

【後略】
〔以下、技術的な話題よりも、G社N社共同開発の経緯が中心。〕

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

学費不要で完全な技術者を育てるHolbertonが$8Mを調達して学生数を増やす

ここ数年でHolberton School of Witchcraft and Wizardry Engineeringはもっと総合的なプログラミングスクールとして知られるようになった。二年の教程で完全なエンジニアを育てようとする同校は、今では大学の専門学部の課程と比べて遜色ないと見なされている。今日(米国時間4/9)、サンフランシスコに拠を構える同校は、今後の拡張を支えるシリーズA、820万ドルの資金調達を発表した

そのラウンドは現在の投資家daphniTrinity Venturesがリードした。そして、Omidyar Networkが新たな投資家として参加した。これで同校の資金調達総額は、1300万ドルになる。

Holbertonは現在、約200名の学生を教えている(厳しい入学試験がある)が、それを今後1000名に増やす計画だ。最近同じサンフランシスコ市内で移った大きなスペースは、500名の収容能力がある。アメリカのいちばん大きな大学等でも、コンピューターサイエンスの学生が500名〜1000名もいるところはない。これまでの卒業生はApple, IBM, Tesla, Docker, Dropboxなどに就職している。学生が納めるべき学費はないが、就職後3年間は給与の17%を同校がいただく。

同校は、人種や性別などにとらわれず多様な学生を受け入れることをモットーにしているし、学生ローン等の負債状況も問わない。最近のクラスでは、学生の約40%が女性だ。そして、マイノリティの方がやや多い。残念ながらシリコンバレーでは未だに、こんな学校や企業は珍しい。

協同ファウンダーでCEOのJulien Barbierはこう述べる: “第一級の教育は、誰もが受ける資格がある。Holbertonの学生は、背景がきわめて多様だ。昨日までスーパーのレジをやってた子もいれば、ミュージシャンやポーカーのプレーヤー、高校を出たばかりの子に、金のない人、などなど。しかし全員が、受ける教育だけはアイヴィーリーグ(名門大学)級であるべきだ。Holbertonでは、全員に恵まれた人びとと同じ機会が与えられ、今後の全人生を投ずる価値のあるスキルを習得する。ここの学生たちは、ときにはわずか9〜12か月で、アイヴィーリーグの卒業生たちと競争して就職している。

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

GitLabがGoogleのKubernetes Engineを統合、コンテナアプリケーションのデプロイが超簡単に

今や多くの人が使っているVCSのGitを、独自にホストしているサービスとして人気の高いGitLabが、最近とくに好調だ。わずか2週間前にはGitHubとの統合を発表したが、今日はGoogleのKubernetes Engine(GKE)を統合してクラスターの展開を自動化し、ユーザーであるデベロッパーが自分のアプリケーションをほんの数クリックでデプロイできるようにした。

この機能を作るために同社はGoogleと協働したが、しかしこの統合はGitLabに前からあるAuto DevOpsツールを大々的に使っている。それは、コンテナを扱うためのよく似た機能をすでに提供していた。Auto DevOpsは、CI/CDパイプラインのセットアップやコンテナへのデプロイなど、面倒な仕事をすべて引き受けることをねらっている。

しかし、“GKEを統合する前は、GitLabのユーザーは自分のクラスターを管理するためにKubernetesの深い理解を必要とした”、とGitLabのCEO Sid Sijbrandijは今日の発表で述べている。“Googleとの協働により、われわれのユーザーはGoogle Cloud Platform上に、管理サービスを伴うデプロイ環境をセットアップし、GitLabの堅牢なAuto DevOpsの能力を利用することが簡単になった”。

このGKEの統合を利用するためには、デベロッパーはGitLabから自分のGoogleアカウントに入るだけだ。GKEがクラスターを自動的に管理するので、デベロッパーは自分のアプリケーションを書くことに集中でき、デプロイと管理はGitLabとGoogleにまかせられる。

この新しい機能はGitLab 10.6 releaseの一部として、GitLabの全ユーザーが今すでに利用できる。

〔この記事の日本語訳。〕

 

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

Google Cloudがユーザーのネットワークを最適化できるための詳細分析情報を提供

Google Cloudが今日(米国時間4/5)ローンチする新しい機能でユーザーは、Google Cloud上のユーザーのサーバー群とGoogleのそのほかのサービスやオンプレミスのデプロイメント、そしてそのほかのありとあらゆるインターネットのエンドポイントとの間のデータフローをモニタし、最適化できる。名前が示すように、そのVPC Flow Logsと呼ばれる機能は、GoogleのVirtual Private Cloud機能(仮想プライベートクラウド, VPC)を使って自分たちのリソースを他のユーザーから隔離している企業が利用する。

VPC Flow Logsは、VPC内の仮想マシンが送受するすべてのネットワークフロー(UDPとTCPの両方)をモニタしログする。それには、Google Cloudの複数のリージョン間のトラフィックも含まれる。そのデータをGoogle Cloudに保存したければ、すべてのデータをStackdriver LoggingやBigQueryへエクスポートできる。後述のように、そのほかのリアルタイムアナリティクスやセキュリティプラットホームにエクスポートするには、Cloud Pub/Subを使える。データは5秒おきにアップデートされるが、このサービスの利用がユーザーがデプロイしているアプリケーションのパフォーマンスに影響を与えないことを、Googleは約束している。

今日の発表におけるGoogleの注記によると、これによりネットワークの運用者はGoogleのネットワークのパフォーマンスを詳細に知ることができ、ネットワークのトラブルシューティングも可能になる。またユーザーのグローバルなトラフィックに関するさまざまな情報が得られるので、ネットワークの使い方や費用を最適化できるようになる。

そのデータはすべて、不審者がユーザーのネットワークに入り込んでいたときなどの捜査にも役に立つ。ただしそのためには、データを、SplunkやArcSightのようなセキュリティ情報とイベント管理(security information and event management, SIEM)の専門企業へエクスポートした方がよいだろう。

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

ケンブリッジ・アナリティカ、Facebookデータ8700万人分入手を否定…実際には3000万人

本日(米国時間4/4)Cambridge Analyticaは、同社が8700万人分のユーザーデータを不正に入手したとするFacebookの発表に反論した。実際にはDr. Aleksandr Koganの調査会社、Global Science Researchから「ライセンスを受けたデータは3000万人分以下」だと主張している。さらに、2016年の米国大統領選挙でトランプ陣営に雇われた際にこのデータは利用しておらず、Facebook から通知を受けたあと直ちに原データを削除し、派生データの削除作業を開始したことも言明した。

Cambridge Analyticaの声明全文を以下に引用した。本誌はFacebookに、2社の主張の食い違いについてコメントを求めたが拒否された。

Facebookのプライバシーポリシーと強制力の弱さは、あのCambridge Analytica騒動を引き起こし、Facebookの時価総額を1000億ドル近く下げるスキャンダルへとつながった。そんな批判にFacebookが耐え続けるなか、言った言わないの議論は今後ますます激化しそうだ。

本日(米国時間4/4)Facebookは、影響を受けた可能性のある人数は最大8700万人であり、対象になるユーザーにはニュースフィードのトップで通知すると発表した。さらに同社は利用規約を改訂して外部デベロッパーとの関係を明確化するとともに、広範囲にわたるAPI制限を発表した。これによってFacebook上に作られた数多くのアプリが動作不能に陥るが、プライバシー侵害を未然に防ぐことができる。Zuckerbergは記者団との電話会議でニュース全般について洞察を述べた

Cambridge Analyticaは、同社のデータ取扱いに関するFacebookの主張を繰り返し否定してきたが、Facebookは撤回しなかった。むしろFacebookは自らが戦おうとしている悪用の事例として、また世界中のデベロッパーを善悪を問わず取り締まることを正当化する理由として、Cambridge Analyticaを利用した。

Cambridge Analytica、GSRのデータセットに8700万件のレコードが含まれていたとする発表に反論

本日Facebookは最大8700人分の情報が調査会社GSRによって不正入手されたと発表した。Cambridge AnalyticaがGSRからライセンスしたデータは3000万人分以下であり、契約書にも明記されている。それ以上のデータは受け取っていない。

当社は2016年の米国大統領選挙で行った業務にGSRデータを使用していない。

当社がGSRと交わした契約には、すべてのデータは合法的に入手されなくてはならないと記載されており、現在この契約書は公文書扱いになっている。当社はGSRがこの契約に違反したことを知ったとき同社に対して法的措置をとった。Facebookが当社にデータが不正入手されたことを知らせてきたとき、われわれは直ちに原データをサーバーから削除し、当社のシステム内にある派生物を探して削除するプロセスを開始した。

一年前にFacebookが追加の保証を求めてきた際、当社は社内監査を実施し、全データ、全派生物および全バックアップが削除されていることを確認し、それを示す証明書をFacebookに提出した。

現在当社システム内にGSRデータが残っていないことを示すために、独立した第三者による監査を実施している。

[原文へ]

(翻訳:Nob Takahashi / facebook

AWSのストレージサービスS3にゾーンを一つしか使えない低料金バージョンが登場

AWSのストレージサービスS3が今日(米国時間4/4)、データをクラウドに保存するための、低料金なオプションを導入した。デベロッパーは、それほど頻繁にストレージにアクセスしないアプリケーションのために、高い可用性を求めないことにより、最大でS3の標準料金の20%引きで利用できる。S3のこの新しいティアの名前は、S3 One Zone-Infrequent Access(ゾーンがひとつの非頻繁アクセス)だ。

S3は、AWSが最初から提供していたサービスのひとつだ。これまで、ティアの種類が少しずつ増えてきた。S3 Standardティアは、99.999999999%の永続性と99.99%の可用性を約束しているが、S3 Standard-Infrequent Accessは、同じ永続性と99.9%の可用性を約束している。またGlacierは、コールドストレージだ。

StandardとStandard-Infrequentに保存されるデータは、三つ以上のアベイラビリティゾーンへ複製される。しかし低料金のOne Zone-Infrequent Accessティアは、名前が示すように、一つのアベイラビリティゾーンにしか保存されない。複数のマシンへ複製することはできるが、しかしそのゾーンがダウンしたり破壊されると、データにアクセスできない。

そのため、この新しい低料金ティアは可用性が99.5%で99%のSLA(アップタイム率)しか提供しない。しかしその機能や永続性は、S3のほかのティアと違いはない。

今日(米国時間4/5)サンフランシスコで行われたAWS SummitのキーノートでCTOのWerner Vogelsが言ったように、ストレージのコストは複製を行うアベイラビリティゾーンの数で決まる。彼の見解では、この新しいサービスは、頻繁にアクセスされないけど複製はできる、というデータに利用すべきだ。

99.5%の可用性は、1年に1日か2日の、データにアクセスできない日がある、という意味だ。一部のアプリケーションにとっては、それで十分だが、Vogelsの説では、顧客はこのストレージを二次的なバックアップコピーや、複製可能なメディアファイルの保存に使うだろう、と言う。

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

サーバーレスコンピューティングのモニタリングサービスStackeryが$5.5Mを調達

StackeryのファウンダーたちがまだNew Relicにいた2014年に彼らは、今後伸びてくるサーバーレス技術の市場にツールを提供していく機会がある、と考えていた。New RelicのIPOを契機に同社を去った彼らは、サーバーレスのアーキテクチャに統括と管理の層を提供する、を目標としてStackeryを創業した。

今日(米国時間4/3)同社は二つの大きな発表を行い、その最初の550万ドルの資金調達を彼らは“シード+”(プラス)と呼んでいる。第二の発表は、Health Metrics Dashboardと呼ばれるサーバーレスのパフォーマンスモニタツールだ。

まず、資金調達の話から。なぜ、シードプラスと呼ぶのか? 同社の協同ファウンダーでCEOのNathan Taggartによると、シリーズAでも良かったけど、でもまだ彼らの市場がそれほど成熟していないので、控えめな呼び方にした。“シリーズAへの欲求はあったけど、シードプラスの方が市場の現状に合っている”、と彼は述べる。今はまだ、各社がやっとサーバーレス方式の利点を理解し始めた段階だから、明らかに成長途上の市場だ。

HWVPがこのラウンドをリードし、Voyager Capital, Pipeline Capital Partners, そしてFounders’ Co-opが参加した。これにより、2016年に創業した同社の調達総額は730万ドルになった。

AWS LambdaAzure Functionsなどのサーバーレスコンピューティングという呼び名は、やや誤称だ。プログラムはサーバーが動かすのだけれども、アプリケーションのための専用のサーバーは要らない。トリガーイベントがあってそれに呼応するコードをサーバーが実行するときだけ、料金が発生する。これに先駆けてやってきたクラウドコンピューティングと同じく、デベロッパーがこれを好むのは、アプリケーションの構成やリソースの確保に大量の時間を取られずに済むからだ。

しかし、従来のクラウドコンピューティングと同じく、サーバーレスも実はクラウドサービスだ。だからこそ、デベロッパーは容易にアクセスできる。2011年に始まった“ITの消費者化”現象を思い出せば、それはクラウドサービスを容易に調達できる能力と引き換えに、組織内部のコントロールを失うことを意味していた。

クラウド初期の当時と同じく、今企業はサーバーレス技術のアドバンテージを求めるが、それと同時に、その費用や、他企業の利用状況、セキュリティ、企業のルールとのコンプライアンスなどが気になる。そこで、Stackeryのようなサービスの出番となる。

Health Metrics Dashboardと名付けられた新しいダッシュボードは、このビジョンの延長であり、モニタリングにルーツを持つファウンダーたちらしいプロダクトだ。サーバーレスはコンテナを扱うことが多く、多くのファンクションがそこにはある。何かがおかしくなったとき、その根因を見つけるのが難しい。

StackeryのHealth Metricsダッシュボード。写真提供: Stackery

そのダッシュボードは、ひとつのアーキテクチャ全域のスループットと各リソースのパフォーマンスを見せるから、デベロッパーは、どこにボトルネックがあり、パフォーマンスの問題や失敗があるか分かる。

同社は2016年に創業し、オレゴン州ポートランドに本社がある。社員は今9名で、内5名がエンジニアだ。年内には3名の増員を計画している。

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

Microsoftがオンライン学習にAI上級コースとソフトウェア開発入門を新たに加える

Microsoftが今日(米国時間4/2)、デベロッパーのためのオンライン教育プログラムに二つの新しいコースを加えた。ソフトウェア開発入門コースと、機械学習の知識を増やしたいと願っている中級以上のデベロッパーのためのAIコースだ。

誰もが知ってるように、データサイエンティストと機械学習のデベロッパーは、需要に対して供給がきわめて少ない。そのために今、多くの企業では、社員の知識と技能を高めるための社内教育に力を入れているが、今日から始まる誰でも受講できるAIコースも、最初はMicrosoftが自社の社員のために開発したコースだ。

そのMicrosoft Professional Program for Artificial IntelligenceはedX.orgで無料で受講できるが、お金を払えば修了証ももらえる。コースの期間は3か月で、各四半期の頭に始まる。当然ながら、Microsoft AzureとMicrosoftのCognitive Servicesを多く使うからAzureのアカウントは必要だが、使用するオペレーティングシステムは特定しない。

全部で10の必修クラスがあり、それらはAI入門データサイエンスのためのPythonプログラミングAIデベロッパーの倫理などさまざまだ。訓練モデルを使った実習も多い。ひとつのクラスは所要時間が8ないし16時間だ。

AIコースだけでなく、同じく今日発表されたソフトウェア開発の入門コースは、これもedXのコースで13の必修クラスから成る。とくに、JavaScriptとPythonが中心のようだ。ただしこれらのプログラミング言語を学ぶだけでなく、データ構造の基礎や、GitHubの使い方、コードをプロフェッショナルに書くためのそのほかのツールなども教わる。

こういった学習コースをいろいろ集めたものを、Microsoftは“Professional Programと呼んでいる。Microsoft Academyの方が、分かりやすいんじゃないかなぁ。今あるコースは、フロントエンドの開発、クラウドのアドミン育成、ITサポートのプロフェッショナル育成などだ。

画像クレジット: 写真提供, Dan DeLong/Microsoft

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

Microsoft Azureのアベイラビリティゾーンがやっとアベイラブルになった

どのクラウドを使う場合でも、あなたのアプリケーションの可利用性を高く維持するためには、そのアプリケーションとデータを物理的に異なる複数のリージョンに置きたいだろう。そうしないと、ひとつのリージョンがダウンするとアプリケーションもダウンする。しかし大手クラウドプラットホームはすべて、ひとつのリージョン内に‘アベイラビリティーゾーン(availability zone)’という概念を設けて、アプリケーションを同じリージョン内の二つのデータセンターでホストするオプションを提供している。すべて、と言ったが、Azureのアベイラビリティゾーンは昨年9月にベータでローンチし、今日(米国時間3/30)から一般供用される。

今日のローンチに先駆けてMicrosoftのAzure担当VP Julia Whiteは、データセンターのネットワークに関する同社の設計哲学はつねに、商用利用の顧客にできるかぎり広い圏域のリージョンを提供して、彼らの顧客との至近性を確保し、またローカルデータの独立性とプライバシーに関する法律を守ることにある、と述べた。たしかにAzureは競合他社に比べてリージョンの数が多く、今可利用なものが38、発表されているものが12ある。

“Microsoftのインフラストラクチャのアプローチはエンタープライズの組織を念頭に置いており、そのために多数のリージョンを設けている”、とWhiteは言っている。“このようなリージョンの設定は、容易でシンプルだからしているのではない。顧客が本当に望むものはこれだ、と信じているからだ”。

それぞれのアベイラビリティゾーンに独自のネットワーク接続と電力のバックアップがあり、リージョン内のひとつのゾーンがダウンしてもほかは無事だ。しかしリージョン全体に及ぶ災害はすべてのゾーンを遮断するだろうから多くの企業は、データを少なくともあとひとつの別のリージョンに保存したいだろう。

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

Google Cloudがアプリケーションパフォーマンスモニタリングのツール集を提供

Googleのクラウドプラットホームでは、社内用に作ったツールやサービスがGoogleのプロダクトとして顧客に公開提供されることが多い。今日(米国時間3/28)同社は、その一環として、Google Cloud Platformの上でアプリケーションを構築するデベロッパーにとって重要な、アプリケーションのパフォーマンス管理(application performance management)ツール集Stackdriver APMを発表した。

APMの考え方はやや変わっていて、問題の責任をオペレーションに渡すのではなく、デベロッパーがアプリケーションを調べる。つまりアプリケーションを作ったデベロッパーがコードにいちばん近いところにいるので、そこから出てくる信号もいちばんよく理解できるはずだ、とする。

StackDriver APMは、三つのツールで構成される: プロファイラーとトレース(トレーサー)とデバッガだ。トレースとデバッガはすでに利用できるが、しかしプロファイラーと併用することによって、三つのツールが協働してコードの問題を特定し、調べ、そして修復できるようになる。

Stackdriver APMを発表するブログ記事でGoogleのプロダクトマネージャーMorgan McLeanはこう書いている: “これらのツールのすべてが、どんなクラウドの上で動くコードやアプリケーションでも扱えるし、オンプレミスのインフラでも使える。つまり、アプリケーションがどこで動いていても、一貫性がありアクセス性の良いAPMのツールキットを使って、アプリケーションのパフォーマンスをモニタし、管理できる”。

ほかにStackDriverにはモニタリングとロギングのツールもあり、これら完全なAPMのスイートが、SplunkやDatadog、New Relic、AppDynamics(Ciscoが買収)などのベンダと競合することになる。しかしGoogleのプロダクト管理担当VP Sam Ramjiによると、これらのベンダは競合他社であるだけでなくパートナーでもあり、お互いのツールが協働して問題解決に取り組むことを、Googleも十分に理解している。

“しかし、コアシステムがみんなによく見えるようにする点では、うちが一番だ。人びとはこれまで使ってきたお気に入りのツールをこれからも使って、彼らの企業の事業目的という見地からプロダクションシステムを検査したり、適切なタイミングでアラートしていくだろう”、と彼は述べる。

まず最初は、プロファイラーの出番だ。これによりデベロッパーは、軽量級の(全量ではなく)サンプリングベースのツールで、アプリケーションのすべてのインスタンスからデータを収集する。

Stackdriver Profiler. 画像提供: Google

プロファイラーが集めたデータから問題を判定したプログラマーは、次にトレースを動かす。Ramjiによると、コードの問題はほとんどつねにクリティカルパスの後(あと)にあるから、このツールを使えば、問題が分散システムの全域にわたって伝搬していく様子を理解できる。トレースの画面(下図)は視覚化されたアナリティクスのような形をしていて、これらにより問題の性質と、計算資源に対するそのインパクトが分かる。

Stackdriver Traceツール。 画像提供: Google

そして最後がデバッガだ。Ramjiがこれをとくに好きなのは、若き日の90年代のツールを思い出させるからだ。当時はデバッガでアプリケーションを止めたり動かしたりしながら、問題の所在を突き止めていた。このAMPのデバッガもやはり、指定した箇所でコードを止めて、問題の核心を見つける。

ただしこの現代的なデバッガには、Ramjiが“マジック”と呼ぶものがある。デベロッパーによるコードの停止や再開が、顧客に影響を及ぼさないのだ。McLeanもこう書いている: “プログラマーにおなじみのブレークポイント方式のデバッグ処理を提供するが、それによって顧客へのネガティブなインパクトはない”。

Stackdriver APMは今日(米国時間3/28)から可利用になり、完全なサービスから成る完全なモニタリングスイートが提供される。これでGoogleは、モニタリング〜デバッグという分野でも、既存の選手たちと競争するつもりのようだ。

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

Google CloudはGoogle自身が使っているテキスト音声変換エンジンをデベロッパーに公開

テキストから音声への合成技術は近年大きく進歩し、最近のシステムは本物の人間がテキストを読んでるように聞こえるものが多い。その進歩を引っ張った企業のひとつであるGoogleは今日(米国時間3/27)、同社がAssistantやGoogle Mapsなどで今使っているのと同じ、DeepMindが開発したテキスト音声変換エンジンをデベロッパー向けに一般公開した。

そのCloud Text-to-Speechと呼ばれるサービスは、32種の声が12の言語とその変種を喋る。このサービスが生成するMP3またはWAVファイルは、ピッチや読む速度、音量などをデベロッパーがカスタマイズできる。

しかし、声の質にはむらがある。それはたとえば、英語には6種類の声があるからで、それらはすべて、テキストから生のオーディオを作るためのDeepMindのモデルWaveNetで作られている。

WaveNetはそれまでの技術と違って、短い発話の集まりから音声を合成しない。それをやると、私たちにはおなじみの、ロボットふうの話し方になってしまう。それに対してWaveNetは機械学習のモデルを使って生のオーディオのモデルを作り、より自然に聞こえる音声を合成する。Googleが行ったテストでは、WaveNetの声の方がふつうの(人間の)声よりも20%良い、という評価になった。

Googleが初めてWaveNetに言及したのは約1年前だが、その後同社は、同社自身のTensor Processing Unitsをベースとする新しいインフラストラクチャへこれらのツールを移し、オーディオ波形の生成をそれまでの1000倍速くした。だから今では1秒のオーディオの生成に50ミリ秒しかかからない。

この新しいサービスは、すべてのデベロッパーが利用できる。料金表はここにある。

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

Linux Foundationにディープラーニングのオープンソース団体が加わる

名前はLinuxでも、Linux Foundationかなり前から、Linuxのためだけの団体ではない。今ではCloud Foundry, Automotive Grade Linux Initiative, Cloud Native Computing Foundationなど、さまざまなオープンソースの財団やプロジェクトを支えている。そして今日(米国時間3/26)Linux Foundationにはさらにもうひとつの財団、LF Deep Learning Foundationのサポートが加わった

LF Deep Learning Foundationの目的は、“人工知能や機械学習、およびディープラーニングのオープンソースのイノベーションをサポートして支え、これらの重要な技術を世界中のデベロッパーとデータサイエンティストにとって可利用にすること”だ。

創設メンバーは、Amdocs, AT&T, B.Yond, Baidu, Huawei, Nokia, Tech Mahindra, Tencent, Univa, そしてZTEだ。今後、さらに増えていくであろう。

The Linux Foundationの事務局長Jim Zemlinはこう述べている: “AIや機械学習およびディープラーニングのエコシステムにおける多くのプロジェクトに長期的な戦略と支援を提供し続けることを目的とする団体をご提供できることは、きわめて喜ばしい”。

同団体の最初の公式プロジェクトはAcumos AI Projectで、これはLinux Foundationがすでにホストしている、AT&TとTech Mahindraのコラボレーションだ。Acumos AIは、AIのモデルとワークフローを開発、発見、そして共有するためのプラットホームだ。

Linux Foundationが支えるそのほかの団体と同じく、LF Deep Learning Foundationもさまざまなレベルの会員資格を支援企業に提供し、また非営利団体も会員として受け入れる。LF Deep Learningの会員は、同時にLinux Foundationの会員にもなる。

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

Googleのクラウドプラットホームではハイパフォーマンスなワークロードを容易に動かせる

AmazonやMicrosoft、Googleなどが提供している非常に大きなクラウドプラットホームは、大学や企業の科学者たちがシミュレーションや分析のために必要とするハイパフォーマンスコンピューティング(high-performance computing, HPC)のプロジェクトを十分に動かせる。なにしろ彼らに課せられる大きなワークロードも、何百何千というマシンで並列処理されるから楽勝だ。しかし、往々にしてチャレンジは、それだけ大量のクラスターをどうやって作り、それらを動かすワークロードをどうやって管理するかだ。

HPCのコミュニティがこのチャレンジを比較的楽にこなせるために、Googleは今日(米国時間3/23)、同社のクラウドプラットホームでオープンソースのHPCワークロードマネージャーSlurmをサポートする、と発表した(このSlurmではない)。それは、上位500のリストに載ってるようなスーパーコンピューターのユーザーの多くが使ってるのと同じようなソフトウェアだ。ちなみに現在最大最速のクラスターは、1000万あまりのコンピューターコアから成るSunway TaihuLightだ。

GoogleはSlurmを作っているSchedMDとチームを組んで、SlurmをGoogleのCompute Engineで簡単に動かせるようにした。この統合努力によりデベロッパーは、自分たちの仕様に基づいて動くCompute Engineで、スケーリングを自動的に行うSlurmを容易にローンチできる。ここでの興味深い機能のひとつは、もうちょっと計算力が欲しいようなときに、ユーザーがオンプレミスのクラスターのジョブをクラウドと連合できることだ。

GoogleのCompute Engineは現在、最大96コア、メモリ624GBまでのマシンを提供しているので、GCP(Google Cloud Platform)の上で必要に応じて大規模な計算力クラスターを構築することも、十分に可能だ。

なお、Microsoft Azureもその上にSlurmをデプロイするためのテンプレートを提供しており、またこのツールはかなり前からAWSをサポートしている。

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

IETFがTLS 1.3を承認、悪質なハッカーや盗聴者が仕事をしづらくなる仕掛けを盛り込む

聞こえるかな? 世界中のハッカーや諜報員たちが大声で一斉に叫んでいるよ。Internet Engineers Task Force(IETF)が今日、全会一致で、Web上の暗号化されている接続を高速化し、盗聴しづらくするセキュリティフレームワークを承認した。

それはTransport Layer Security version 1.3と呼ばれ、派手な話題ではないけど、至るところに悪いやつがいるようになったWebの、安全強化策のひとつだ。IETFは、世界中のエンジニアたちの集まりで、このようなスタンダードの策定で協力し合っている。そして今回のTLS 1.3の承認までは、4年あまりという長い年月と、提出されたドラフト(草稿)数28という、たいへんな作業を経ている。

それは、インターネットがとてもデリケートなマシンで、その基本的な部分の変更、たとえばクライアントとサーバー間の安全な暗号化接続の確立は、きわめて慎重な協議を必要とするからだ。

ここで技術的な詳細は述べられないが(ぼくが挑戦しても途方に暮れるだけだろう)、TSL 1.3は、ユーザーの安全を守るためにいくつかの重要な変更を加えている。

  • クライアントとサーバー間の“ハンドシェイク”が簡素化され、平文で送信されるデータの量を最小化するので、暗号化がより早期に開始される。
  • 前方秘匿性”によりハッカーは一回の鍵交換から鍵を解読できないようになり、その後それを使ってそのほかの鍵を解読することもできない。
  • “レガシーの”暗号化アルゴリズムをオプションから除く。それがうっかり、やむを得ず使われると、その欠点を利用してメッセージの暗号を破られることがある。
  • 新たに“0-RTT”、ゼロ・ラウンドトリップ・タイムを導入。このモードでは、サーバーとクライアントが一部の要件を事前に確立していて、お互いを紹介し合わなくても直ちにデータの送信を開始できる。

このスタンダードのの全文は155ページあり、専門のエンジニアでないと理解は難しいだろう。でもとにかく容易に入手できるから、勉強意欲のある方はぜひ挑戦を。

もちろん、現場の実装努力がなければ新しいスタンダードも効果を発揮できないが、IETFの承認が下りたことによって、大企業やWebサービス、より高いレベルのスタンダードなどが実装に着手するだろう。そのことに、われわれ一般ユーザーは気づかないかもしれないけど、インターネットという舞台の縁の下で頑張っているエンジニアたちや暗号技術者などに、この場を借りて謝辞を述べておきたい。

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

Cloudflareがモバイルのネットワークモニタリングツールを発表、デベロッパーはもっとネットワークを意識すべきと

昨年の秋にCloudflareが、モバイルのパフォーマンスをVPNでアップするNeumobを買収したときは、同社がそれまでのWebのパフォーマンスソリューションを超えて、モバイルのデベロッパーにも、ネットワークレベルのパフォーマンスに対する意識と関心を持ってもらうため、と思われた。そして今日同社は、デベロッパーにネットワークレベルのパフォーマンス問題を理解させるための無料のツール、Cloudflare Mobile SDKをリリースした。

Cloudflareの協同ファウンダーでCEOのMatthew Princeによると、デベロッパーはデバイス本体の上でアプリがクラッシュする理由を理解するツールはいろいろ持っているが、ネットワークの状態を見たり理解する能力がない。アプリの不安定性の大きな原因は、デバイスよりむしろネットワークであるのに、という。

Cloudflare Mobile SDKでは、デベロッパーは、自分のiOSやAndroidのアプリにコードを2行書くだけで、ネットワークのモニタリングができるようになる。またWeb上で、ネットワークのパフォーマンスを数値で見ることができる。このツールは、信号が弱かったり、Wi-Fiからモバイルのネットワークに移ったことによってパケット落ちが生じた、などの問題を露呈させることができる。それらは、アプリをハングさせたり誤動作させたりすることもあるネットワークの障害だ。

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

またこのツールにより、世界のいろんなところのネットワークのパフォーマンスを見ることもでき、問題の所在も分かる。ツールが集めて表示する情報によって、パフォーマンスの問題を(デバイスでなく)不安定なネットワークに帰せしめることができ、その不安定さがアプリのパフォーマンスに与えている影響を知ることもできる。

Princeによると、今後はそのほかのモニタリングツールともパートナーして、デベロッパーが一箇所でパフォーマンスの問題をチェックできるようにしたい、という。“目標は、デバイスでもアプリでもなくネットワークのパフォーマンスを上げることと、アプリのデベロッパーがネットワークの状態に関する正しいインサイトを持てるようにすることだ”、と彼は語る。

このツールは、最初のうちはパフォーマンス改善のためのベーシックな提案をするだけだが、今後徐々に、ネットワークモニタリングツールをCloudflareのそのほかのツールとより深く統合して、パフォーマンス向上対策が容易にできるようにしたい、と彼は言う。

Cloudflareはさらにこのツールを、デベロッパーが今後、ネットワークの動態を正しく理解するようになるための‘入口’、入門的環境とも見ている。デベロッパーがネットワークのパフォーマンスに関するデータを取り出せるようになれば、モバイルネットワークの信頼性レポートだって書けるだろう。“デベロッパーがこのツールをいろんなアプリに埋め込んでくれれば、モバイルネットワークのプロバイダを正しく評価できるようにもなるし、そのサービスの良し悪しを比較検討できるようにもなる”、とPrinceは説明している。

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

GitLabがライバルのGitHubをサポート、CI/CDで顧客を取り込みたい

おもしろい展開だ。チームがコードを共有するための共有リポジトリを提供するサービス、という点では多くの点でGitHubと競合するGitLabで、その継続的インテグレーションとデリバリ(continuous integration and delivery(CI/CD))の機能がGitHubをサポートすることになった

今日(米国時間3/22)ローンチするその新しいサービスは、GitLabがホストするサービスの一環だ。2019年の3月22日までは無料で利用できるが、その後は、GitLab.comの有料のSilverティアへ行く。

GitHubもやはり、そのコアツールの上の層としてベーシックなプロジェクト管理やタスク管理のサービスを提供しているが、しかしDevOpsのライフサイクルのほとんどの部分はパートナーたちにまかせている。GitLabは、複数のコードリポジトリを統合するなど、もっと完全なCI/CDソリューションを提供しているが、GitLabの人気もけっして低くはないけど、GitHubはデベロッパーや企業による知名度ではGitLabを大きく引き離している。というわけで今回GitLabは、コードをGitHubに保存しているけどより完全なCI/CDソリューションも使いたい、という新しいユーザー、とりわけエンタープライズユーザーを獲得したいのだ。

今度の新たなGitHubの統合により、デベロッパーは自分のプロジェクトをGitLabでセットアップし、それらをGitHubのリポジトリに接続できる。するとデベロッパーがコードをそのGitHubのリポジトリへプッシュするたびに、GitLabがそのプロジェクトのCI/CDパイプラインを動かし、ビルドとテストとデプロイを自動化する。

GitLabのCEOで協同ファウンダーのSid Sijbrandijはこう述べる: “継続的インテグレーションとデプロイメントは現代的なDevOpsの根幹だ。今回の新しいサービスにより、GitHubをコードリポジトリとして使っている企業やオープンソースのプロジェクトは、GitLabの、業界のトップを走る高度なCI/CDサービスを利用できる”。

なおGitLabは、AtlassianのBitBucketの、今回とよく似た統合も提供している。

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

AIをクラウドにデプロイする過程を単純化するためにPaperspaceはサーバーレスを選ぶ

GPUベースのインフラストラクチャをサービスとして提供することは、スタートアップにとって容易なことではないが、機械学習やVFXを多用するモダンなソフトウェアの開発とデプロイを目指すクラウドインフラストラクチャサービスPaperspaceは、あえてそれに挑んでいる。そして同社は今日(米国時間3/21)、さらに次の一歩として、AIや機械学習のプロジェクトでサーバーのデプロイを不要にするサービスプラットホームGradientを発表した。

どんなサーバーレスのアーキテクチャでも、サーバーがいなくなるわけではないが、ユーザー(デベロッパー)が手作業でそれらをデプロイする必要はなくなる。Gradientはコードをデプロイする手段を提供し、アロケーションやマネージメントはすべてPaperspaceが面倒見る。それにより、機械学習のモデルの構築に伴う複雑性の、大きな塊(かたまり)を取り除く。

同社の協同ファウンダーでCEOのDillon Erbによると、数年前に同社を立ち上げたときはGPUは今日のクラウドサービスのように一般化していなかった。最初は仮想マシンのGPUインスタンスを立ち上げるやり方が主流で、今でもそうだが、問題はツールの不備だった。

Erbの説明では、大企業はツールセットを内製することが多い。しかし実際には、それだけのリソースを持たない企業がほとんどだ。“GPUなどで十分な計算パワーがあっても、それだけではだめで、ソフトウェアスタックが必要なんだ”、と彼は言う。

同社が昨年1年間を費やして作ったGradientは、デベロッパーにそのための構造を提供し、それにより彼らは、もっぱらモデルやコードの構築と、プロジェクトを軸とするコラボレーションに集中できるようになる。そしてマネージメントは、Paperspaceにまかせる。DevOpsのチームが、チームとコードとその下のインフラストラクチャの間の対話を管理する必要も、なくなる。

“コードとDockerのコンテナだけをいただければ、VMのスケジューリングなどはわれわれがいたします。ご自分でマシンを立ち上げる必要はありません”、とErbは語る。

Paperspaceは、Y Combinatorの2015年冬季クラスを卒業して以来、クラウドにGPUをデプロイするという難題に取り組んできた。2014年にローンチしてから今日までに1100万ドルあまりを調達してきたが、シードラウンドの400万ドルがやっと2016年だった。

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