マイクロサービス

サービスメッシュIstioがバージョン1.0に到達、マイクロサービスアーキテクチャの成熟を推進

Istioはマイクロサービスのサービスメッシュで、Google, IBM, Lyft, Red Hatなどによるオープンソースの共同プロジェクトだ。そして今日（米国時間7/31）は、そのツールのバージョン1.0がローンチした。

サービスメッシュをよく知らない人がいても、不思議ではない。むしろ今は、知らない人の方が多い。でもIstioはたぶん、今のオープンソースプロジェクトの中ではもっとも重要なもののひとつだ。それは、コンテナや、マイクロサービス、サーバーレスコンピューティングなど、今の業界のトレンドのいくつかが交わるところに位置し、エンタープライズがそれらをより容易に導入できるようにする。今Istioは200あまりのコントリビューターがいて、バージョン0.1がローンチして以来4000回以上もチェックインされている。

Istioの中心的な機能は、マイクロサービスのルーティングやロードバランシング、フローコントロール、そしてセキュリティだ〔日本語参考記事〕。それは既存の分散アプリケーション群の上に座って彼らの安全な対話を助け、またログ取りやテレメトリー、そして全体を安全に制御下に置くために必要なポリシーを提供する。カナリアリリースもサポートしているので、アップデートの本番ローンチの前に少数者でテストすることもできる。それはGoogleのようなWebスケールの企業が、内部的に前からやっていることだ。

GoogleのプロダクトマネージャーJennifer Linが、説明してくれた: “マイクロサービスの時代になると、いろんなものの移動や変化が激しくなる。Kubernetesの成功によってコンテナのオーケストレーションまわりは抽象化を果たしたが、Istioはオープンソースのプロジェクトとしてその次のステップを担い、マイクロサービス開発のための基盤となり、またVMベースのワークロードをなるべく多くサービス管理のレイヤへ移すためのパス（径路）も提供する。そのためそれは、サービスのための正しいレベルの抽象化にフォーカスし、またサービスを管理するための無矛盾な（整合性ある）環境を作る”。

1.0のリリースの前から、eBayやAuto Trader UKなどいくつかの企業がすでにIstioをプロダクションに採用している。Linの主張ではそれは、マイクロサービスを採用した多くの企業が今直面している問題を、Istioが解決してくれるというサインだ。“ますます多くの、ますます高度な顧客たちが自分たち独自のサービス管理レイヤを作ろうとトライし、そんな彼らがまだ1.0になる前からIstioに切り替えている。いくつかの有名大企業も含む多くの顧客が、‘1.0でなくても十分プロダクションで使える。われわれが作った粗っぽいものに比べると、随分ましだ’、と言っている”。

IBMのフェローでクラウド担当VPのJason McGeeも彼女の話に同調し、こう言っている: “Istioがローンチしてから以降のわれわれのミッションは、だれもがマイクロサービスで成功できるようにすることだ。とりわけ、エンタープライズがね。だからこそわれわれはコミュニティにフォーカスし、セキュリティとスケールの改良に努め、これまであらゆるサイズの企業のためにアジャイルなクラウドアーキテクチャを築いてきた経験から学んだことを、重点的にIstioにコントリビューションしてきた”。

大手のクラウド選手たちの多くが、今や直接にIstioをサポートしている。IBMは同社のKubernetes Serviceがそのベースだ。GoogleはGoogle CloudのユーザーにマネージドIstioサービスすら発表しているし、またKubernetesとIstioをベースに構築されるサーバーレスアプリケーションのために特製したオープンソースのツールも提供している。

今日のパーティーにはMicrosoftとAmazonの姿が見えないようだが、このプロジェクトが元気であるかぎり、彼らも必ず来るだろう。

現状ではIstioは、主なオープンソース団体のどれにも属していない。Kubernetesの本拠地であるCloud Native Computing Foundation(CNCF)は、Istioとそんなに変わらないlinkerdを推している。この種のプロジェクトは1.0がリリースされるころになると、長期的に支えてくれそうな団体を探すことが多い。Istioもきっとそのうち、居場所を見つけるだろう。

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

Atlassianの2年にわたるクラウドへの旅 ―― AWSへの大幅な移行

数年前、Dropboxがパブリッククラウドの採用をほとんど止めて、独自のデータセンターを構築することに決めたことは、多くの人々に衝撃を与えた。だが最近、Atlassianはこれとは逆向きに、ほとんどのデータセンターを閉じてクラウドに移行した。企業たちは、さまざまな理由でこうした選択を行う。Atlassianの現在のCTOであるSri Viswanathが取締役会に加わったのは2016年だったが、彼は同社の最大のアプリケーションをAWSに移行する決定を下した。

これは部分的には、時間が経つにつれてアプリケーションたちが厄介なコードの層に邪魔されて、更新も保守も行うことが困難になる、技術的負債に関わる話である。2002年に設立されたAtlassianにとって、Viswanathが会社にやって来た2016年が、いわば先延ばしにしていた年貢の納め時だったということだ。

Atlassianは、未来に進むためには、コードを更新する必要があることには既に気がついていた。彼らがViswanathを取締役会に加えた理由の1つが、その仕事の指揮をとって貰うことを狙ってのことだが、そうした仕事の必要性そのものは、彼がやってくる前に十分に認識されていた。2015年には新しいクラウドベースのアプローチに向けたビジョンとアーキテクチャを検討する小さなチームが立ち上げられていたが、その成果を十二分に達成するために、最初のCTOを採用したいと考えたのだ。

マイクロサービスへの移行

彼は計画を実行に移し、内部コードネームVertigoを与えた。おそらく、彼らのソフトウェアスタックの大部分をパブリッククラウドに移行させるという考えは、エンジニアリングチームにとって、想像するだけでもめまいがするようなものだっただろう。このプロジェクトの目標は、その最大の製品であるJiraとConfluenceから始めて、ソフトウェアを再構築することだった、もちろん次の10年を大きな困難なしに支えてくれるような基礎とすることが狙いだ。

写真：WILLIAM WEST/AFP/Getty Images

彼らは2016年の大部分をソフトウェアの書き直しに費やし、それをAWS上に置くことにした。15年に渡って蓄積されてきたコードをマイクロサービスに転換することに注力した結果、最終的にはコードベースも小さなものにすることができた。彼は、技術的負債は大変な問題だったが、車輪の再発明をしないように注意深く行う必要があったと語った。いつでも、本当に変更する必要がある場所だけを変えるようにしていたのだ。

「コードベースは相当な大きさでしたので、作業に際して、私たちは2つのことをしなければなりませんでした。マルチテナントアーキテクチャのために構築したいと思っていましたし、マイクロサービスを提供したいと思っていたのです」と彼は語った。「もし引っ張り出して自己完結型にすることのできるサービスがあれば、そうしたことでしょう。でも私たちは新しいサービスを全体プロセスの一部にしたかったのです」。

運用しながらの顧客移行

移行が行われたのは昨年だった。そしてすべての顧客を残らず新システムに移行させるにはまるまる1年が必要だった。その移行は1月に始まり12月に終了したが、数万の顧客が移行の対象となった。

写真：KTSDesign/Science Photo Library

まず第一に、彼らは可能な限り自動化を行い、移行の順番についても非常に慎重に考慮し、難しく見える移行に関しても注意深く取り扱った。「どのような順番で移行を行うべきかに関しては非常に慎重に考えました。単に最初に簡単なものから始めて最後に難しいものをやろう、とは思っていませんでした。かといって困難なものばかりに取り組んで、進捗があまりないことも望む所ではなかったのです。私たちは（自分たちのアプローチ）を適宜ブレンドし、プロジェクト全体のバグと課題を解決して行かなければなりませんでした」と彼は語った。

Viswanathは、とにかく重要な目標は、顧客を重大な問題を起こすこと無く移行させることだったと述べた。「マイグレーションを行った人と話したことがあるなら、それは大変なことだとわかります。誰もがマイグレーションで多かれ少なかれ傷を負っているのです。これを本当に慎重に行うことを意識していました」。驚くべきことに、それは完璧ではなかったものの、大規模な停止を招くことなく彼らはこの仕事を乗り切ることができた。誇るべき仕事だと言えるだろう。もちろんだからといって、それがずっと順調で簡単だったというわけではない。

「『私たちは注意深く考え移行しました』と聞くと、まるで簡単なように響きますが、実際には毎日が戦争でした。移行する度に、壁にあたり思わぬ反応が起きました。一年を通して、それが私たちにとって日常的な事だったのです」と彼は説明した。エンジニアリング、プロダクト、サポートを含むチーム全体の努力が必要とされた。その努力の一環として、日々のスクラムミーティング（スクラムはアジャイル手法の1つ）にはカスタマーサポートの人間も参加してもらい、顧客が抱えるあらゆる問題に関する感覚を掴み、それを可能な限り迅速に解決できるようにしていた。

彼らが得たもの

どのようなクラウドプロジェクトでも、アプリケーションをクラウドに移行することには、柔軟性、敏捷性、資源弾力性といったものに関わる、一般的なメリットがあるものだが、今回のプロジェクトにはそれ以上のものがあった。

写真： Ade Akinrujomu/Getty Images

まず第一に、マイクロサービスがたっぷり使われているために、複数の配備を同時に迅速に展開することが可能になった。すなわち、新しい機能を格段に早く追加することができるようになったのだ。移行期間の年は、移行のためにできるだけものごとを静的に留めておきたいと考えていたために、ほとんどの新機能の追加は延期されていた。しかし新しいシステムを導入することで、新しい機能の追加をはるかに迅速に行うことができるようになったのだ。

パフォーマンスも大幅に向上した、そしてこの先もしパフォーマンスのボトルネックが発生しても、クラウドであるためリソースをただ追加することができるのだ。さらには、EU内で現地拠点を持つことができるようになり、エンドユーザーに近い場所にアプリケーションを配置することでパフォーマンスが向上した。

最後に、クラウドに移動したすべての企業に当てはまるわけではないが、彼らにとってはクラウドがより経済的な選択肢であることが本当に実証されたのだ。データセンターを閉鎖して、ハードウェアの購入費用や、それを維持するためのIT担当者を雇用することに伴うコストを削減することによって、全体のコストを削減することができた。

人間的側面の管理

これは長期にわたるプロジェクトだったが、彼らはそれと同様に、人間的側面も考える必要に迫られていた。彼らは、技術者が常に新鮮な気持ちでいられるように配置換えを行い、移行支援作業で技術者たちを疲弊させないようにした。

企業文化そのものも役立ったものの1つだ。Viswanathはそれを率直に、オープンなコミュニケーションと、問題を隠し立てしない文化によるものだと説明した。「わたしたちはオープンなコミュニケーションの維持を心がけています。たとえ物事がうまく進んでいないときでもそれは変わりません。もし自分の手に負えなくなったときには、エンジニアは手を挙げて助けを求めます。そうすることで私たちは支援を行うことができるのです」と彼は言う。

彼は同社の中にある種の不安があったことを認めた。彼個人にしてもこの規模のプロジェクトの実施に関しては不安を抱えていた。しかし彼らは組織の未来のためには、これを行う必要があることを理解していたのだ。「もしこのプロジェクトがうまくいかなければどうなるんだ、という緊張は確かにありました。でもその方向は正しいもののように見えましたし、私たちはそれをやらなければならなかったのです。真のリスクは、私たちが遂行に失敗して、あるべき利便性を実現しそこなうことでした」。

結局のところ、それは大変な作業だったが上手く行き、将来のためのシステムを手にすることができた。「次の10年を戦う準備が整いました」と彼は言った。

[ 原文へ ]
（翻訳：sako）

画像： erhui1979 / Getty Images

これからのアプリケーション開発は「3つのマイクロ」の時代に

【編集部注】著者のPeter Yared氏はSaphoの創業者でCTO。以前はCBS InteractiveでCTO/CIOを務めた。

これまでアプリケーション開発はずっと危険に満ちていた：プロジェクトは肥大化し、高価につき、決してリリースされない。実装技術は ‐ サービス指向アーキテクチャ（SOA）からビジネスプロセス管理（BPM）に至るまで ‐ その肥大化と歩調を合わせる傾向にある。RedpointのTomasz Tunguzが最近指摘したようにSaaS（サービスとしてのソフトウェア）の成長は鈍化しており、次世代のアプリケーションは既存のアプリケーション同士を斬新な方法で新しいワークフローへと織り上げたものになる。

サービス、アプリケーション、およびフローの「マイクロウェーブ」

アプリケーション開発における「マイクロ」の傾向とは、複雑な問題に対して、ボトムアップにシンプルなソリューションを提供することに注力するといったものである。マイクロサービスは簡単に複数のシステムと統合することが可能であり、マイクロアプリは簡単なユーザーインターフェイスを提供することが可能で、そしてマイクロフローは利用者にシステムを横断してタスクを完了させることを可能にする。サービス、アプリケーション、およびフローのこの「マイクロウェーブ」3人組は、ソリューションを即座に提供するために、既存のシステムを斬新で有機的な手段を用いて織り上げる新しい方法を提供する。

マイクロサービス

image (4)

アプリケーション間の相互運用性は、長い間アプリケーション開発における聖杯（追い求めても手に入れることができない価値あるもの）となっていた。1990年代のCORBA/IIOPといったヘビー級トップダウンアーキテクチャは、2000年代にはSOAへと進化した。SOAの実装には、企業全体への義務と協調の適用が必要とされた。SOAPなどのペイロード規格は、ヘビー級で特に認証層での非互換性に満ちていた。

GEのようなわずかな企業が、SOAを実装するための規律を持っていたが、ほとんどの企業にとって、SOAプロジェクトは、広く採用されることはなかった。たとえ成功した後でも、企業の世界の恒常的な売却や買収は、SOAをムービングターゲット（定まっていない目標）にし続けた。

ここ数年は、マイクロサービスが流行となっている。マイクロサービスとは、アトミックで、バックエンドで単一の操作（例えば顧客レコードを1件取得するといった）を実行するような自己完結型のものである。マイクロサービスへの最も一般的なインタフェースは、よく知られていて、非常に単純なJSON/REST/HTTPSパラダイムを採用している。認証も単純であり、一般的に使いやすいAPIキーを採用している。

マイクロサービスの美しさは、それらの作成、デプロイ、および共有が信じられないほど簡単なことだ。新規および既存のアプリケーションは、簡単に多数の外部ならびに内部のマイクロサービスを呼び出すことができる。否定論者たちは、マイクロサービスがまるでキノコのようにあまりにも簡単に増殖し、スケールしにくく共有や発見が難しいという点を正しく指摘している。しかし、これらは強引な技術によってではなく、各企業内のポリシーによって囲い込まれるべき問題である。

アプリ同士が有機的に通信することを簡単にすることによって、アプリ開発と展開方法の新世代が生み出され、そのことが企業とソフトウェアベンダー双方にとってアプリケーションの新世代を加速することをとても容易にしている。

マイクロアプリ

image (3)

2008年にiOSとAndroidのアプリストアが発足して以来、モバイルアプリが多くの消費者のプライマリインターフェイスとして採用されてきた。利用可能なアプリケーションの過多で、消費者のデバイス上にアプリをインストールさせ、それを使い続けて貰うことはとても難しくなっている。それ故に、ベンダーが機能をアプリの中に山のように積み上げて既存の利用者を新しい機能で引きとめようとしたり、同時により多くのユーザーを惹きつけようとすることは、とてもありふれたやり方である。その結果、ネイティブアプリはますます肥大化し、ナビゲートするのが難しくなって来ている。

インテリジェントでコンテキストに敏感な「マイクロアプリ」のニューウェーブが、出現し始めている。マイクロアプリケーションをサポートするプラットフォームは、インタラクティブなSlackやFacebook Messengerのボットから、天候やフライトといったGoogleのインタラクティブな回答ボックスといったものまでを含んでいる。これらのマイクロアプリケーションは、通常は単一目的のもので、簡単なユーザーインタフェースとコンテキストを組み合わせて利用する。

Facebook Messengerのマイクロアプリはリッチなバブルとメニューで構成されている

マイクロアプリはHTMLに基づいており動的にロードされる。一般的にはアプリストアをバイパスし、SlackやFacebook Messengerといった既存のコミュニケーションツールへと直接ロードされるのだ。「ボット」が使う自然言語の側面には間違いなく抵抗がある。しかし、素早くマイクロアプリをメッセンジャーの中にロードしたり、結果を検索できたりする能力は、急速に勢いを増している。Facebook Messengerは特に、新しい機能を素早く統合しつつある、例えば動的なメニューやインタラクティブなユニットで、それを使えばシャツを買うことからビザの注文までが可能になる。

Slackの開発者リレーションのディレクターであるAmit Shevatは、マイクロアプリを一言で上手く表現してくれた：「それは1つのことを本当に上手に行わなければならない」。

マイクロフロー

ビジネスプロセスマネジメント（BPM）ツールは、組織がビジネスプロセスの自動化をトップダウンに実装するのに役立つ。それらは通常、非常に高価であり、デプロイにも長い時間がかかる。BPMツールは、人間とのインタラクションや機械間（MtoM）の転送を必要とする、長期間に渡るワークフローを管理する。

マイクロフローへ最初に進出したのは、IFTTTやZapierといった企業で、あるマシンから他のマシンへのデータ転送を扱う ‐ 例えばSalesforce上で締結された契約をZendeskへ送るといったようなものだ。これらのサービスには人気があるが、それらは牽引力と収入の上限に達している。例えばWorkatoといった新しい企業が、SaaS型システム間のMtoMワークフローを拡張しているが、それらは複雑さという点においてBPMソリューションと似通っていて、プログラマ向けのドメイン専用言語（DSL）を必要とする。

Slack内でのマイクロフロー

マイクロフローのための新たな可能性は、人間-機械インタラクションの場である。今やSlackやSkypeのようなメッセンジャープラットフォームが、リッチでインタラクティブなHTMLを通してユーザーがバックエンドと対話することを可能にしている。ユーザーがどのようにエンタープライズソフトウェアと対話するかについて再考するチャンスが存在しているのだ。

マイクロフローを使用すれば、複雑で扱いにくいレガシーシステムをバイパスして、ユーザーは承認などの単純なアクションを実行することができる。現代の労働者、特に若い労働者の最大の不満の一つは、長年に渡ってアップグレードされていないレガシーITシステムと対話することの困難さである。X世代（1960年代初頭-1970年代半ば生まれ）の労働者の多くが、どうしてそこら中にタイプライターがあるのだろうと訝しんだように、ミレニアル世代（1980年代半ばから2005年位までの生まれ）は、多くのグローバル2000で採用されている不必要に複雑で時代遅れのシステムに困惑しているのだ。

経営幹部や管理者でも、マイクロフローから便益を受けることが可能だ。例えばたまにしか使わないシステムにログインすることを要求する多数の承認を行う際などに。多くの企業が、経費管理などの機能のために複数のシステムを持っている。IT部門は恐らくシステムを統合する長期計画を有しているかもしれないが、マイクロフローは幹部たちに、単一のインターフェイスを通して複数のシステムと容易にインタラクトすることを可能にする。

マイクロフローは、典型的にはユーザと幾つかのタイプの対話を必要とするため、それらはモバイルデバイスやメッセンジャーの通知機能を最大限に利用することができる。このような単純で、簡単に使用できるマイクロフローは、より多くのマクロワークフローへ関係者たちを完全に巻き込むことを容易にする。

「マイクロウェーブ」の未来へ向かって

マイクロサービス、マイクロアプリ、そしてマイクロフローを相互に組み合わせることによって、次世代のアプリケーションを提供するための新しいパラダイムが提供される。私たちが過去の教訓から学び、マイクロ革命を「肥大化」させないことを願っている。

[ 原文へ ]
（翻訳：Sako）