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などの前提知識が多数必要で、「誰もついてきてくれない」と服部氏はコメントした。
