Japan Container Days v18.12レポート（2018年12月4日取材）
Kubernetesを中心とするコンテナ技術のイベントJapan Container Days（JKD）v18.12が、2018年12月に都内で開催された。
JKD v18.12でIBMが語るクラウドネイティブカンパニーへの道
IBMの斎藤和史氏のキーノート「Cloud Nativeの未来とIBMの取り組み」では、クラウドネイティブへのIBMの取り組みが語られた。
「絶対止めないシステム」から「絶対止めないビジネス」へ
まず斎藤氏はIBMのイメージについて、「やはりホスト、汎用機、勘定系システムではないでしょうか」と問いかけ、「いまはクラウド」と主張した。
さらに、「プロプライエタリのイメージをお持ちのかたもいらっしゃるかもしれません」としつつ、いまはオープンテクノロジーに大きく投資をしていることを紹介。CNCFに参加し、KubernetesやIstio、Knativeなどのプロジェクトに開発から関わっていることを説明した。そのほか、10月に発表されたRed Hatの買収にも触れ、オープンソースやハイブリッドクラウドに大きく投資していると語った。
「いま、IBM全体がクラウドネイティブカンパニーになろうとしている。そこをご理解いただけるとうれしい」（斎藤氏）
この変化について斎藤氏は、「絶対止めないシステム」から「絶対止めないビジネス」への変化として説明した。前者のためのポイントは超可用性、後者のためのポイントは高い復元力だという。この復元力の中心となるのがKubernetesである。
IBMのKubernetesへの取り組み
具体例としてはまず、IBM社内でCIO（Chief Information Officer）やCDO（Chief Data Officer）、CAO（Chief Analytics Officer）らが束になり、社内基盤を作り、顧客分析などに利用しているという。クラウドネイティブ構成によりハイブリッドクラウドでマルチクラウドで、巨大なうえにスケーリングを重視しているという。
次の例はAIのWatsonだ。かつてはダラスでのみ動いていたのが、Kubernetes化したことにより、日本のIBM Cloudでも、他社クラウドでも、オンプレミスでも動くようになった。
そのIBM Cloudは東京リージョンを含む世界6リージョンでアベイラビリティーゾーンを提供。2019年には日本で関西データセンターも開設する予定だとアナウンスされた。
IBMグループの天気予報会社The Weeather Company（weather.com）も、システムをマイクロサービス化してKubernetesで動かし、絶対止めない環境を実現しているという。
IBMのソフトウェアであるWebSphereやDB2、MQなども、Kubernetes用にコンテナ化して提供している。しかも、Helmで最適構成にパッケージ化している。「使う側にとって簡単に使えてうれしいのと同時に、作る側にとってもメンテナンスしていけるので、両者うれしい」と斎藤氏は語った。
クラウドネイティブ環境の大変な運用を解決するIBMの解決策
さて、このようなクラウドネイティブの環境について「やり出すのはやれてしまうが、その後の運用が大変」と斎藤氏は言う。
しばしば聞かれるのが、あっという間にたくさんのクラスタが作られて収集がつかなくなることだ。IBMでも、公式には700クラスタがあることになっているが、実際にはその何十倍はあると斎藤氏。たとえば本番環境と開発テスト環境を分けたり、クラウドとオンプレミスで分けたり、プロジェクトごとに分けたり、関東と関西など地理的に分けたりなど、さまざまにクラスタが分けられる。
「こうなると、運用がしんどい。インフラのバージョンアップや拡張など大変になる。それができるスーパーエンジニアが何人いるだろうか」（斎藤氏）
そのために斎藤氏が挙げた解決策の1つめが、運用管理を便利にする新しいテクノロジーを積極採用すること。そして、それらを採用したIBM Cloud Kubernetes Service（IKS：フルマネージドKubernetes環境）やIBM Cloud Private（ICP：プライベートクラウド基盤ソフトウェア）といったサービスや製品を利用することだ。
解決策の2つめが、人を育てることだ。これには、ユーザー企業とのコラボレーションによって新規ビジネスなどを創出する場「IBM Cloud Garage」を斎藤氏は挙げた。新規開発だけでなく、SREなどにも取り組んでおり、世界中に拠点があるという。
解決策の3つめは、新しいテクノロジーをハイブリッドクラウドやマルチクラウドで使える仕組みを用意すること。これついてはマルチクラウド管理プラットフォームの「IBM Multicloud Manager」を斎藤氏は紹介した。ポリシーベースのアプリケーション管理機能を持ち、たとえばブロックチェーンのワークロードを条件を満たすクラウドにデプロイする、といったことができるという。
JKD v18.12でIBM CloudのIKSの特徴を知る
ランチセッションとして開催された「IBM Kubernetesの全貌と始め方」では、日本IBMの高良真穂氏が同社のクラウドサービスIBM Cloudについて、IBM Cloud Kubernetes Service（IKS）を中心に紹介した。
IKSを支えるIBM Cloudのアーキテクチャー
高良氏は冒頭で、汎用コンピュータの元祖System/360や、コンピュータネットワークSNA（System Network Architecture）、ThinkPad、Deep Blue、WatsonといったIBMの歴史を紹介。その後に、2013年のSoftLayer買収や2014年のBluemix、2017年のIBM Cloudブランドへの統合、2018年のRed Hat買収といったクラウドへの歩みを紹介し、「IBMは現在AIとクラウドを中心に変革を進めています」と語った。
IBMのKubernetesの製品やサービスには、ソフトウェア製品のIBM Cloud Private（ICP：プライベートクラウド基盤ソフトウェア）と、IBM Cloud Kubernetes Service（IKS：フルマネージドKubernetes環境）がある。高良氏によると、両者のチームは統合されたという。
IKSでは、自社インフラの上で、KubernetesによりDockerコンテナーを動かす。ユーザからはkubectlコマンドやdockerコマンドが使える。Kubernetes Certified 1.11を取得。「Kubernetesで標準化されているので、ベンダーロックインされない」と高良氏は説明する。
基本アーキテクチャとしては、IBM CloudのグローバルネットワークとIaaSプラットフォームの上に、KubernetesやCloudFoundry、170を超えるサービスが乗っている。
このうち、グローバルネットワークは、世界61箇所のデータセンターを結んでいる。ネットワークは地球を2周（東回りと西回り）しており、最低10Gbps。データセンターには、IBM Cloud対応のもののほか、昔からの顧客のために政府機関用データセンターやハイセキュリティデータセンターなどもある。
IBM Cloudでデプロイ可能なデータセンターは42箇所で、そのうちIKSが使えるのは31箇所。IKS対応のデータセンターの中で、マルチゾーンでのKubernetesに対応しているデータセンターがあり、日本のTOK02、TOK04、TOK05も含まれている。マスターノードも分散配置して障害に備えられるという。Podのオートスケールのほかノードのオートスケールも開発中。
マルチゾーン構成で使うロードバランサーとしては、CIS（IBM Cloud Internet Services）が用意されている。DDoS保護やグローバルロードバランサーの機能のほか、エンタープライズ向けメニュー（別料金）として、スマートルーティングにより最短誘導する機能やレート制限の機能も備える。
IaaSプラットフォームの特徴としては、ベアメタルサーバーもノードとしてデプロイできることを高良氏は挙げた。GPU搭載サーバーも対応しているという。共通のストレージサービスを使うことで、ベアメタルサーバーと仮想サーバーのハイブリッド構成にも対応。「ベアメタルの性能は高いが、周波数でノーマライズするとあまり変わらない」と氏はコメントした。
プラットフォームの上には、前述のとおり多数ソフトウェアがサービスとして用意されている。たとえば、Watson APIサービスなどもある。サービスは、カタログから購入すると、JSON形式で認証情報が得られて、それを登録して利用する。
IKSの使い方を解説
そしてKubernetesを利用できるIKSだ。IKSでは複数のKubernetesクラスタを管理できる。さまざまなスペックのKubernetesノードを共存可能。
ダッシュボードとしてはStandardダッシュボードとGrafanaを利用でき、ログ分析ツールとしてELKやGrafanaなどを選べる。HelmやDatadogも利用できる。
Kubernetesのバージョンアップもクリックから実行でき、1ノードずつPodを対比しながら順次バージョンアップを実行する。
ドキュメントが充実していることも、高良氏は強調した。KubernetesからIBM Cloudまで、チュートリアルやデザインパターンも含めてドキュメントが揃っているという。ICPのマニュアルも全バージョン揃っている。
最後にIKSの始め方が紹介された。「GKEとだいたい同じ」（高良氏）ということで、ログインしてIKSを選び、IKSクラスタを作成し、ローカルにCLIとIKSプラグインをインストールし、kubectlを使えるようにする手順が解説された。
JKD v18.12で聞いたサイバーエージェントのコンテナ化事例2タイプ
初日のミニセッションの枠で、サイバーエージェントでのコンテナ化事例が2セッション連続して紹介された。同社は、オンプレミスのKubernetes基盤AKEを構築していることを以前から発表している。今回は各プロジェクトでのコンテナ化の事例として、それぞれ、レガシーシステムのコンテナ化と新規システムのHelm化の体験談が語られた。
歴史の長い広告システムをKubernetesに移行
和田亨氏のセッションは「レガシーシステムのコンテナ化に挑戦した話」。歴史の長い広告配信システムの運用を、Kubernetesに移行して改善した話だ。
もともと歴史が長いシステムで、再現性がない部分もあったという。また、スケールに強いシステムにしたい、オンプレミス実行環境のロックインを避けたい、という要求もあった。さらに最新のシステムによりエンジニアのモチベーションを改善したいという意図もあったという。
既存システムでは、サービスをスケールアウトするなどの構築時はインフラチームに依頼する必要があり、スケールに時間がかかることや、オペレーションミスなどがとなっていた。また、アプリケーションをJenkinsで手動ビルドしており、約100種類のジョブでそれぞれJenkinsのプラグインを多用していて理解しにくく作り直せないという課題があった。さらに、デプロイは専用VMからcapistranoとfabricによって手動で実行していて、Jenkinsのビルド番号をメモしてコマンドを実行する必要があることや、デプロイソースは誰も触れなくなっていることが課題となっていた。
そこでとった解決策が、Kubernetesへの移行だ。スケールアウトはノードプールのスケールの変更などで素早く実行。ビルドはCircleCI Enterpriseでコンテナイメージのビルドまで実行。デプロイはビルドの後続でHelmテンプレートから実行する。
Kubernetes環境は、サイバーエージェントのKubernetes基盤であるAKEを利用する。モニタリングにはDatadogを全ノードに配置し、オートディスカバリで対象を指定する。ロギングは、従来は/var/log/app配下に出力していたものをcronでGCSに転送していたのを、fluentd sidecarでGCSに転送するようにした。
デプロイにおいては、グレースフルリスタート（サービスを止めずに再起動）が問題となっていた。特に、データベースキャッシュを作るウォームアップ処理が問題だったという。
旧デプロイ方法では、Consulでサービスディスカバリするようにしておき、一時的に外したVMにデプロイして戻すという方法をとっていた。新デプロイ方法では、ローリングアップデートするにあたって、Podを落とすときには安全に落とせるまでsleepし、Podを作るときはpostStartでウォームアップ処理をして、リッスンできるようになってからサービスに追加するという方法をとったという。
最後に、Kubernetesに移行した結果を和田氏は語った。ブラックボックスになっていた過去の夫妻を消せたこと、メンバーのモチベーションが上がってコンテナの良さが伝わったことが説明された。また、Java 8のような、ミドルウェアバージョンアップの検証が容易になったという。その一方で、デメリットとしてKubernetesの学習コストが高いことを和田氏は挙げ、「メンバー全員で習得すべくがんばっている」と語った。
マイクロサービスのデプロイをHelmで管理
山田直行氏のセッションは「ミドルウェア〜Webアプリまで全てをHelm化したサービスの運用事例」。広告関連の計測ツールという、マイクロサービスによる新しいシステムを最初からKubernetesとGCP（Google Cloud Plafrom）で構築した事例だ。
これらのプロダクトを本番環境で運用して1年半ほど。KubernetesにデプロイするリソースをすべてHelmで管理しているという。運用に便利なHelmプラグインとして、デプロイ前にYAMLの差分がわかるhelm-diffを山田氏は紹介した。
また、Helmチャートのフォルダ構成としては、アプリケーションではアプリケーションごとのディレクトリの下にhelmディレクトリを作って環境ごとのチャートを配置。ミドルウェアでは全ミドルウェアを1つのリポジトリに集約してその下で分けていることを紹介した。
動かしているKubernetesクラスタは、CI/CD、開発、ステージング、本番の4つ。マイクロサービスのデプロイはCI/CDから、ミドルウェアなどはローカルから手動で行う。
個別の実例としては、Redisでの話が紹介された。Redisクラスタのチャートを自作カスタマイズしてHelmだけで冗長構成にできていなかったところ、公式チャートを使うように変更したことで、Helmで起動や削除、向き先変更などができるようになり、構成変更がシンプルになったという。
Helmにしたメリットとして山田氏は、マイクロサービスのまとまりがわかりやすいこと、テンプレート機能、サービスを消すときに楽なことを挙げた。一方でデメリットとしては、Helmの学習が必要なことを挙げつつ、それほど複雑でないことや、makeでラップしていることなどから、それほどデメリットではないと語った。
最後に、今後の課題としては、チャートの管理や、近く来るHelm 3へのアップデートを挙げ、「楽しみだけど大変そう」と感想を語った。
JKD v18.12で、AWSがre:Invent 2018での発表をレポート
Amazon Web Services Japan（AWS）の原康絃氏によるセッションでは、前月に米国で開催されたイベント「re:Invent 2018」で発表されたAWSのサービスが、コンテナに関係するものを中心に紹介された。これからの予定についてのオフレコトークもまじえながら、AWSの人ならではの詳細が語られた。なお、本記事ではオフレコの内容は扱わない。
DNSやロードバランサに頼らずサービスディスカバリ
最初に紹介されたのは「AWS Cloud Map」。クラウドリソースのサービスディスカバリを実現するマネージドサービスだ。
サービスディスカバリとは、アプリケーション等から依存リソースにアクセスするときに、相手を指定する方法だ。最も古典的な方法として、IPアドレスでアクセスすると、クラウドではリソースのIPアドレスが変わって困る。その解決策として、ロードバランサーやDNSを利用してサービスディスカバリをすることが行なわれている。
ただし、SQS（Amazon Simple Queue Service）などでは、これらの手段が使えない。これを解決するのがAWS Cloud Mapだ。
AWS Cloud Mapでは、ARN（Amazonリスース名）や、任意に付けた論理名、特定の属性などで対象をディスカバリする。Route 53ヘルスチェックを利用した正常な状態のリソースのディスカバリもできるという。対象はすべてのクラウドリソースで、IAMによる権限制御などもできる。
AWSのECS、Fargate、EKSで使えるほか、KubernetesのExternalDNSや、Istio、Consulなどでも対応するという。
価格は、登録1つにつき$0.10/月で、ディスカバリAPIコールが100万回で$1.00。原氏は、サービス登録方法などもまじえて説明した。
サービスメッシュApp Meshは、フィードバックを得て作り込む
続いて、マネージドサービスメッシュの「AWS App Mesh」だ。マイクロサービスで使われるもので、「Amazonも20年間、マイクロサービスでやってきた」と原氏。
マイクロサービスの課題として、サービスが正しく他のサービスと通信できるように設定するには、複雑に連携したシステムからどのように問題箇所を見つけるか、問題が他のサービスに影響するには、といった点を原氏は挙げた。そしてこれらの課題を、プログラミング言語や通信プロトコルの違いなく解決する必要がある。
AWS App Meshではこれを解決するために、サイドカー方式のプロキシのEnvoyを採用した。なお、EnvoyはIstioでも使われている。
AWS App Meshは、Amazon CloudWatchやAWS X-RAYなどのモニタリングやトレーシングのサービスと連携する。Envoy対応のサードパーティとも連携できる。
現在はPublic preview段階で、機能もかなり絞り込んでいるという。コンソールはなく、FargeteやCloud Mapなどにも対応していない。原氏によると、「サービメッシュのユースケースはまだ少なく、その状態で作り込んでも使われ方に合わなくなる。フィードバックをもらいながらいいものにしていく」とのことだった。
ECSやEKSの新機能も
そのほか、Amazon ECSでは、CodeDeployでBlue-Greenデプロイメントが可能になった。従来はローリングデプロイメントのみだった。Lambdaフックもあり、Lambdaを介してロールバックなどもできる。CodePipelineからも利用できる。
マネージドKubernetesサービスのAmazon EKSでは、ALB（Application Load Balancer）サポートが追加された。
ほか、コンテナのマーケットプレースのAWS Maerketplace for Containerや、軽量ハイパーバイザーのFirecracker、オンプレミスでECSやEKSを使うAWS Outpostについても、原氏は言及した。
JKD v18.12、LINEの機械学習モジュール運用基盤Rekcurd
LINEの服部圭悟氏によるセッションは、同社のスマートスピーカーClovaなどで使われる機械学習がテーマ。開発した機械学習モジュールをKubernetesにデプロイし、管理と運用を簡単にする「Rekcurd」について解説した。
ちなみに、Rekcurdは、もともとDruckerという名前で開発されていたのが、都合により逆さ読みに変わったという。
機械学習モジュール開発者とインフラ担当のギャップ
Clovaでは、呼びかけをデバイスが認識すると、その音声情報をクラウドに飛ばして言語解析にかけ、結果をスキルに渡す。この中でたくさんの機械学習モジュールが使われている。こうした機械学習モジュールは、ほぼすべてRekcurdを使って運用しているという。
服部氏は、機械学習モジュールを実運用するにあたっての問題点を語った。1つは、開発者自身が運用管理をする場合。インフラや運用に関する知識が乏しいとともに、サービスにはりついてトラブル対応などに時間をとられて機械学習モジュールの開発に注力できなくなる。
もう1つは、インフラ担当に運用を任せる場合。中身や仕様がわからない状態で渡されて、サービスの更新やトラブルのたびに開発者と運用担当者で連携をとる必要がありコミュニケーションコストが大きくなる。
この問題を解決するのがRekcurdだ。「すごく便利でも、追加の作業をあると使ってもらえないので、それをなくす。だれでも簡単に機械学習モジュールを使える、誰でも簡単に運用管理できるようにする」と服部氏。
Rekcurd、Rekcurd dashbord、Rekcurd clientの3つ
Rekcurdシリーズは、機械学習モジュールの配信を簡単にする「Rekcurd」、機械学習モジュールの管理と運用を簡単にする「Rekcurd dashboard」、既存のシステムへの統合を簡単にする「Rekcurd client」からなる。
1つめのRekcurdを使うと、機械学習モジュールがgRPCサービスとして動く。Pythonから、WebアプリケーションフレームワークのFlaskに似た書き方により、gRPCを知らなくても使える。KubeflowのSeldonを意識して作ったという。
2つめのRekcurd dashboardは、Rekcurdで作ったサービスを一元管理する。YAML不要で、WebUIから、新しいモデルのアップロードやバージョニング、切り替えが簡単にできる。服部氏は、Rekcurd dashboardからモデルのアップロードや切り替えなどをする手順を、スクリーンショットを使って説明した。
3つめのRekcurd clientは、SDKのような位置付けで、URLを指定するとgRPC specに自動で変換する機能などを持つ。
「Kubeflowじゃダメなの？」
ここから服部氏は、想定問答形式で説明した。主なところでは、KubernetesクラスタはRancherで構築した。監視や冗長構成、デプロイはKubernetesの機能を使い、Rekcurd dashboardから設定すれば全部やってくれるようになっている。サービスレベルでサーバーを分けるには、Kubernetesの機能でノードにサービスレベルのラベルを付けて、合うノードで動かす。
機械学習モデルのデータは大きいので、MySQLや、AWS S3互換のプライベートオンラインストレージに置く。「隣の人にも見せたくない」というようなセキュリティについては、認証制御を作っている。
「Kubeflowじゃダメなの？」については、「いいと思うが、まだいろいろ足りていない」という。まだTensorFlowのみであり、前処理や後処理は別のスコープであり、WebUIなし、KubeflowやgRPCなどの前提知識が多数必要で、「誰もついてきてくれない」と服部氏はコメントした。
Linus Torvalds氏やMitchell Hashimoto氏が登場 〜Open Source Summit Japan 2018 （2018年6月20日・22日取材）
The Linux Foundation主催の技術カンファレンス「Open Source Summit Japan 2018」が、2018年6月20日〜22日に開催された。公式発表によると、Open Source Summit Japan / Automotive Linux Summit Japan 2018の参加者数は1000名以上。
ここでは、20日のキーノートの後半と、22日のキーノートをレポートする。
（このレポートは「Open Source Summit Japan 2018開幕 Jim Zemlinの講演に続きAGLやHyperledgerの事例を発表」の続きです）
LinuxカーネルのSpectre対策で大変だった点は
20日のキーノートの後半では、Linuxカーネルのコア開発者としてThe Linux Foundationに所属し、stableカーネルのメンテナーでもあるGreg Kroah-Hartman氏（通称Greg K-H）が登壇。今年初頭から各種OSを騒がせたSpectre/Meltdownと呼ばれる一連の脆弱性について、Linuxでの対応をまじえて解説した。
Hartman氏はこの問題について、CPUのハードウェアのバグで現代的なCPUに共通するものであること、アプリケーションが正しいコードでも防げないこと、CPUの投機的実行を悪用したものであることなどを概説した。
Spectreは現在、1〜5の番号が付けられたvariant（変種）が発見されている。ちなみに、このうちvariant 3がMeltdownとも呼ばれる。
variant 1は境界チェックの回避だ。たとえば、配列の終わりをチェックしながら1つずつ値を読み取るような場合、CPUは範囲チェックより先にメモリを読んでキャッシュに入れるため、キャッシュの有無から値を推定できるというものだ。
Linuxカーネルでは、範囲チェックにarray_index_nospec()マクロを用意して、該当箇所をこれで置き換えることで対応した。最初は遅くなるものだったが、後からLinuxハッカーたちが最適化して、アセンブリ言語の簡単な命令になっているという。
Linuxカーネルでは、x86で1月に、ARMで2月に対応。それ以前のカーネルはアップデートするようHartman氏は呼び掛けた。
variant 2は、CPUの分岐予測を悪用したものだ。これは、コンパイラ、カーネル、マイクロコードのアップデートで修正がなされている。Linuxカーネルでは、x86は3月に修正。ARMは関係ないと思うが、確かなことはわからないという。
Meltdown（variant 3）はユーザー空間からカーネル空間のメモリを読めるもの。KPTIやKAISERなどの修正が順次作られており、I/Oヘビーなシステムでは対策による性能への影響が見られるが、新しい修正ほど性能が大きく向上しているという。
Meltdownは、Linuxカーネルのx86では1月上旬に修正がなされた。ARMでは2〜4月に修正がなされたが、x86と違う方法で修正がなされているという。
なお、Meltdownのさらに変種のvariant 3aもあり、これもMeltdownの修正で対策されている。
variant 4は5月に公表された脆弱性で、「もうみんな慣れてセンセーショナルには扱われなかった」とHartman氏。ほとんどマイクロコードの問題で、カーネルにも少しの修正がある。Linuxのx86では5月に修正、ほかのCPUは問題ないと思うが確かなことはわからないという。
variant 5は、2018年6月に公表されたばかりの脆弱性だが、Linuxでは2016年に気付いて修正しているという。Linuxカーネル4.4には、2018年に追加でバックポートされた。
さて、なぜSpectreが大きな問題だったか。それはCPUのバグだったから、とHartman氏は説明した。すべてのOSに影響し、対策によってパフォーマンスが落ちた。CPU製品にも何年か影響するし、今後も報告や対応が続くだろうという。
また、この脆弱性は公表される以前に、CPUの会社から各種ベンダー企業には情報が行ったが、Linuxカーネル開発者にはなかなか来なかったのが困ったという。また、クラウドプロバイダーは商用ディストリビューションのLinuxカーネルを使わず、コミュニティカーネルを元にした独自カーネルを使っていたことも、遅れになったという。こうした情報体制が変わることを期待したいとHartman氏は語った。
最後にHartman氏は、Linuxカーネルを使う側の心得を挙げた。まず、パッチをつまみ食い（cherry-pick）せずに、stableカーネルのアップデートをすべて適用すること。また、カーネルのハードニング機能を使うこと。できればハードニングなどの対策が追加された新しいバージョンのカーネルを使うこと。そして、マイクロコードやBIOSもアップデートすることだ。
HelmのCNCFプロジェクトへの道
Microsoft Azureのシニアソフトウェアエンジニアであり、HelmやDraftのコアメンテナーでもあるMichelle Noorali氏は、Helmの必要性やCNCFプロジェクト入りの経緯、Draftについて語った。なお、Noorali氏は冒頭で「私はもともとRubyのプログラマーで、Rubyは日本のMatz（まつもとゆきひろ）氏が開発した言語」と自己紹介した。
Kubernetesについてはもともと、3年前に自社の課題に使えないか調べはじめたという。それは、コンテナアプリケーションを信頼できるやりかたでスケールさせるという課題だ。そこで、コミュニティに参加して調べ、安定して持続可能だろうと判断したという。
Kubernetesでは、マニフェストファイルで定義してやると、コンテナのクラスタを動かし、面倒を見てくれる。ただし、アプリケーションを動かすためにはマニフェストの記述が多数になるとして、Noorali氏は例を見せた。
そこで、Kubernetesで動かすアプリケーションのマニフェストを「チャート」としてパッケージングして再利用できるようにし、共有させるツールがHelmだ。これがコラボレーションを促進する、とNoorali氏は説明した。
Helmも大きく成長している。このように開発コミュニティが大きくなってくると、スケールの問題が出てくる、とNoorali氏は言う。メーリングリストやSlackなどのコミュニケーションチャンネルを管理したり、カンファレンスを開いたりと、技術的でない課題も増えてくる。
そこでHelmのコア開発者たちが話し合い、CNCFに入ってプロジェクトをホストしてもらうことを決めた。プロポーザルを書いて手続きし、受け入れられて、5月末にCNCF入りが発表された。「いまはそのための事務作業中で、非常に楽しみにしている」とNoorali氏はコメントした。
もう一つ、人が集まり始めたプロジェクトとして「Draft」も紹介された。アプリケーションをコンテナ化してHelmでデプロイするまでの何度もやるプロセスを自動化するツールだ。Draftは1.0の前に人気が出た例だ、とNoorali氏は説明した。
Draftのデモも壇上でなされた。APIサーバーのアプリケーションと、それを呼ぶWebアプリケーションとを、それぞれDraftでデプロイして動かし、Webブラウザーでアクセスしてみせた。
最後にNoorali氏は、CNCFにはすばらしいツールやサンプル、ガイドラインが揃っていると説明。ライセンスや行動規範なども紹介しながら「みなさんが新しいドアを開けられたらと思う」と語った。
SUSEとNECも講演
SUSEのThomas Di Giacomo氏（CTO）とTroy Topnik氏（Product Manager, Cloud Application Platform）は、PaaS基盤ソフトCloud FoundryのディストリビューションであるSCF（SUSE Cloud Foundry）をデモした。
講演のタイトル「Better Together」は、Clouf FoundryとKubernetesをつなぐという意味だ。デモでは、Helmを使ってKubernetes上で動かしたSCFで、サンプルアプリケーションをSCFにデプロイして動かした。さらにSCFから同じアプリケーションをIBM Cloudにもデプロイしてみせた。
NECのKeiichi Seki氏は、同社のOSSへの取り組みを紹介した。NECではオープンソースへの取り組みを、Operation、Community、Governanceの3つで考えているという。
プロジェクトとしては、以前からLinuxやOpenStackなどにコアメンバーとして参加している。OpenDaylightやOPNFV、ONAPといったネットワークや通信のプロジェクトにも参加。KubernetesやHyperledgerなどの新しいプロジェクトにも参加している。Seki氏は「エコシステムが大事だと思っている」として「われわれはコミュニティに貢献していく」と語った。
Linux Torvalds氏「退屈なのがいちばんいい」
Linus Torvalds氏のキーノートは、いつものようにカーネル開発者のDirk Hohndel氏（VMware）との対談形式で行われた。
「いつもと同じ質問から始めます」と前置きしてHohndel氏は、RC版としてリリースされたLinux 4.18-rc1について聞いた（なお、rc2は6月24日にリリースされた）。これに対してTorvalds氏は「コンスタントな開発ができるように考えていて、順調に続いている」と回答した。「毎回リリースごとにだいたい1万以上のコミットがあり、今回のリリースも前回と違わない。今回で違うのは、消した行が多かったことぐらいだ」。
メンテナーのトラブルについてHohndel氏が聞くと、「単純なミスだ」とTorvalds氏。「新しいコードを受け付ける期間のあとにバグフィックスのみの期間を設けているが、みんなバグを直すより新しい機能を作るほうが楽しいので、バグフィックスと称して新しいコードを遅りたがる（笑）。それできつい言葉を使うこともある」。
とはいえ、この数ヶ月には特別な状況としてSpectre/Meltdownの問題があった。これについて「この問題は投機的実行を用いたものだ。私はCPUに興味があるので、本当は興味深い攻撃だ」とTorvalds氏。「しかし、秘密裏に進められたのはフラストレーションを感じた。一部の人たちだけが問題を知り、コミュニケーションがないことが分かってしまった。その後、問題が公表されて、メーリングリストで公に議論できるようになった」と不満を訴えた。
日本のOpen Source SummitはAutomotive Linux Summitと共催となっている。それにちなんでHohndel氏は自動車でのLinuxの信頼性について質問した。これについてTorvalds氏は「小さいシステムのほうが問題が入り込みにくいが、現在では自動車でもネットワークを使うようになってきており、小さな組み込みシステムでは済まなくなっている。Linuxは長年やってきてテストされているので、信頼できると思う」と答えた。
ここでHohndel氏は、「『Linus Torvaldsの作ったものでいちばん影響があるのはLinuxではなくgitだ』という記事を見た」と苦笑混じりに話題を振った。Torvalds氏は「このあいだ、git bisect（どのコミットで問題が混入したか探す機能）がなかった時にはどう開発していたのか、不思議に思った」とgitの有用性を自ら認めた。「gitを始めたときには乱暴で使いにくいと言われたものだったが、慣れてくるとみんな使うようになった。これには私も驚いている」。
gitの開発は、Torvalds氏が始めたあと、Junio Hamano（濱野純）氏が引き継いだ。「彼が大変なところをぜんぶやってくれた」とTorvalds氏は語る。「gitは大きなものになったが、考え方はシンプルだ。コアになる共通の考え方があり、その上に細かいツールが乗る。これはUnixやLinuxと似ている」
Hohndel氏はさらに、GitHubの成功についても話を広げた。「GitHubの成功は、gitのためのインフラが必要だったからでは」とHohndel氏が質問すると、Torvalds氏は「YesでありNoでもある。インフラが必要というのは正しいが、gitは分散バージョン管理システムだ。git以前は集中型バージョン管理システムが多かったが、それだとプロジェクトの場所を1箇所に決める必要があるので、GitHubのようなインフラは使いづらい。gitであればプロジェクトの場所が関係ないので、GitHubが好きに使える」と答えた。
これについてHohndel氏がさらに「GitHubが世界の中心でなくていい。つまり、Microsoftが買収しても何も変わらないということですね」と聞くと、Torvalds氏は「それがgitのメリット。コントロールで競争するのでなく、よいもので競争する」と答えた。
話題は再び変わって、Linuxやgit、さらにSubsurface（Torvalds氏がHohndel氏らとともに開発しているスキューバダイビング用ソフト）の次の新しいプロジェクトについてHohndel氏は質問した。Torvalds氏は「新しいものは好きじゃない（笑）。いつも、自分には欲しいけどほかの人が作っていない、というネガティブな理由で始めた。3つのプロジェクトを始めて、もうこれで十分なので、ひとつのことに集中したい」と答えた。
なお、ほかに興味のあることしては、「コンパイラに興味があったし、FPGAで新しいハードウェアを設計して作るのにも興味があるが、時間がない」という回答だった。
Linuxカーネルの方針に「ユーザーのコードを壊さない」というものがある。Linuxカーネルのバージョンを上げたときに、その上で動くソフトウェアが動かなくなることがないようにするということだ。これについてHohndel氏が質問すると、Torvalds氏は「開発者は機能を変えるのがいちばん楽しいが、使うユーザーが求めるのはいままでと同じことができることだ。退屈なのがいちばんいいことだ。私がメールで暴言を書くのはたいてい、誰かが何かを壊して、直さなくていいでしょうと言っているときだ」と発言した。
とはいえ、Linuxが機器に組込まれるようになると、使われる期間は長くなる。「安定したバージョンが必要ということで2年前のカーネルを製品に採用して、その製品が5年使われると、7年前のコードに依存することになる。その時点で7年前のコードを直してくれと言われても困る。早い時点で言ってくれれば対応できるのだが。それを組み込みの人に言いたい」（Torvalds氏）
最後にHohndel氏は「来年のこの場所で話すこと」を尋ねた。Torvalds氏は「こうなったらうれしいこと」として、「ARMアーキテクチャはさまざまなプラットフォームで動くのが、ハードウェア屋さんにとってはアドバンテージだが、それがカーネル開発者には厳しい。来年には、全ARMシステムでブートが標準化されるのを期待している」と語った。
Mitchell Hashimoto氏「ありがちな失敗は、従来型とクラウド型のミスマッチ」
Mitchell Hashimoto氏は、企業のクラウドへの移行で問題になることについて語った。氏は「ソフトウェアを使うのは簡単。大事なのは考え方を変えること。クラウドにもそれがいえる」と冒頭で述べた。
Hashimoto氏は、「クラウド」「マイクロサービス」「スケジューラー」の3つを順に来ている主流トレンドとして挙げた。
基本になるのがクラウドだ。Hashimoto氏はクラウドのメリットを、最小限から使用量に合わせて使えること、APIファーストで作られて自動化できること、グローバルに分散すること、高価値のサービスが用意されること、低コストで拡張できることとした。
次にマイクロサービス。そのメリットとして、1つのソフトウェアの担当範囲を小さくしてクオリティを上げられること、標準化されたコンピュータインターフェイス、開発とデプロイの並行化、パーツごとにアップデートできてセキュリティにもいいことが挙げられた。
スケジューラーは3つの中で最新のものだ。さまざまなアプリケーションを統一してデプロイし、リソースの利用効率を上げ、自動復旧やスケールアウトを実現する。
さて、その次にハードルとなるのは、運用、セキュリティ、ネットワーク、開発の4種類の人がみな仕事をクラウドに切り替える必要があることだ。「馬から自動車に変わったときのようなものだ。自動車を単にいい馬として扱うと、メリットを生かせない」とHashimoto氏は言う。
運用の人の場合、従来型のスタティックなモデルでは専用のサーバーをあらかじめ必要な量用意する形だが、クラウドのダイナミックなモデルではオンデマンドで無限のスケールとなる。セキュリティの人の場合、従来型ではファイアウォールなどの境界線で区切るIPベースのセキュリティだが、クラウド型では境界線がなくアイデンティティベースのセキュリティとなる。ネットワークの人の場合、従来型ではホストベースでスタティックIPアドレスで構成したが、クラウド型ではサービスベースでダイナミックIPアドレスで構成する。開発の人の場合、従来型ではアプリは専用のインフラ上で動くが、クラウド型ではどこでも動く。
「ありがちな失敗は、たいてい技術ではなく、従来型とクラウド型のミスマッチが原因だ」とHashimoto氏は述べ、2つのパターンを紹介した。
1つめのパターンは、運用だけクラウド型にして、ほかの3つは従来型のままなケースだ。「これはよくある。クラウドに移ったけど、ほかは同じにして成功、と言っているケースだ」とHashimoto氏。
この場合に問題になるのは、クラウド上で従来型のネットワークやセキュリティ、開発を実現するために、たくさんのVPCや山ほどのサーバーなど、必要ないインフラがたくさんできることだとHashimoto氏は指摘する。また、開発スピードにもボトルネックが生じる。
2つめのパターンは、ほかの3つがクラウド型に移ったのにセキュリティだけが従来型のケースだ。この場合に問題になるのは、すばやくデプロイできるようになったのに、セキュリティのレビューの時間がかかって、アプリケーションのデプロイが遅くなることだ。
このパターンに銀行での事例があったとHashimoto氏は紹介した。従来型のセグメントベースのセキュリティとクラウド型のセキュリティを両立させてコストが倍になる。また、アプリケーションをデリバリーするためにたくさんのファイアウォールの設定を変え、そこに時間がかかることにもなっていた。この事例ではセキュリティもクラウド型のロールベースモデルに変え、ファイアウォールをとめることで、時間とコストを削減したという。
最後にHashimoto氏は、こうしたクラウド型のモデルをすべて可能にするのは、KubernetesやTeraform、Ansibleといったオープンソースの力だと説明。さらに、「新しいモデルを採用すればみなさんの会社も新しいことに成功する」と語った。
AGLのIVIへの取り組み
Automotive Grade Linux（AGL）プロジェクトに参加するマツダ、スバル、スズキの3社によりIVI（In-Vehicle Infotainment、車載インフォテインメント）への取り組みに関する講演も行われ、それにホンダとトヨタを加えた5社が壇上に立った。
マツダのSeiji Goto氏は、AGLにおけるIVIの取り組みを解説した。
IVIでは非競争領域をAGLで共通化して問題を解決しようとしているという。「リファレンスボードに比べて製品ははるかに複雑で、そのギャップが発展を阻害している。そのギャップを小さくしようとしている」とGoto氏。
2017年に、「AGL Reference Hardware Specification」の規格を出した。ここでは、共通の部分をメインボードにし、違う部分を拡張ボードにする。
次のコンセプトとして現在議論中なのは、組み合わせて使える「レゴブロック」だ。実際の車に搭載できるように2DINサイズを目指すという。
スバルのShinji Tsunoda氏は、プロジェクトのスケジュールを紹介した。リファレンスハードウェアの1stステップは、2019年上半期まで。そのあと2ndステップに移行する。
1stステップでは、メインボードにルネサスのRenesas R-Car Gen3 Startar Kitとインテルのボードを、拡張ボードにシマフジのKingfisher AdvancedとKingfisher Standardを用いる。
スズキのToshihisa Haraki氏は、2ndステップを紹介した。2ndステップではできるだけいろいろな種類のメインボードと拡張ボードを作る。また、メインボードと拡張ボードの間は、1stステップでは特殊なインターフェイスだが、2ndステップでは共通のインターフェイスにしたいという。
登壇者の平均年齢は77歳〜シニアプログラミングネットワーク レポート（2017年4月29日取材）
高齢者のプログラマーが登壇するパネル形式のイベント「シニアプログラミングネットワーク #1」が、2017年4月29日に渋谷で開催された。主催は、Code for Japan、イベントスペース dots.、日本NPOセンター。
シニア向けのゲーム「hinadan」がTVなどのメディアで取り上げられた若宮正子氏、iPhoneアプリをApp Storeで3本リリースしている鈴木富司氏、ボードコンピュータのIchigoJamで制御する檻でイノシシ90頭をしとめた谷川一夫氏という、平均年齢77歳の登壇者の話を聞きに、老若男女が集まった。
目的から入って半年で作ったhinadan
若宮氏は、60才からパソコンを始め、2016年からプログラミングを始めた。シニア向けにスマートフォンを教えていてCode for Japanの小泉勝志郎氏と知り合い、2016年7月に突然「Swiftはじめました」とメッセージを送って小泉氏を驚かせたという。約半年後の2017年3月3日に開催される「電脳雛祭り」に出すというスケジュールで、SkypeとMessengerのリモート教育により、小泉氏からプログラミングをイチから教わった。目的から入ったことと、そのために必要なこと以外は省いて教えたのが成功したポイントだと小泉氏は言う。
「年寄りが若者に勝てるゲーム」というコンセプトで作られ、「スマホを使ったことのないお爺ちゃんお婆ちゃんがやってくれるのがうれしい」という。海外でも紹介され、韓国のNAVERのカンファレンスに招聘されて「I want to be creative」という題で講演した。
若宮氏の言葉では、ユーザーインターフェイスについて「年寄りは指が震えるからドラッグ＆ドロップはよくない。また、タップが長押しになってしまうのも注意が必要だ」というのが印象的で、会場からも「なるほど」という声が聞こえた。
応援者を前提にしたアプリの構成
鈴木氏は、「定年後をアプリで楽しむ」と題して、国際的に活動してきた自身の人生とアプリ開発をからめて語った。iPhoneアプリ開発は一度手を出して挫折したものの、2016年から再チャレンジして、独学でSwiftを学んだという。
作品「スマホの勉強シリーズ」もデモした。「初心者はiPhoneの設定は無理」というコンセプトにより、若い応援者に頼むのを前提に、応援者向けの説明を入れているという点の会場の感心を集めた。孫に聞くのは嫌だという声や、教える側も何度も聞かれるのは嫌だという声を聞いたのが元になっているという。また、年配者用アプリの心がけとして、「タップという単語は避ける」「文字は大きく」「できるだけ動画で説明」などの工夫も語られた。
なお、鈴木氏も若宮氏も、英語に抵抗がないことがひとつの成功要因だったという分析も、小泉氏から出た。公式文書やエラーメッセージなどは英語であり、さらにApp Storeとの交渉も英語になるというわけだ。
IchigoJamでイノシシ90頭を捕獲
福井県の谷川氏がIchigoJam制御の檻を作ったのは、イノシシが農地を荒らしたり住居地に出没したりといった問題に対応するためだという。イノシシは警戒心が強いとのことで、警戒心なく檻に入らせて扉を閉めるために、センサーによる方式を選んだ。
たまたまPCN（プログラミンググラブネットワーク）の勝山クラブで小学生が触っていたIchigoJamを知ったという。老眼でのハンダ付けに苦労しながら、センサーやモーターを取り付けてプログラミングをしたとのこと。猟友会による実験を経て、現在65個の檻を設置して、90頭を捕獲した。
谷川氏の講演は、事前の話題性も高く、見知らぬ世界の話に当日の参加者の関心を集めていた。
アプリに町民の声を反映
hinadan以前の若宮氏の活動として、Code for Japanの福島県浪江町の話が、当時復興庁で浪江町にいた現Code for Japanの陣内一樹氏との対談で語られた。福島原発の近くにあり一時は全町避難となった地域で、町民の絆の維持や町からの情報発信、生活の質の向上のためにアプリを開発した。「行政がアプリを作るとたいてい失敗する」という陣内氏の意見から、町民インタビューをもとにペルソナを作成し、ハッカソンで開発してもらった。
アプリのプロトタイプは町民が評価したほか、若宮さんを招いてレビューしてもらい、けっこう厳しい声も出たという。たとえば、「随時配信だとお年寄りはかえって混乱する」という声から毎日夕方に配信する新聞形式で情報を発信した。さらに、写真投稿コーナーでは、コメントで個人的なやりとりが盛んになったり、複数枚の写真を1枚にまとめるときの加工方法が流行したりと、当初想定していなかった使い方もなされたという。
年配の人がアプリを使うには、作るには
最後に、ここまで登壇した全員によるパネルディスカッションが開かれた。年配の方にとってのアプリの使いやすさや、プログラミングの始め方などの話題が語られた。
スマホでの文字入力への苦手意識から、音声入力に興味を示すという話が出たが、一方で方言がきついと認識されないという壁も語られた。また、みな文字入力より写真が好きという声もあった。
プログラミングをこれから始める人に向けては、「まず簡単なものを作って、それが動くと、感動になって次につながる」という声や、「『子供でもできる』というような誘い方はしたくない。やはり難しいので、継続していくことが重要」という声があり、小泉氏は「共通しているのは、作りたいものがあるというモチベーション」とまとめた。
Ruby誕生25周年を祝うカンファレンス「Ruby25」開催（2018年2月24日取材）
プログラミング言語「Ruby」の誕生25周年を祝うカンファレンスイベント「Ruby25」が、2月24日に東京で開催された。Rubyの生みの親である“まつもとゆきひろ”（Matz）氏を中心とする講演のほか、Rubyに関する企業や団体などの展示もなされ、参加申し込みが三百数十人集まる、大規模で祝賀ムードにあふれるイベントとなった。
まつもと氏が基調講演で語ったことによると、新しいプログラム言語を作るプロジェクトを始めるにあたって「Ruby」という名前を付けた1993年2月24日をもって誕生日としたとのことだ。Rubyに関するカンファレンスは世界中で開催されているが、まつもと氏から開こうと言ったことはこれまでなかったという。「今回は、私が軽い気持ちで『お祝いしよう』と言ったら、スタッフやスポンサーの尽力で、こんな大きなカンファレンスになった」とまつもと氏は笑顔で語った。
以下、カンファレンスの模様を順にレポートする。
皆が仕事でRubyを使う時代に
開会にあたって、Ruby25副実行委員長であり、まつもと氏の勤務先の株式会社ネットワーク応用通信研究所（NaCl）の代表取締役社長である井上浩氏が開会挨拶をした。また、経産省 商務情報政策局 情報産業課 課長の成田達治氏（企画官 和泉憲明氏による代読）と、筑波大学大学院システム情報工学研究科コンピュータサイエンス専攻長 教授の加藤和彦氏が祝辞を述べた。
NaClの井上氏は、1997年にNaClが事業を開始した年に、まつもと氏が主任研究員（現在はフェロー）として参加したことを紹介。思い出として、1999年にIPAの助成事業としてApacheのmod_rubyを開発したときのエピソードを語った。
また、会場に「仕事で少しでもRubyに関わっている人は」と質問し、多くが挙手するのを見て、「かつて、最初のRubyKaigiで同じ質問をしたときは、パラパラ程度だった。そのときに『この先、みなさんが主役になるでしょう』と言ったが、まさにその時が来た」と感慨深く述べた。
経産省の成田氏（代読和泉氏）は、ソフトウェア業界の人材不足やサービス型への転換などの課題に対して人材育成の必要性を挙げ、Rubyはこれまで人材を育成してきて、これからも育成していくだろうと述べた。そして、ビジネスアイデアをスピーディに実現するのはRubyの得意などころだと思うので、これからも魅力的なサービスを作っていってほしいと語った。
筑波大学の加藤氏は、筑波大学でまつもと氏の2〜3年上の先輩にあたり、在学中の接点はなかったが交流のある研究室にいたことを紹介。さらに、プログラミング言語マニアとして、すべてがオブジェクトのSmalltalk 80や、折衷型のC++やJavaを経て、すべてオブジェクト指向でありながら汎用的に使えるRubyをすごいと思ったと語った。そのうえで、「Ruby以後の言語は何らかの形でRubyの影響を受けていると思う」として、「その性質は継承されるようで、Ruby上のRuby on RailsやSinatraは以後のWebフレームワークに影響を与えた」と論じた。
Rubyに関わりの深い地域の首長からの祝電も読まれた。福岡県知事の⼩川洋氏は、フクオカRuby⼤賞やmrubyの取り組みを紹介して25周年を祝った。松江市⻑の松浦正敬氏は、Ruby PrizeなどのRubyコミュニティへの支援や、Rubyを学ぶ環境作りなどの取り組みを紹介して25周年を祝った。島根県知事の溝⼝善兵衛氏は、mruby/cやSciRuby、Rubyアソシエーションなどの支援を紹介して25周年を祝った。
Railsの開発とともにRubyのエコシステムが構築された
特別講演には、「Rubyの1/4世紀」と題して、一般社団法人 日本Rubyの会 会長の高橋征義氏が登壇。25年の歴史を、5年ごとに区切って振り返った。ちなみに高橋氏は冒頭で、Rubyを世界的にメジャーにしたRuby on Railsの1.0正式版リリースが2005年で、「ちょうど真ん中ぐらいになることに気づいた」と紹介した。
高橋氏はRuby年表をGitHubリポジトリで公開している。氏はこの歴史を5年ごとに分け、それぞれ「誕生」「認知」「転換」「発展」「普及」と名付けて解説した。
誕生期としては、まずRuby誕生の1993年。この年は、芸能界ではtrfや小沢健二、Judy and Maryがデビューし、映画「ジュラシックパーク」が公開された年だ。1994年には非公開MLとFTPで活動し、1995年12月21日にNetNewsのfj.sourcesに公開された。
NetNewsという限られた人の世界から一般公開されるメディアに取り上げられたのは、1997年9月22日の「INTERNET Watch」（インプレス）の記事だったという。その後、同年10月に「TRY!PC」誌（CQ出版）11月号には、「ちょーわかりやすい！Perl & ruby入門」も掲載。同年に「オンラインソフトウェア大賞97」に入賞し、この頃ぐらいにプログラミング言語に興味ある人にリーチしたようだと高橋氏は語った。
続く1998年〜2002年が認知期だ。1999年にはruby-lang.orgドメインを取得。そして、Rubyに関する最初の書籍「オブジェクト指向スクリプト言語Ruby」が刊行されて、広く知られるようになった。
さらに2000には米国でDave ThomasとAndy Huntによる書籍「Programming Ruby」が刊行されて海外で存在が知られるようになり、2001年には米国でイベント「RubyConf」が開催された。
続く転換期（2003〜2007年）は、Ruby on Rails（略してRails）の影響が大きく、「RailsがいかにRubyのエコシステムを変えたか」を高橋氏は語った。
この時代は、Webマガジン「Rubyist Magazine」で「現在のRubyのパッケージ管理には標準はありません」と書かれていたという。そこに、多数のライブラリを必要とするRailsが登場し、RubyGemsを採用したことで、RubyGemsが公式的な位置づけになっていった。
また、2010年には、目的のソフトウェアが必要とするライブラリのインストールを管理するBundlerがリリースされて、Rails 3.0でサポートされた。この2つの例などを例として挙げて、「Railsの開発と同時にRubyのエコシステムが構築されてきた」と高橋氏は論じた。
最後に25年のまとめとして、高橋氏は書籍「エラスティックリーダーシップ」日本語版にまつもとゆきひろ氏が書いた文章から「専門家はいない。私たちしかいないんだ」というフレーズを引用。そして、「草の根で始まった言語であり、個人の集まりがが手探りで始めて、ここまで来た」と語った。
また、組織の貢献として、その個人やインフラを支えるさまざまな活動を紹介。「Rubyを個人が支えて、その個人を組織が支えている」とRubyの開発の姿について高橋氏はまとめた。
Ruby 3では大きなギャップを作らない
まつもとゆきひろ氏の基調講演は、「Ruby after 25 years」という題で、これまでの25年の変化を元にこれからの25年を語るものだった。
氏はまず、これまでの25年について「ラッキーだったことに、Ruby関連の変化は驚くほど小さい」とまとめた。OSはUNIX系に収斂し、CPUはほぼx86系（一部ARM）となった。Rubyを開発しているマシンやOSは少しずつ変わったが、劇的には変わらず、「一部はこの安定性に救われた」という。
一方で変化したところとして、性能、容量、価格、台数をまつもと氏は挙げて、プログラマーが楽になる変化だとした。応用分野の変化については、Web、モバイル、クラウド、マルチコアを挙げ、そのポイントとしてスケールや分散が語られた。
これをふまえて、未来のRubyについてまつもと氏は考察した。まず、「言語の文法といったコア部分については、それほど変わらないのではないかと思う」と語る。そして「進化の方向は、基本的に生産性を向上させるもの」という仮説を掲げる。そして、求められるのは「より早く、より安く、より速く」だという。それに必要なものとして、「高度な分散」「高度な抽象」「高度な支援」の3点を挙げた。
ここから、来たるべき「Ruby 3」について話が進んだ。目標は、高速、分散、（静的）解析だという。そして、それぞれのためのプロジェクトとして「MJIT」「Guild」「Steep」の3つをまつもと氏は紹介した。
MJITは、RubyにJIT（Just-In-Time）コンパイルを組み込むものだ。まつもと氏は、2015年に、Ruby 3では3倍高速化する「Ruby 3x3」というキャッチフレーズを掲げたことに触れ、「Rubyが生き残るには、わくわくするテーマ、できるかもしれないけど難しいゴールが必要だと思った」と語った。そして、「言ってみるもので、JITによるスピード改善を作った人や、それをブラッシュアップして取り込んでくれる人がいた」と報告した。
Guildは、分散処理の枠組みだ。これにより、マルチコアやマルチノード、マルチデータセンターにつながる可能性が出てきたと、まつもと氏は説明した。
Steepは、Rubyの静的型推論の仕組みだ。Rubyの型推論としてはそのほか、統合開発環境IntelliJ IDEAやプログラミング言語Kotlinで知られるJetbrains社の人が、実行時の情報をもとに型解析する技術を開発しているという。
そのRuby 3のリリース時期について、まつもと氏は「2020年に出せるといいなと。約束しませんが」と語った。
Ruby 3のリリースにおいては「連続的な変化をしようと思っている」ことが明らかにされた。いわく「Ruby 3はラベル」。前述したような技術をRuby 2.xに入れていき、目標を達成したバージョンに「Ruby 3」とバージョンを付けるというものだ。
直近のバージョンでは、Ruby 2.6にはMJITのプロトタイプが入る。そのために、いつもなら正式リリースに近くならないと出さないプレビュー版を「もうすぐ出す」という。実際、まつもと氏の講演のあと、Ruby25開催中に、Ruby 2.6.0-preview1がリリースされた。
この方式を取る理由は「巨大なギャップを避ける」ためだという。Rubyでは、1.8から1.9の間で非互換な変化があった。それによって「Rubyコミュニティが5年ぐらい分断した。非常に不幸なことだった」という。同じ問題を防ぐために「予見できる未来で、不連続な変化は起こさない」ことをまつもと氏は宣言した。
さらに遠い未来として、これから25年の変化が予想された。まず挙げられたのは、開発効率と保守性の向上だ。その一つとして、IDEのための静的解析の技術が語られた。さらに、ソフトウェアの開発は、タイプミスしたら指摘されたり、AIがプログラミングしたりと、インタラクティブなものになるのではという仮説が立てられた。そのうえで、問題に悩んだときに熊のぬいぐるみに話すと考えが整理されて解決にう向かうという「テディベア・プログラミング」について触れ、「未来のIDEにはテディベアが入ったり」という冗談も出た。ちなみにまつもと氏によると、Rubyのブロック機構は、子守をしているときに生まれたのだとか。
次に挙げられたのは、大規模分散環境対応だ。CPU 1コアでの性能向上が限界になるについれて、マルチコア化が進んだ。さらにマルチノードやマルチデータセンターに発展したときに、ばらまかれたシステムが協調して動くものが必要になる。「Guildのその先」とまつもと氏は説明した。
その次に挙げられたのは、非均質計算環境対応だ。モバイル向けの一部のCPUでは、パフォーマンス重視のコアと省電力重視のコアを組み合わせた「big.LITTLE」構成が使われているものがある。あるいは、GPGPUやFPGAを使ったコンピューティングも、異質なコンピューティング資源の組み合わせだ。「これをプログラミング言語でどう抽象化するか。まだ考えはないが」とまつもと氏は語った。
そのうえで、コンピューターが楽しいものであるためには、コンピューターはもっと賢くなる必要があり、またコンピュータと対話するに思考を明確化することが必要になるとして、「その思考のためのツールとしてRubyがなるとうれしい。Rubyの価値は、人間のための言語としてのRubyだ」と語った。
最後にまつもと氏は、Ruby25にたくさんのメッセージが集まったことに感謝し、「形のないソフトウェアへの『愛』って不思議だが、本当に愛されていると思う」と語った。
そして、Rubyの25才を「大人だがまだ若い。未来がある」として、「私たちが、Rubyを作る未来であり、Rubyで作る未来だ」と会場に呼び掛けた。
さらに冗談めかして「私の最大の目標は『サバイバルすること』」と言い、「変化を止めて、一部の人しか使わなくなった言語はいろいろあるが、それは嫌」として、たのしいプログラミング、たのしいRubyという価値を提供しつづけると語った。
なお、「もし私が死んだら？」というテーマについては、「合議制になってつまらなくなって落ち込んでいく」「私の発言を機械学習でボットにする」といった可能性を冗談まじりで語りつつ、「適切な後継者が現れるのではないかと思っている」とまとめた。
講演後にはサプライズ演出で、まつもと氏の娘さん2人により花束贈呈が行なわれた。まつもと氏には本当に事前に知らされていたかったようで、非常に驚いて感激していた。
イベントに参加したRuby関係者たちが知らない家庭でのまつもと氏の印象については、2人とも、優しい父親であることをエピソードを交じえて紹介した。さらに、日常でも「人にかわいがられるのがうまい」という素顔や、「話をするのは好きなので、ここでコアな技術のジョークに反応してもらえているのは、いい人たちの中にいるのだなと思った」といった感想も語られた。
RailsはRubyの楽しさをWebの世界に広げた
「Rubyの今」と名付けられたパートでは、Web系、インフラ系、組み込み系、データ処理系の4分野でのRubyについて解説された。
Webの分野については、「Ruby on Ruby on Rails」と題して、RubyとRailsの両方のコミッターである松田明氏が講演。主にRailsについて解説した。
松田氏はRailsを「いま世界で一番使われているWebアプリケーションフレームワークだと思う」として、「RailsはRubyをメジャー言語に押し上げた原動力」と説明した。そして、高橋氏の講演でも取り上げられたようにRubyの半生にあたる歴史を持ち、Rubyにとってもはや切っても切れない関係にあると語った。
続いてRailsの特徴を松田氏は解説した。まず、「現場のリアルな問題を解決する道具」であること。プロジェクト管理サービス「Basecamp」という現実のプロダクトから切り出して作られたフレームワークであり、あくまでプロダクトありきで作られた。
次に、「常に変化し続ける」こと。5,000人のコントリビューターで開発していて、ずっと変わり続けて古びない。そして、そこからDRYやCoC、REST、Bundlerなど、Rubyや世の中に影響を与えてきた。
次は「たのしい」こと。Rubyの特徴として、書いていて楽しい、気持ちいいということがしばしば言われるが、RailsはRubyの楽しさをWebの世界に広げてくれるという。
最後に「儲かる」こと。TwitterやGitHub、Airbnb、Uber、クックパッド、食べログ、Moneyforwardなど、大きなサイトで実際にビジネスを回してお金を回している。特に、生産性が高くプログラマー1〜2人ぐらいから始められるため、特にスタートアップで重宝されるという。そのため、「スマホを毎日使っていて、Rubyで作られた何かに一度もふれずに生活するのは難しい」と松田氏は言う。
これらを氏は「Rubyのくせに仕事になる。昼間からRubyをキメてお金までもらえる」とユーモラスにまとめた。なお、「Ruby on Rails」の名前について、「Rails on Ruby」が正しいんじゃないかとよく言われることについて、松田氏の解釈は「Rubyの楽しさを運んでくれるインフラ」という意味だという。
Railsの現在とこれからについては、「先週ぐらいから6.0開発中」として、常に新しいものであり続けるので、5〜10年たっても最新じゃないかと思うと語り、「今のところ、Railsにとってかわるものは現れないんじゃないかと思っている」とまとめた。
インフラエンニアにもRubyの生産性を
インフラの分野では、GMOペパボ株式会社の近藤宇智朗氏が「RubyとInfrastructure as Code、そして大規模インフラ」と題して講演した。
まず「Infrastructure as Code」という言葉について解説。サーバーインフラについて、構成管理、サーバーの初期化、オーケストレーションといった内容を宣言的なコードで書くプラクティスであり、バージョン管理やレビューテストなどをインフラに適用できるものだという。
この分野でのRubyの強みとして、エンジニアがやりたいことを助けてくれること、特にDSLを作るのに向いていることを近藤氏は挙げた。そして、実際にRubyのDSLを採用したものとして、Chef、Itamae、Vagrant、ridgepole、Serverspecを、実際の定義例を交じえて紹介。これらは、Rubyによって、本格的にプログラミングしているわけではないインフラエンニアの生産性を上げるものだとして、「“Enjoy Programming” for Ops」（運用エンジニアの「たのしいプログラミング」）という言葉を掲げた。
さらに、機器組み込み用に開発されたmrubyをミドルウェアに組み込むことで、クラウドインフラで活用できるのではとして、Webサーバーに組み込むmod_mrubyやngx_mruby、h2oの例を紹介。さらに、近藤氏が開発したコンテナランタイムHaconiwaを紹介した。
ミドルウェアにmrubyを組み込むメリットとしては「コードで圧倒的な自動化」を実現すると説明。負荷をすばやく検知してスケールアウトする制御や、柔軟なロードバランスなどのサービスメッシュなどの可能性を挙げ、すでにngx_mrubyやHaconiwaによる事例が出始めていると近藤氏は語った。
最後に近藤氏は「Infrastructure as CodeでインフラエンニアにもRubyの生産性を」「マイクロサービスやコンテナにRubyで新しい風を」という言葉を掲げた。
mrubyでWeb系の人も組み込み開発に
組み込みの分野では、軽量Rubyフォーラムの石井宏昌氏が「mrubyって今、こんな風に使われています」と題して講演した。
mrubyを開発した目的は「Web系の人も組み込み開発をできたらよくないか」というものだった。2010年に開発を開始し、2012年にオープンソースとして公開。ライセンスは組み込みでも使いやすいようMITライセンスにした。
mrubyのメリットは、Rubyの書きやすさを生かしながら軽量化し、200KB（さらに軽量化したmruby/cでは64KB）のRAMで動作すること。さらに、VMで動作するため、同じプログラムをほかのボードに使い回せることだ。プラットフォームとしては、たいていのOSやCPUに対応するとのこと。拡張ライブラリーはmrbgemsで配布される。
組み込み業界では出荷してしまったら直せないため、当初はなかなか採用されなかったという。それが、IoTによって採用され始めた。
実際の採用事例としては、IIJのルーターや、しまねソフト研究センターでの水田管理実証実験、データテクノロジー社のIoTゲートウェイ、社内設置型アルコール検査機、リハビリ支援ソリューション、小型人工衛星、マインドストームEV3などが紹介された。
さらに、ソフトウェアに組み込む例では、三次元幾何モデリングシステム「siren」や、SQUARE ENIXのゲーム「NieR：Automata」、仮想デバイス作成サービス「mockmock」、近藤氏の講演でも紹介された「mod_mruby」「ngx_mruby」などが紹介された。
軽量Rubyフォーラムの活動としては、mrbgems評価リストやmruby技術情報の公開などを石井氏は紹介した。mrubyの現状としては、2018年1月に安定版1.4.0がリリース。これからとしては、Ruby 2.0へのキャッチアップや、BLE5.0＋LoRaWANでのmruby適用（夏を予定）、mrubyグローバル会議を開く準備が語られた。
データ処理にRubyのエコシステムを
データ処理の分野では、トレジャーデータ株式会社の田籠聡氏が「Data Processing and Ruby in the World」と題して講演した。
田籠氏はデータ処理を、データ収集（COLLECT）、集計（SUMMARIZE）、データ解析（ANALYZE）、視覚化（VISUALIZE）の4段階に分類して解説した。
まず、視覚化ではプロプライエタリなソフトやサービスが中心で、有力なOSSほとんどないと語られた。
そして、集計やデータ解析の分野では「“よく本屋に並んでいる言語”が支配的」という状況を説明しつつ、Rubyで作られたものとして、Red Data ToolsやRuby/Numo、BioRuby、SciRubyなどを紹介。「Rubyはこの分野で強いとはいえないが、がんばっている」とコメントした。
収集の分野では、トレジャーデータのFluentdや、ElasticのLogstashなどが活躍しており、Rubyが強い分野となっている。田籠氏は特にFluentdについて、MicrosoftやGoogleのクラウドサービスでも採用されていることを紹介。さらに、CNCFのプロジェクトであり、Kubernetesと相性がいいことから、KubernetesをホストするGoogle、Microsoft、AWSのいずれでもFluentdが、つまりRubyが動いていると説明した。
収集以外でのRubyによるプロジェクトについては、GPUの命令セットをRubyから呼ぶ「Cumo」、深層学習フレームワークMXNetのRubyバインディング「mxnet.rb」、Red Data Toolsの一つでChainerをRubyに移植した「Red Chainer」、機械学習の評価器XgboostのRubyバインディング「xgboost-ruby」が紹介された。
最後に、データ処理でRubyが使われるようにするには、Rubyによるエコシステム全体を不自由なく揃えておくことが重要だと田籠氏は述べ、Railsが強いのはそれを用意しているからだと語った。
開発モデルやRuby 3など、まつもと氏と宮川氏が対談
カンファレンス最後のセッションは、「Matz & Miyagawa 未来を語る特別対談」として、まつもとゆきひろ氏と、Fastlyの宮川達彦氏の対談だった。宮川氏が対談ホストとなって、まつもと氏から話を聞き出す形態がとられた。
基調講演で少し触れられた後継者問題について、機械学習によるボットという冗談（？）から、「優しい終身の独裁者（BDFL）」モデルの話になった。まつもと氏は、意思決定はプロダクトオーナーやプロダクトマネージャーのような立場で、それは1人のほうがいいと答えた。また、Linuxカーネル開発もBDFLモデルだがサブシステムごとに権限委譲されていることについては、Linuxと違ってRubyは単体で分けづらいこと、言語としてどういうメソッドを追加してどういう名前を付けるかは優しい独裁者が決める必要があると語られた。
Ruby 3が連続的な変化となることも改めて語られた。新しい機能は、例外はあるかもしれないがメインライン開発に入れ、ある閾値を超えたときに3にするという。Ruby 1.9のときの教訓として「ギャップがあるとコミュニティの分断が起きる。（従来版を選んだ人は）新しい機能や改善が目に入らず、取り残される。起こしやすい失敗だと思う」ことから、今回はラベルモデルがいいかと思っているという
ギャップを避ける方針では、よくも悪くも非互換なものは入れない原則となる。これについてまつもと氏は「25年間やってると、直したいことがないといえば嘘になる。しかし、過去に後方互換性を壊した経緯からすると、しかたないなと」と答えた。
Ruby 3の機能のうち、JITコンパイラーのMJITについては、どういう形で入れるかという課題も語られた。Rubyをスクリプトとして起動してすぐ終了する用途で使うには、JITは向かない。一方、サーバーのように長い間動かす場合にはJITが効果的となる。「どのタイミングでJITにするかとか、デフォルトにするかとか、明示的にするかとか、これからRuby 2.6プレビュー版の挙動を見て検討する」とまつもと氏は語った。
静的型付けについては、まつもと氏は、絶対にコードに型を書きたくない立場だという。Ruby 3で予定されているSteepでは、TypeScriptのように型定義に記述できるようになっており、まつもと氏としては「妥協点」とのこと。氏としても、型がわかることによりIDEでコードを書くことや読むことの支援のメリットは認めており、Steepである程度そのメリットを提供できるのではないかと考えているという。
そのほか、文法を変更する可能性については、そのためには現在は文法エラーになるものでなければならないが、Rubyではけっこう通ってしまうという話題になり、RSpecのテストケースについてはまつもと氏でも「これ通るの？」と驚くという。
プラグマを記述して挙動を変えるということも考えられるが、「今のところそのつもりはない」という。近いのはマジックコメントによる「frozen_string_literal」（リテラルで表された文字列オブジェクトを変更不能にする）で、この挙動をデフォルトにするかどうかに賛否があってまつもと氏も決めかねていると語られた。
Ruby 3について、決まっていないが検討していることとしては、ネームスペースの問題が挙げられた。PythonやJavaではファイル単位のネームスペースとなっており、それをインポートする形をとる。この問題については「真剣に検討しないとなと思っている。ただ、検討した結果、元のままにすることもありうる」とまつもと氏はコメントした。
基調講演で語られた、人間のためのRubyという考えについては、プログラミング言語はコンピュータと人間の間の妥協点であり、言語ごとにその濃淡が違うとして、「Rubyは人間を助ける方向にある。無駄遣いできるコンピュータリソースを人間が使いやすいほうに、というのがRuby」とまつもと氏は語った。
未来の話としては、コンピュータが自分でデータから学習するようになればプログラミングはいらなくなるのでは、「スタートレック」の世界ではプログラミングはなく口頭で指示するだけでいい、という話になり、「そういう時代にはプログラミングは楽しみのためのものになるかもしれない」という空想が語られた。
Rubyがどちらかというと進化に保守的なのに対して、松田氏の講演で語られたようにRailsが劇的に変化しているという違いもある。これについては、まつもと氏は言語は枯れた分野であり、その上でWebというホットな分野が進化するという関係を説明した。
ただし、RailsではRubyの書き方をモンキーパッチ（既存のクラスの拡張）によって強化するActive Supportを含んで多用している。これについては、モンキーパッチはRubyのいいところだが、皆が勝手にやると困るという話になり、「RSpecの英語っぽく見せることへの情熱は不思議」というコメントも出た。また、RaisからRubyに入る人がActive Supportでの書き方が普通だと思ってRubyにバグレポートが来るという笑い話も語られた。
Pythonが最近注目され、機械学習やコンピュータサイエンスなどでよく使われている問題も話題に出た。まつもと氏は、Railsが流行している間にPythonでは教育分野などで努力していてそれが実を結んだと考えており、コンピュータサイエンスではRubyも同じような努力をしていなかければと思うと語った。
また、RubyとPythonは見た目がなまじ似ているため、両方を書いていると混乱するという話では、「コロンを見たらPython」という言葉も出た。いずれにしても、RubyもPythonもその地位は安泰ではなく、1つのゲームチェンジャーみたいなもので変わるのではとまつもと氏はコメントした。
今後25年については、まつもと氏は「とりあえずサバイブ」という言葉を繰り返し、「Rubyは生きている限り面倒をみたい。そのあとも継続して続くようにしたいとは思っている」と答えた。
そのほか、サイドプロジェクトとしてアイデアだけ考えていたことがRedisに近かったという話や、バッククォート記法をコマンド実行から明け渡したいが反発が大きいので諦めるかと思っているという話、もしRuby処理系のソースコードがこの世から突然消えたら作り直すかといった話などが語られた。
Rubyistは海外への切符を持っている
最後に、 笹田耕一氏による閉会挨拶が行なわれた。
まずは「まつもとさん、おめでとうございます」。Ruby 25周年ということでお祝いメッセージを募集したところ、たくさんのメッセージが集まったという。特に、国内より国外からのメッセージが多かったとのことで。これは日本語の堪能な著名RubyistのAaron Patterson氏の呼び掛けによるものだという。笹田氏は、「Rubyistは海外への切符を持っている」との言葉で締めくくった。
openSUSE.Asia Summit 2017にアジア各地から参加者が集合（2017年10月21日〜22日取材）
コミュニティベースのLinuxディストリビューション「openSUSE」についてアジア地域のコミュニティメンバーが集まる国際カンファレンス「openSUSE.Asia Summit 2017」が、2017年10月に東京都調布市の電気通信大学で開催された。会期は2日間で公用語は英語。
日本だけでなくアジア各地から参加者が集まり、特に前回の「openSUSE.Asia Summit 2016」を開催したインドネシアから多くのコミュニティメンバーが来日して、情報交換や交流を深めていたのが印象的だった。
さらに、オープンソースのオフィススイートLibreOfficeに関する「LibreOffice mini Conference」も併催され、アフリカ地区などからも参加者や発表者が集まった。
openSUSEとSLEはどのように作られるか
基調講演では、openSUSEの議長であるRichard Brown氏が、改めてopenSUSEについて解説した。openSUSEはかつてのSUSE Linuxを源として2005年に発足し、2006年に最初のリリースが公開された。以後、商用LinuxディストリビューションのSUSE Linux Enterprise（SLE）の開発ベースともなっている。
Brown氏はopenSUSEの原則と哲学として「自由」を挙げた。openSUSEのディストリビューションはオープンソースライセンスのソフトの集合体であり、フリーでないライセンスのソフトは追加リポジトリからインストールするようになっている。持続可能なコミュニティも重要で、貢献する人がプロジェクトとの間でCLA（Contributor License Agreement）を交わす必要はない。そして運営については「自由で自発的な活動」を重んじているという。
ここでBrown氏は、「もっと新しいバージョンのソフトを」と「もっと安定した（枯れた）ものを」という、一般的なLinuxディトリビューションへの2つの要求のジレンマを語った。この問題に対してopenSUSEでは、最新のバージョンを取り入れたローリングリリースの「Tumbleweed」と、安定版である「Leap」という2種類のディストリビューションを用意している。
この区分は2015年に始まったものだ。それまでのopenSUSEをSLEの開発ベースとするにはギャップがあったことからopenSUSE Leapが作られた。SLE 12 SP1と共通のコア部分からopenSUSE Leap 42.1が、SLE 12.SP2と共通のコア部分からopenSUSE Leap 42.3が作られている。いずれも、openSUSE Tumbleweedの成果が反映される。
ただし、Tumbleweedのように構成ソフトウェアをどんどんバージョンアップしていくローリングリリースのモデルでは、バージョンアップによって不具合が発生することがしばしばある。
そこでopenSUSEでは、OBS（Open Build Service）という自動ビルドシステムと、openQAという自動テストシステムを使い、バージョンアップのたびにOS起動からアプリケーション実行までのテストを実施していることをBrown氏は説明した。これにより、たとえばGNOME 3.24はアップストリーム（本家）でリリースされてから48時間以内に、KDE Plasma 5.98はリリース当日に、openSUSE Tumbleweedのパッケージを提供したことをBrown氏は実績として語った。
なお余談だが、Brown氏はポケットサイズのPC「GPD Pocket」にopenSUSEをインストールして、プレゼンテーションや会期中の作業に使っていた。休憩時間に話を聞くと「（イベント時点で）まだGPD Pocketの全機能に対応していないので、いじりながら使っている」とのことだった。
opensuse Leapの歴史と次期バージョン
openSUSE LeapのリリースマネージャーであるLudwig Nussel氏は、Leapの歴史と次期バージョンの予定について語った。
openSUSE 13.2までは、SLEと別々に開発されていた。openSUSE 13.1の開発は、SLE 12に反映された。その後、Brown氏の基調講演でも語られたように、Tumbleweedを元に開発された共通のコア部分から、LeapとSLEが開発されるようになった。
最初のLeapは2015年11月にリリースされた42.1で、SLEを元にLeapが作られた。次のLeap 42.2は、2016年11月にリリースで、KDEやカーネル、GNOME、systmd、Qtなどのアップデートがなされたが、KDE Plasma 5.8 LTSの採用は見送られた。Leap 42.3は2017年7月で、ここからTumbleweedをベースにした共通のコアからSLEと並行して開発されるようになった。
次期バージョンは、バージョン番号体系が変わって「Leap 15」となる。2018年4月リリース予定だという。x86_64を第1アーキテクチャとして、aarch64やppc64への移植がなされる。スケジュールとしては、2017年11月～2018月2日にα版リリース、同2月にSLEがRCになる。2〜3月にβ版をリリースし、3月末〜4月にRC版とリリースを予定している。
Nussel氏は、インフラやマーケティング、パッケージング、QA（品質保証）、翻訳などへの参加を呼びかけた。中でも翻訳なら参加しやすいとして「日本からは“very good job”がなされれている」とコメントした。
openSUSEに関する各種セッション
そのほかにもさまざまな個別セッションが開かれた。ここではopenSUSE固有のツールに関するセッションをいくつかレポートする。
SUSE所属でopenSUSE開発者のMax Lin氏（台湾）は、openSUSE Tumbleweedの開発プロセスを紹介した。
TumbleweedはBrown氏の基調講演でも説明されたように、最新パッケージが入るローリングリリースのディストリビューションだ。元になる「Factory」から、OBSによるビルドとopenQAによる自動テストが行なわれ、すべて正常に動作することなどが確認される。
ワークフローとしては、リクエストが送られると自動レビューや人間によるレビューなどを経てFactoryに入り、ビルドとテストを経てTumbleweedに入る。このレビューや
ステージングのプロセスについても、Lin氏は詳しく説明した。
同じくSUSE所属でopenSUSE開発者のBen Chou氏（台湾）は、openQAによる自動テストのしくみについて解説した。氏は「Life is too short for manual testing!（手動でテストするには人生は短かい）」として、継続的な自動テストによって、変更による意図しない影響が怖くなくなると説明した。
SUSEのopenQAのサービスでは通算100万ジョブが実行されたという。openQAジョブの平均的は13分で、「週40時間と考えて164人年の仕事をした」とChou氏は説明した。
openQAではキーボードやマウスなどの人間の操作をシミュレートし、openCVによる画像認識なども備える。各テスト項目は多数のneedle（テストモジュール）となっており、テストを組み合せたジョブを、ワーカーが実行するアーキテクチャーとなっている。そのほかChou氏は、needleを開発するためのAPIや対話モードなどについても解説した。
Kukuh Syafaat氏（インドネシア）は、いくつかのLinuxディストリビューションで使われ始めているパッケージ方式のSnapとAppImage、Flatpakを紹介して、openSUSEで比較した。いずれも目的のソフトウェアとともに依存しているライブラリ等をいっしょに1つのパッケージにまとめているのが特徴で、そのため同じマシンに複数のバージョンを入れることもできる。
Syafaat氏は、SnapについてはUbuntu以外ではインストールが難しく安定していないとコメントし、openSUSEにはFlatpakを薦めた。そしてFlatpakでopenSUSEにインストールしたLibreOfficeやSpotifyクライアント、Kubic Desktopを紹介した。
またAppImageは1つの実行ファイルにまとめられており、管理者権限なしでインストールして使えるのが特徴だという。これについてもSyafaat氏は、AppImage化されたLibreOfficeやKdenliveなどを紹介した。
Andi Sugandi氏（インドネシア）は、OBSを解説するとともに、AppImageの作成にOBSを使う例を紹介した。
OBSでは、openSUSE用だけでなく、ソフトウェアをrpm形式やdeb形式などさまざまなパッケージにビルドできる。Sugandi氏は、OBSのWeb UIやCLI、プロジェクトを記述する各種定義ファイルなどを紹介した。
また、AppImageの作成にOBSを使う利点として、自動的に最新版をビルドできることや、アップデートの差分も作成できることを紹介した。
openSUSE開発者のHillwood Yang氏（中国）は、教室用PCなど多くのマシンへにopenSUSEやSLEをインストールするときに作業を自動化するAutoYastを紹介した。
インストーラーにユーザーが指定する内容をXMLファイルに記述し、PXEブートしたsyslinuxのオプションでXMLファイルを指定して実行する。ただし、このファイルが14000行あるという。そこで、既存のマシンから設定を抽出し、YaSTの設定エディターに読み込んで編集するところをYang氏は紹介した。
Debian開発者のやまねひでき氏（日本）は、OBSやopenQAなどのopenSUSE由来のツールがDebianのパッケージに移植されている状況を紹介した。
OBSは、Collabora社所属のAndrew Lee氏が仕事で使うためにDebianパッケージに移植し、Debian 9（stretch）に入っているという。またSnapperは、Nicolas Dandrimont氏が移植し、やまね氏がメンテナーを引き継いだ。
openQAは、やまね氏が名乗りを上げて、現在（イベント時点で）作業中だという。2017年のDebian開発者会議「DebConf 17」で発表し、Debian開発者に興味を持たれたと氏は語った。
LibreOffice mini Conferenceも併催
openSUSE.Asia Summit 2017の中の併催イベントとして、オープンソースのオフィススイートLibreOfficeに関する「LibreOffice mini Conference」も開催された。
LibreOffice Japanese Teamの小笠原徳彦氏（日本）は、LibreOfficeとその開発コミュニティについて紹介した。LibreOfficeはオープンソースライセンスで開発されているフル機能のオフィス生産性スイートで、マルチプラットフォームと多言語対応が特徴となっている。タイムベースでリリースされており、メジャーリリースは6か月ごと、マイナーリリースは1か月ごととなっている。
小笠原氏はそのほか、LibreOfficeに含まれる各ツールや、ドキュメントフォーマット、Web上で文書を編集するLibreOffice Onlineなども紹介した。
そのうえで開発状況や開発コミュニティを紹介し、企業の傘の下にある「Umbrella Culture」ではなく、「Mixing Bowl（料理で材料を混ぜるボウル） Culture」だと説明。さらにLibreOffice開発コミュニティを支えているThe Document Foundation（TDF）を紹介して、「“TDFがLibreOfficeを開発している”というわけではない。TDFはMixing Bowlを提供している」と語った。
Software Liberty Association TaiwanのFranklin Weng氏（台湾）は「The Interoperability of Documents」と題して、いかに共同作業できる文書を作るかについて語った。
Weng氏は、昔の文書は手書きして馬などを使ってやりとり（interoperate）したという話から始め、それが20世紀にはタイプライターになり、コンピューターとなったが、やりとりにはプリントアウトが使われていたことを取り上げた。つまり、ワープロ上で空白文字でレイアウトしたり文字装飾を指定したりして「美しい紙の文書」を作ることが目的だった。
しかし、現在では電子メールなどのデジタルでやりとりするようになり、やりとりの目的は「文書交換」ではなく「共同作業」となった。そのために、オープンで安定したな文書フォーマットと、正しい考えにもとづく文書の作り方、オープンなフォントの3つが重要になったとWeng氏は論じた。
特に強調されたのが文書の作り方だ。Weng氏は、スタイルで整形した文書と、フォントやセンタリングで整形した文書で同じような見た目になっているものを並べ、「正しいスタイルで整形するべし」と語った。
また文書フォーマットについては、LibreOfficeのODF形式とMicrosof OfficeのOOXML形式を比較し、OOXMLはバージョンによって違いがあることや、記述が冗長になることなどを挙げて、ODFのほうが優位だとWeng氏は主張した。
最後に氏は、「LibreOffice自体を広めるより、共同作業できる文書を広めよう」と話をまとめた。
LT（ライトニングトーク）の枠では、アフリカ地域からLibreOffice mini Conferenceに来日したMohamed Trabelsi氏（チュニジア）とAschalew Arega Ademe氏（エチオピア）が、自国での活動を紹介した。
Trabelsi氏はチュジアのオープンソースソフトウェア（OSS）活動について、中東から北アフリカの地域の中で活発な地域になってきていると紹介した。LibreOfficeの翻訳については、チュニジアで使われている言語について、フランス語は翻訳率100%だが、アラビア語がUIで82.5%、ヘルプで1.4%という数字を示して、「若い学生に期待したい」と語った。
Ademe氏はエチオピアについて、政府がICTの拡大に力を入れていることや、さまざまな言語が使われていることなどを説明した。その中で、2005年からEFOSSNET（Ethiopian Free and Open Source Software Network）という団体が発足して、事実上の公式言語であるアムハラ語についてはLibreOfficeの翻訳率が高いことを紹介した。
