2018年知っておきたい次世代テクノロジーとOSS(後編)ブロックチェーンとコンテナ
OSSだけにとどまらない幅広い領域にテーマを採り、毎回好評を博してきたOBCI(オープンソースビジネス推進協議会)プレミアムセミナー。今回は今もっとも世の中の注目を集めながら、なかなか具体的な情報に触れる機会の少ない次世代テクノロジーの専門家をお招きし、解説いただいた。後編の今回は、ブロックチェーンとコンテナ管理の各テーマについて紹介する。
講演(3)「ブロックチェーンの限界を超える」
誰にも否定できない記録を保存・維持するには
分散型アーキテクチャと耐障害性が必須
ブロックチェーンがいわゆるP2Pの技術だというのはご存知だろう。各端末に置かれたデータはすべて同一で、追加や更新のつどネットワークに参加しているすべての端末=ノードにコピーされる。どこか一つの端末に障害が発生しても、残りの参加ノードがまったく同じデータを保管しているため、個々の障害の影響を受けることなく機能を維持できる。これがブロックチェーンに極めて高い耐障害性を与えているのだ。
だが、この耐障害性にばかり注目するのは、むしろブロックチェーンの本質を見誤ることになると斉藤氏は指摘する。「むしろブロックチェーンには実現すべき本来の目標があり、その実現手段として耐障害性を強化したと考えるべきだ」というのだ。
その目標とは「その内容・存在について、誰にも否定できない記録を保存・維持すること」。ブロックチェーンの実用化はビットコインから始まったため、送金記録を確実に担保するためには、こうした機能が不可欠だった。
「もし特定の銀行や組織にサーバーが集中していた場合、ある人が誰かにお金を送ったのに『システムにそんな記録はなかった』と言われたら反論できない。そういったリスクを避けるために、誰もが送金の事実を確認できる仕組みを作らなくてはならなかった」(斉藤氏)。
その結果、システムは必然的に非集中型にならざるを得ない。かくして「分散型アーキテクチャ+高い耐障害性」がブロックチェーンの大きな特徴となったというわけだ。
ブロックチェーンが目指すのは
「誰もが自由&確実にお金を送れる仕組み」の実現
次に、斉藤氏は最もよく知られているブロックチェーンの応用例であるビットコインについて説明した。そもそもビットコインはなぜ作られたのか。斉藤氏は「誰もが自由にお金を送れる仕組み」の実現・維持のために開発されたと見ている。日本にいる私たちには、実際に自分のお金が送金できないような事態はイメージしにくい。だがインドなどでは高額紙幣が廃止になった結果、銀行の人手が足りなくなり、一般の利用者の口座を一時的に凍結するといった緊急事態が現実に起きている。
「そんな国や地域では、自分の資産の移動に関するリスクから身を守らねばならない。世界的に見ると“送金の自由”は、経済の自由に関する重要な課題の一つとなっている」(斉藤氏)。
自分のお金をいつでも、どこへでも送金できるようにする。そのために注目されたのがブロックチェーンの基本的な仕組みだ。銀行など特定のサービス提供者による制約を受けないためには、デジタルのコインをP2Pで送る仕組みを構築し、なおかつ送金した事実をデジタル署名によって記録できなくてはならない。
だが、デジタル署名を用いたとしても、それだけでは解決しない問題があると斉藤氏は言う。「ダブル スペンディングの問題」だ。
「例えばAさんからBさんにデジタル署名をつけて100円送金した場合、データは送ってもAさんの手元には実体の100円が残っているため、それにまた同じデジタル署名をつけてCさんに送ると、デジタル署名のついた送金記録が2つできてしまう。この“正しい”送金記録が複数存在してしまう事態を何とか防ぎたい」(斉藤氏)。
では、どうするのか。AさんからBさんに100円送金する際に、そのデジタル署名付きの取引記録を作成して、しかもそれが誰からも閲覧できる仕組みを作ればよい。そうすれば仮にダブル スペンディングが起きても、日付の一番早い記録に載っているBさんへの送金が“正しい”と、すべての第三者から判断してもらえるからだ。
「作業証明付きハッシュチェーン」により
取引記録の改ざんなどを物理的に不可能にする
斉藤氏の言う「誰からも閲覧可能な仕組み」とは、言い換えれば「ビットコインで行われた取引の記録をみんなで確認できる仕組み」でもある。この記録は通常2000~3000件の取引を1つのブロックとしてまとめ、このブロックそれぞれを第三者が正しい取引記録であると認めたら「承認」し、その承認したという記録をブロックチェーンに書き加えていく。まさに「ブロックチェーン(記録のブロックの連鎖)」なのだ。
だが、これで完璧というわけではない。この“承認したという記録”自体の真正さが証明されなくてはならないからだ。このデータの真贋の判別に使われるのが「作業証明付きハッシュチェーン」という技術である。
ビットコインの取引データは数列で表されている。その中の特定の部分をハッシュと呼ばれる特別な計算式にかけ、得られた数字を「ハッシュ値」と呼ぶ。このハッシュ値がビットコインのルールに合っているものだけが正当な取引として承認され、なおかつ報酬のコインを受け取れる仕組みだ。だが毎回“正当な”ハッシュ値が出るわけではない。承認して報酬を受け取るには、文字列の一部の数字(“ノンス”と呼ばれる)を1つずつ変えては計算式にかけ、“正しい”ハッシュ値が出るまで根気よく繰り返さなくてはならない。
「それには、平均1秒間に2750京回の計算が必要だ。そのため1か所でも改ざんすると、その記録を承認してもらうためには膨大な再計算が必要で、実質的に改ざんは無理だと考えられている」(斎藤氏)。
サイバーフィジカル社会に必要不可欠な
情報の真正さをブロックチェーンが守る
斉藤氏は、最後に「結局ブロックチェーンを何のために使うかというと、しっかりした取引記録の基盤を作ることで、これからの社会の自動化に貢献するためだ」と語る。
近い将来、社会は新たな目や耳、手や足を持つ=サイバーフィジカル社会の時代を迎えると考えられている。例えば、ある地域に雨雲が近づくと、その気象情報が各家庭の家事ロボットに送信され、ロボットが洗濯物を取り込んでくれるといったことも、もはや夢物語ではない。
ここで重要なのは、そうした新しい情報ネットワークを通して得られた内容は正しいのか、 そしてその情報に基づく判断や制御は正しいのか、ということだ。この点について、斉藤氏は「もしニセの情報が流された時に、正否を判断する手段がなかったら大変危険だ。その守りにブロックチェーンは非常に有効だと考えている」という。
さらにこの先AIが社会の隅々に浸透してくると、人間ではわからないブラックボックスの部分が急激に増えてくる。そうした場所で発生しうる障害や逸脱から、正しい記録を保存・維持する上でもブロックチェーンは大きな可能性を持っている。
「あらゆる技術は、特定の問いに対する答えだ。ビットコインも『自分が自由にお金を扱うには?』という問いへの答えだった。同様に、私たちはこれからの社会をどうしてゆくか、それには何が必要かを問い続けねばならない。来るべきサイボーグ社会(Cybernetically Organized Society)に何を期待し、そこに対して信頼できる技術を開発していくかが必須の課題となる」と斉藤氏は力強く述べ、セッションを終了した。
講演(4)「コンテナー管理OSSの定番、Rancherによる
100%オープンな開発・運用体制の構築」
国内外でコンテナへの注目度が急上昇中
わが国初のイベントではチケットが完売する勢い
新藤氏は冒頭、近年のコンテナのめざましい普及ぶりに触れる。「国内企業だけを見ても、メルカリやポケモンGOもコンテナでサービスを構築している。またAbemaTVはコンテナを活用することでネットテレビ局をわずか4か月で立ち上げられることを示してみせた。海外はさらに盛り上がっており、中でもアリババはDockerのワールドワイドカンファレンスに大規模なブースを出展して注目を浴びた」。
また、国内でもエンジニアを中心にコンテナに対する関心は日増しに高まり、2018年4月19日に開催された、わが国初のコンテナ関連技術に特化したイベント「Japan Container Days v18.04」では、5000円のチケット540人分が完売したと新藤氏は明かす。
「この売れ行きを見ても、コンテナの現場レベルではエンジニアたちが大いに勉強したがっていることがわかる。サイバーエージェントやメルカリといった成長分野のプレイヤーが次々に採用していることも手伝って、開発者、ユーザー双方にコンテナに積極的に取り組む気運が高まっているのは間違いない」(進藤氏)。
完全なKubernetesベースに生まれ変わった
最新バージョン「Rancher 2.0」
新藤氏が日本の事業統括責任者を務めるRancher Labs。同社が提供するオープンソースソフトウェア「Rancher」は、すでに世界5000以上の組織や企業で導入され、コンテナ管理プラットフォームの市場で重要な地位を占めている。
Rancherの最もホットな話題は、これまでの「Rancher 1.6」から「Rancher 2.0」へのバージョンアップだ。すでに2017年にテクニカルプレビュー版がリリースされ、2018年夏前の正式版リリースに向けて現在急ピッチで作業が進んでいる。
新バージョンでの最も大きな変更は、オーケストレーションの基盤を従来のマルチオーケストレータからKubernetesベースに完全に移行したことだ。Rancher 1.6はKubernetes以外にも独自開発のCattleやMesos、Swarmといった複数のオーケストレーション機能を備えていたが、Rancher 2.0ではKubernetesベースに統一。これに伴い、従来のマルチクラウド対応もマルチKubernetesクラウド対応としてGoogle Kubernetes Engine(GKE)、Azure Kubernetes Service(AKS)、Amazon Elastic Container Service for Kubernetes(EKS)といったマネージドサービスに対応した。
こうしたドラスティックな変更の背景は、Kubernetesがコンテナ環境のオーケストレーションツールのデファクトスタンダードとなったことだ、と新藤氏は言う。「Rancher 1.6の開発当時はまだコンテナのオーケストレーション管理の技術が確立されていなかったため、すべてに対応しようという考え方だった。だがここ2年くらいでKubernetesが急速に台頭したことに合わせて、大幅なリニューアルを図ったのがRancher 2.0だ」。
プラットフォームに制限されることなく
クラウドからオンプレまで横断的にコンテナを管理
Rancher 2.0がユーザーにもたらす大きなメリットの一つに、プラットフォームを選ばずにKubernetesを使ってコンテナ管理が実現可能な点が挙げられる。
プラットフォームだけではない。Rancher 2.0は管理・運用に機能を特化しているため、開発ツール選択の自由度が高いのも大きな特長だ。従来のクラウドベンダーによるPaaSはハードウェアやOSからアプリケーションまでを垂直統合型で積み上げていくため、いわゆるベンダーロックインが悩みだった。
「開発・プログラミングツールはユーザーによって好みが異なってくる。Rancherはあくまで管理運用の部分だけを担うので、既存の開発環境の制約を受けることが少ない。そのため、例えばGitLabとの組み合わせなども可能だ」(進藤氏)。
すでにGitLabやGitHubによる開発体制が確立している場合も、Rancherは独立した管理運用ツールとして導入できる。「単独ベンダーによる垂直統合型環境には、すべてを任せて一元管理できる良さもあるが、Rancherを採用されるお客様には、オープン性や選択の自由度という部分を高く評価してくださる例が多い」と指摘する。
さらにもう1つの特長は、オンプレミスとクラウドの混在環境を一元管理できる点だ。例えばゲームベンダーなどのように、パフォーマンス管理やストレージ、ネットワークが重要で、自分たちが把握できるハードウェア上でコンテナを管理したいというユーザーの場合、コアな部分だけをオンプレミスで運用し、他の部分はクラウドに上げるといった使い分けもRancher 2.0ならば問題なく実現できる。
ユーザーコミュニティ「Rancher JP」を中心に
全国各地での勉強会やドキュメント公開を展開中
新藤氏はRancherのもう1つの強みとして、コミュニティの充実を挙げる。Rancher JPと呼ばれるコミュニティは、発足からわずか1年半で約1000名に達する勢いだ。メインの活動は「Rancher Meet up」と呼ばれる勉強会で、2016年10月のスタートから2018年5月ですでに12回目を数える。Meet up以外にも、これまで札幌、東京、京都、大阪、広島、福岡でハンズオンなどさまざまな勉強会が有志メンバーによって開催されているという。「これを将来的には各都道府県に展開するのが自分の使命の1つだと考えている」と進藤氏。
Rancher JPではメンバーによる日本語資料の作成・整備も進んでおり、これまでに約80種類のドキュメントが公開されている。またSlackも運営され、常時300名ほどのメンバーが盛んにコミュニケーションをとっている。
「おそらく現在Rancher JPは、マルチクラウドおよびマルチKubernetesクラウド環境のユーザーコミュニティとしては日本最大級と自負している。しかしRancherの市場で見た場合、まだまだ日本は小さい。ぜひコンテナやKubernetesによるコンテナ管理に関心を持っている方は、コミュニティに参加して市場規模を盛り上げていただきたい」(進藤氏)。
こうした声に応えるように、「Japan Container Days」の第2回も2018年12月4~5日の開催が決定したという。「2018年は日本における『コンテナ元年』になる」と宣言し、新藤氏はセッションを締めくくった。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- オープンソースのコンテナ管理ツール「Kubernetes 1.12」リリース
- Google、オープンソースのコンテナ管理ツール「Kubernetes 1.3」リリース
- オープンソースのコンテナ管理ツール「Kubernetes 1.10」リリース
- オープンソースのコンテナ管理ツール「Kubernetes 1.10」リリース
- オープンソースのコンテナ管理ツール「Kubernetes 1.15」リリース
- Google、オープンソースのコンテナ管理ツール「Kubernetes 1.7」リリース
- Google、オープンソースのコンテナ管理ツール「Kubernetes 1.7」リリース
- Google、オープンソースのコンテナ管理ツール「Kubernetes 1.1」リリース
- Google、オープンソースのコンテナ管理ツール「Kubernetes 1.2」リリース
- Google、オープンソースのコンテナ管理ツール「Kubernetes 1.4」リリース