Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Quarkus.io のブログ記事、 Concurrent asynchronous actions with Mutiny の翻訳記事です。 今週は、並行処理を中心とした広く普及しているユースケースについて聞かれました。このユーザーは、2つのマイクロサービスを並行して呼び出し、両方の結果が出たらそれらを結合して処理を続けたいと考えていました。基本的には以下のパターンです。 非リアクティブなアプローチでは、両方の呼び出しは呼び出し元のスレッドをブロックし、ワーカースレッドプールを使用している場合を除き、呼び出しは同時進行ではありません。ワーカースレッドプールを使用していても、これらのスレッドはブロックされている可能性が高く、無駄にリソースを消費してしまいます。 しかし、心配はありません。Quarkus のリアクティブと Mutiny は、このシナリオを処理するためのすべてを持っています。 2つのサービスを呼びだそう 今回の記事では、Vert.x Web Client というリアクティブな HTTP クライアントを使ってみます。ノンブロッキング I/O を活用して、高いパフォーマンスと真のノンブロッキングを実現しています。隠れたスレッドプールには依存しません。Quarkus Rest Client を使うこともできます。しかし、今のところワーカースレッドを使っています。 どのクライアントを使うにしても、呼び出すためにいくつかのリモートサービスが必要です。使ってみましょう。 https://programming-quotes-api.herokuapp.com/ - プログラミングの見積もりを取る https://api.chucknorris.io/ - Chuck Norris についての見積もりを取る まず最初に、私たちの見積りを取得するために必要なコードを見てみましょう。どちらのサービスも似たようなものではありますが、対応の構造が少し異なります。結局はこれで終わりですね。 private static Uni<String> getProgrammingQuote(WebClient client) { return client.getAbs(PROGRAMMING_QUOTE) .as(BodyCodec.jsonObject()) .send() .onItem().transform(r -> r.body().getString("en") + " (" + r.body().getString("author") + ")"); } private static Uni<String> getChuckNorrisQuote(WebClient client) { return client.getAbs(CHUCK_NORRIS_QUOTE) .as(BodyCodec.jsonObject()) .send() .onItem().transform(r -> r.body().getString("value")); } これら2つのメソッドは、 WebClient を受け取ります。そして、サービスを呼び出し、JSON レスポンスを取得し、それを抽出します。これらは両方とも Uni を返す。そう、これらは非同期なんです。その結果（見積書）は、利用可能な場合には後ほど提供されます。また、 Uni を返すということは、返された Uni を誰かがサブスクライブした時にのみサービスが起動するということです。複数回サブスクライブしている場合は、複数回に分けて呼出をすることになります。 Unis の組み合わせ 今のところ、サービスを呼び出す方法は2つあります。しかし、上の図のように同時に並行に呼びたいです。 Mutiny では、 Unis が生産したアイテムを組み合わせる方法を提供しています。 Uni<Tuple2<String, String>> tuple = Uni.combine().all() .unis(getProgrammingQuote(client), getChuckNorrisQuote(client)) .asTuple(); 誰かが Uni tuple をサブスクライブすると、サービスを呼び出す getProgrammingQuote(client) と getChuckNorrisQuote(client) Unis を購読します。そのため、それらのリクエストが放出されます。サービスが並行して呼び出されます。 両方の返答がある場合は、複数の項目を運ぶシンプルな構造体であるタプルに結合します。 つまり、私たちのサービスを同時に呼び出すことは、非常に簡単なことです。実現したいサービスや非同期アクションを表す Unis を作成します。そして、 Uni.combine().all() を使用してそれらを結合するだけです。 タプルを使用して結果を結合するか、combinator 関数を使用して結合するかを決めることができます。 すべてをまとめる // Web Client を作成 WebClient client = WebClient.create(vertx); // 2つのUnisの結果をタプルに結合 Uni.combine().all() .unis(getProgrammingQuote(client), getChuckNorrisQuote(client)) .asTuple() // サブスクライブ（これが呼び出しのトリガーとなる） .subscribe().with(tuple -> { System.out.println( "Programming Quote: " + tuple.getItem1()); System.out.println( "Chuck Norris Quote: " + tuple.getItem2()); }); それだ！このコードが実際に動作しているのを見たい場合は、この gist を確認してください。JBangで直接実行できます。 jbang https://gist.github.com/cescoffier/1ed68bef12b798529e10350f77686e9a 楽しもう

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Quarkus.io のブログ記事、 Quarkus 1.10 released - JSON as default, Multiple reactive datasources, new Micrometer registries... の翻訳記事です。 リリースされたばかりの Quarkus 1.10.2.Final には、多くの改善と新機能が搭載されています。 デフォルトのメディアタイプが JSON になりました CodeStarts はデフォルトのプロジェクト生成ツールになりました。 Micrometer の拡張機能は、かなりの部分で改善されています（新しいレジストリなど）。 新しい Qute のエラーページ Swagger/GraphQL/Health/OpenAPI UI とSwagger UI の設定 Hibernate の ORM 設定の一部が実行時にオーバーライド可能になりました。 SmallRye Reactive Messaging 2.5.0 と Mutiny 0.11.0 Reactive SQL クライアントが複数のデータソースをサポート 新しい Amazon IAM 拡張機能 Google クラウドにデプロイするための新しいガイド いつものように、バグ修正や使い勝手の改善、ドキュメントの改善なども行われています。 移行ガイド 既存のアプリケーションの移行をお考えですか？ここに 1.10 の移行ガイド があります。 Java 11 対応の GraalVM 20.2 は、まだ推奨の GraalVM のバージョンです。 1.10.0.Final （1.10.1.Finalも）はどこにあるの！？ Caffeine 拡張機能のリグレッションを発見しました。そのため 1.10.0.Final の発表をスキップしました。そして、Platform BOM の問題を発見しました。なので 1.10.2.Final をリリースしなければなりませんでした。 その間にいくつかの問題を修正することができたので、1.10.2.Final はより大きなリリースとなりました。 何が新しいの？ デフォルトのコンテンツタイプとしての JSON REST リソースを冗長にならないようにするための努力と、最近では JSON が REST サービスで最も広く使用されているコンテンツタイプであることを考慮して、Quarkus では REST リソースのデフォルトとして JSON が使用されるようになりました。 つまり、JSON を使用している場合は、 @Produces と @Consumes のアノテーションを追加する必要がなくなります。 また、コンテンツタイプネゴシエーションに頼っていた場合、サポートしているコンテンツタイプでこれらのアノテーションを追加しなければいけません。 デフォルトのプロジェクト生成ツールとしての CodeStarts CodeStarts プロジェクトは、長い間地道な努力を続けてきました。朗報：今はデフォルトのプロジェクト生成ツールになりました。 エンドユーザーの視点から見ると、より良い UI、より柔軟性のあるコード例をもたらします。 Micrometer レジストリ 新たに2つのレジストリが追加されました。 StatsD SignalFX さらにメトリクスを追加しました。 Swagger/GraphQL/Health/OpenAPI UIs Swagger/GraphQL/Health/OpenAPI UI を一貫して Quarkus をテーマにしたものにするために、多くの作業が行われました。 また、実行時にそれらを無効にすることもできます。 より具体的には、Swagger UI の前面では、すべての Swagger UI 設定のつまみが Quarkus の設定プロパティとして公開されています。それについては、 先日公開されたばかりの Stylish API のブログ記事 で紹介しています。 Qute エラーページ テンプレートエンジンのQuteをお使いの方は、ピカピカのエラーページをご覧になって喜んでいただけると思います。これがエラーを指摘し、さらに生産性を高めてくれます。 Hibernate ORM ランタイム設定 1.10 以前では、すべての Hibernate ORM 構成プロパティがビルド時に修正されていました。主に最適化のためのものです。 1.10 では、慎重に選択したいくつかのプロパティについてこのルールを緩和しました。以下のプロパティを実行時にオーバーライドできるようになりました。 quarkus.hibernate-orm.database.generation quarkus.hibernate-orm.database.generation.create-schemas quarkus.hibernate-orm.database.generation.halt-on-error quarkus.hibernate-orm.log.sql quarkus.hibernate-orm.log.format-sql より多くの Reactive の変更 SmallRye Reactive Messaging が 2.5.0 にアップグレードされました。これにより、いくつかの改善と Mutiny が 0.11.0 にアップグレードされました。 Reactive SQL クライアントは複数のデータソースをサポートするようになりました。これによって複数のデータベースに接続できるようになりました。JDBC データソースの場合と全く同じ方法で使用できます。 Amazon IAM の新しい拡張機能 Amazon サービスの拡張機能に新しい友人ができました。真新しい Amazon IAM 拡張機能です。 これについては、 Amazon IAM ガイド で詳しく紹介されています。 Google Cloud Google Cloud 関連の仕事の多くは Quarkiverse で行われています。 また、Quarkus アプリケーションをどのように Google Cloud にデプロイするのか疑問に思っている方のために、 新しいガイド をご用意しました。 その他の変更点 Hibernate ORM が 5.4.24.Final にアップグレードされました。 完全な変更ログ 1.10.0.CR1 、 1.10.0.Final 、 1.10.1.Final 、 1.10.2.Final の完全な変更ログはGitHubで入手できます。 ADOPTERS.md Quarkusの使用に関する情報を共有するために、リポジトリのルートに ADOPTERS.mdファイル を追加しました。 Quarkusを使用していて、私たちのブログでインタビューを受けたい場合、または単にこのファイルに追加したい場合は、私たちにご連絡ください。 貢献者 Quarkusには現在 395人の貢献者 がいます。皆様、本当にありがとうございました。 特に1.10リリースについてはみなさんのおかげです。 Alexey Loubyansky, Andrea Cosentino, Andreas Eberle, Andrej Petras, Andrew Hatch, Andy Damevin, Anton Fagerberg, Antonio Goncalves, antonwiens, Arne Mejlholm, Auri Munoz, Bill Burke, Bobby Alex Philip, Bobby Philip, Cem Nura, Clement Escoffier, Daniel Platz, David M. Lloyd, Denis Fuenzalida, Dheeraj Nalluri, Dmitry Telegin, Dominik Henneke, Dušan Križan, Erin Schnabel, Falko Modler, Felix Wong, Foivos Zakkak, George Andrinopoulos, George Gastaldi, Georgios Andrianakis, ghokun, Guillaume Le Floch, Guillaume Smet, Gwenneg Lepage, Gytis Trikleris, Ioannis Canellos, Jack Hu, Jaikiran Pai, Jakub Antosik, Jan Martiška, Jordi Sola, Julien Ponge, Justin Holmes, Justin Lee, jyemin, jzuriaga, Jérôme TAMA, Jörg von Frantzius, kdnakt, Kevin Viet, Knut Wannheden, Kuba Antosik, Ladislav Thon, Libor Krzyzanek, Lovekesh Garg, Loïc Mathieu, luneo7, Maciej Swiderski, Manyanda Chitimbo, Marcin Czeczko, Martin Kouba, Matej Novotny, Matej Vasek, Matthias Harter, Michal Szynkiewicz, Nathan Erwin, osaka-svg, Paul Kunysch, Pedro Igor, Peter Palaga, Phillip Kruger, René Grob, Robbie Gemmell, Roberto Cortez, Rostislav Svoboda, Samuel Le Berrigaud, Sanne Grinovero, seregamorph, Sergey Beryozkin, Simon Bengtsson, Stefan Hacker, Stephane Epardaud, Stuart Douglas, Thorasine, Vincent Sevel, Vincent Sourin, Vinod Anandan, xstefank, Xumk, Yoann Rodière 参加しよう 私たちはあなたのフィードバックをとても大切にしていますので、バグを報告し、改善を依頼してください...一緒に何か素晴らしいものを作りましょう! Quarkusのユーザーや好奇心の強い人は、恥ずかしがらずに歓迎コミュニティに参加してください。 GitHub にフィードバックを提供する; コードを作成して PRを行う ; Zulip や メーリングリスト で議論する; なにか質問があれば Stack Overflow で投稿してください。

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Quarkus.io のブログ記事、 Cytech uses Quarkus to save Greek Tourism の翻訳記事です。 観光業とコロナ 観光業がコロナのパンデミックの影響を最も受けた産業の一つであることは今に始まったことではありません。ホテル、レストラン、航空会社、クルーズは、この夏、本当に厳しい時間を過ごしたビジネスの一部です。多くの国、特に経済が観光に依存している国は、国民に大きな健康リスクを負わせずに観光客に国境を開放する解決策を模索していました。ここには魔法のような解決策はありません。ですが、両方の要件を満たすために最善を尽くす余地は常にあります。 ギリシャ政府は経済を助けるために国境を開放することをどこかの時点で決めていました。しかし、予防策や対策を講じずにそれを行うのはあまりにも無謀です。だからこそ、高度な技術に基づいたシステムを構築することにしたのです。これはコロナのテストに適した旅行者を選びます。これは次のような考え方です。もし、全員を検査する余裕がないのであれば、コロナ検査で陽性の可能性が高い人を検査すべきでしょう。このようにして、ギリシャの国家はその資源を賢く使うことができます。同時に、テストのためのお金を節約できます。 問題は「どうやって」ということです。そして、その現場に入ったのがこの部分です。すでに科学者のチームが AI と機械学習のアルゴリズムを提案しています。その野望は、テストを受けるべき人を効率的に選ぶことで、上記のようなニーズを的確にカバーすることにありました。しかし、これらのアルゴリズムにはデータが必要です。その時点では、入国した乗客の詳細なデータは、どのようなデジタルで組織化された形でも入手できませんでした。 基本的な考え方 ギリシャ政府は、私たちの会社である Cytech 社に、乗客から情報を収集し、フィルターをかけて関係者全員に渡すソフトウェアの開発を依頼しました。その中に EVA という機械学習システムがありました。しかし、この情報を必要としている当事者のリストはもっと長いものでした。それは、市民保護局、保健省、国境捜査官、航空会社などを含みます。それと同時に、乗客一人一人に申請が審査中であることを知らせるメールを送ることになる。EVA が結果を出したら、最終的な書類を乗客にメールで送り返してくれます。それがなければ、彼らの入国は許されません。長い話を短くすると、私たちの仕事は、すべての乗客のデータを収集するための要求の厳しい Webフォームを 構築することでした。それでも、最も重要なのは、スピード、堅牢性、回復力を重視した他のすべての情報システムとの正しいデータ交換が可能なデータブローカーを作成することでした。 技術的な課題と解決策 旅客探知器フォーム プロジェクトのバックエンドのための Broker プラットフォームの要件は、主に UI が使用するための REST API エンドポイントを公開することに集中していました。また、EVA、EODY（国立公衆衛生機関）、GGPP（市民保護事務局）、ギリシャのコロナ患者レジストリなど、必要なデータ交換のために政府関連の第三者との相互接続も行っています。また、極端な納期内に納品することや、大規模なニーズにも対応することができました。成熟した実績のあるツールであること、開発者の生産性、（水平方向の）スケーラビリティ、可能な限り最小のリソースで最大の効率性とパフォーマンスを提供してくれることも求められました。 過去に小規模なプロジェクトで Quarkus と良い経験がありました。ですが、使い勝手の良さと生産性向上のための機能にはすでに感銘を受けていました。Quarkus は業界標準（Microprofile と Jakarta EE API）をベースにしているため、開発者にとっては、非常にタイトな納期内に非常に迅速にスピードを上げることができました。また、Quarkus のウェブサイトのガイドセクションは、自動的な魔法のように期待通りに動作しないいくつかの部分について、すぐにフィードバックを得ることができました。 ライブリロード、および非常に高速なスタートアップは、Javaでのエンタープライズ品質の非常に大規模なアプリケーションを開発する上で非常に新鮮なスタートを切ったように感じました。バックエンドアプリケーション上での変更はすぐに次のリクエストに反映されました。アプリケーションの UI には同じ機能を提供する Vue.js を選択したため、それは同じような機能を提供します。アプリケーション全体の変更はすべて、それが起こったときにライブでリロードされました。 Quarkus：ゲームチェンジャー このような致命的な影響を与えるアプリケーションには、堅牢性が求められます。どんな種類の停止にも対応する余地はありませんでした。これは、人々が私たちの国に入ることを拒否されたり、国境で強制送還されたりすることを意味します。テストは、Quarkus の開発ライフサイクルの中では最優先です。そのおかげで、最小限の時間でアプリケーションの堅牢性と信頼性を高めることができました。本番環境でのアプリケーションのテストは、テストクラスに @QuarkusTest をアノテーションし、 @QuarkusTestResource と TestContainers を使ってデータベースを処理するのと同じくらい簡単でした。非常に高いコードカバレッジを実現しました。そして、（最も重要なのは）簡単なパスだけでなく、アプリケーションのすべての部分に深く浸透させられました。これは、アプリケーションが最初にデプロイされ、公開された瞬間から、アプリケーションの 100% の稼働時間と可用性に大きな役割を果たしました。 Microprofile Config API に基づいた Quarkus アプリケーションの設定の汎用性を評価しました。これは統一された設定規約を使用し、動的な設定ソースを簡単にプラグインする機能を提供します。それは私たちのプロジェクトで私たちを大いに助けてくれました。これには、ダイナミックで変化の激しい部分が多く含まれていました。例えば、特定の国の入国場所の制限や、特定の国から来る乗客が RT-PCR 検査の陰性を持ち歩くことを要求するなどです。私たちのプラットフォームの主な機能の一つは、政府関係者への正確でオンタイムなデータ送信でした。動的な構成機能を使用することで、サードパーティの処理エラーによって障害が蓄積し始めた統合部品を迅速に分離し、一時停止し、オンデマンドで再開できました。 特に観光シーズンの間にギリシャに入国するすべての人が訪問しなければならないウェブサイトは、非常に高いトラフィックを容易に推測することができます。一日に何千ものフォームが提出され、いつの時点でも数千人のユニークなユーザーが同時に存在していました。私たちは、最小限のリソースでトラフィックのほとんどを処理するアプリケーションを必要としていました。また、深夜の時間帯など、必要に応じてスケールアウトすることも可能です。EVAからの結果が入ってきたときに、プラットフォームは、各乗客のための最終的なフォームを極端な緊急性で処理する必要がありました。それは、QRコードとそれに付随するPDFファイルを生成し、すべてのフォーム情報と一緒にメールで送信します。Quarkus のリソース使用量を最小限に抑えることで、大抵の場合、2つの c5.large （2 vcpus、4GBメモリ）のAWS EC2インスタンスにスケールできます。それらの、CPU 使用量は通常 10% 以下でした。QRコード生成時間中、プラットフォームは 4 つの c5.large EC2 インスタンスにスケールアウトしました。CPU 使用率は約 80% です。これらは 1 分間に 10000 以上のQRコード/PDF/メールを処理していました。 7月から9月まで、世界のほぼすべての国からの旅行者から約 400 万の旅客探知器フォームのために働きました。フォームには、夏のハイシーズンにそれぞれのメール通知、PDF、QR コードが添付されていました。リスクの低い国の観光客へアクセスを提供し、効率的なリスク管理とコロナ試験のリソースの最適な配分を行いました。また、リスクの高い国に可能な限り早くロックインし、目的地への早期警告を提供します。同時に、10 種類の情報システムと通信し、ダウンタイムやパフォーマンスの低下なく、乗客の貴重な情報を提供しています。健康の専門家の難しい仕事をサポートしました。それゆえ、彼らは国のために正しい判断を下せます。そして、ウイルスの拡散を地域社会に封じ込めるために必要な情報を得たとき、私たちはその場にいたのです。これまでも今も、刺激的で、それとと同時に、ストレスの多い旅でもあります。それは社会にとって非常に重要な問題を解決するためにテクノロジーが果たすユニークな役割を示しています。 Cytech について Cytech は、通信分野に特化した20年の経験を持つソフトウェアハウスです。モバイルメッセージング、マーケティング、決済の分野で独自の製品やサービスを開発しています。Cytech は、10カ国以上（ヨーロッパ、アジア、南米、北米、アフリカ、オーストラリア）の企業にとって、信頼できるテクノロジーパートナーとなっています。私たちの高品質と専門的な成果が認められているため、国家や大規模な組織からの要求の厳しい、挑戦的なソフトウェアプロジェクトを請け負うことがよくあります。

皆さんこんにちは、ソリューションスペシャリストの井上です。今回はAI/MLの世界で重要度が増してきているMLOpsについて解説してみたいと思います。 なぜ今AIが必要か？ いままでは世界の変化が緩やかで、過去データを分析すればおおよその未来予測はできました。 ところが今は変化が早く過去のデータがあまり役に立たない状況も出てきています。最近の例では新型コロナがありますね。「データには鮮度がある」という言葉を痛感することも多いのですがもちろんそれだけではありません。例えばZaraなどのFast Fashionに代表されるFast Inventoryモデルは従来のように1年前のデータから流行や在庫数を予測するのではなく、もっと短期間で売れる服を作って売り切るモデルで、最近このようなビジネスモデルが増えてきています。 そのために必要なリアルタイムデータを短時間で分析したり、リソースがなく利用していなかった過去の膨大なデータの分析などは、今までのように人がやっていては到底間に合いません。そこでそれをマシン（AI/Machine Learning(以降ML)）に実行してもらう必要性があるということです。 それならAI/MLをやってみよう！　となるわけですが、なんとなく始めるのはお勧めしません。 87%のAI/MLプロジェクトが実用化されていない！？ その理由はこの数字が物語っています。87％というのは2019年7月にサンフランシスコで開催されたTransform 2019というイベントで提示された、AI/MLプロジェクトの失敗率です。 ここ数年で多くの企業がAI/MLの部署を作ったり、プロジェクトを立ち上げたりしています。デジタルトランスフォーメーションの実現にはデータの活用が不可欠で、それを飛躍的にAI/MLが推し進めることを期待されているのですが、実際には多くのAI/MLプロジェクトが道半ばで挫折しています。 なぜ多くのAI/MLプロジェクトは失敗するのか？　その理由は4つ、人材不足、インフラとアプリの陳腐化、コラボレーションの欠如、そしてデータのサイロ化です。 1.人材不足 まずは人材の問題から考えてみましょう。AI/MLプロジェクトを継続的に使えるモノにするには以下のようなプロセス、人材が必要だと言われています。「いやいや、成功するかもわからないのに最初から大きな投資はできないよ」という意見はもっともだと思います。でも実際に成功しているケースでもスモールスタートで始めているところも結構あるのです。では何が違うのでしょうか？その差は最初からAI/MLのライフサイクルとペルソナを意識して取り掛かっているかどうかだと思います。例えばAI/ML成功の秘訣は優れたMLモデルの開発ではなく、MLモデルの継続的評価（Causal Inference : 因果推論）とそれに基づく再訓練の仕組みをきちんと設計することだったリします。また人材についてもデータサイエンティストを採用してその人に全部任せっきりだったりすると、生産性が低下して肝心のAI/ ML開発が進まず成果が出なかったりします。一部のオールマイティ型のデータサイエンティストであればこのライフサイクルを自分自身で対応できるかもしれませんが、そのようなスーパーデータサイエンティストは希少でしょうし、実際に運用を始めたときにはスケールできません。結果として本業のMLモデル開発に割く時間が短かくなり生産性が落ちてしまうことになりかねません。そのためそれぞれのペルソナが 自分の業務に集中できる環境の構築と、スケールできるプロセス設計 が重要になります。 AI/MLライフサイクルとペルソナの役割 2.インフラとアプリの陳腐化 2つ目はインフラとアプリの陳腐化です。 よく見かける光景として以下のようなものがあります。 それぞれのデータサイエンティストが自分で環境を構築・運用、インフラ部門も期待通りの環境の提供が困難 リソース共有ができていないためGPUのリソースも無駄が多い すべてがマニュアルプロセスで非効率、オペミスによる手戻りも多い MLモデルのアプリ実装も時間がかかる セキュリティは常に心配 上記のいくつかは心当たりがある方も多いのではないでしょうか？このような課題を解決するのは セルフサービス化 です。例えば以下のような環境があるとどうなるでしょうか？MLモデルの開発・テスト・リリース、学習に必要なGPU等のハードウェアアクセラレータリソースの自動的な割当、MLモデルのアプリ側への実装・テスト・リリース、そしてMLモデルが現実世界で及ぼす結果の継続的モニタリング。これらすべてが1つのポータルで実現でき、プロジェクトに新たに参加したデータサイエンティストにも同じ環境が即座に用意できるとしたら生産的ですよね。もちろんプロジェクト個人に合わせたデータ、アプリも個人で選択することが可能ですし、それらのアップデートも自動でやってくれるのです。このような環境を最初から準備することは後々プロジェクトを本格稼働する際にとても重要になってきます。 理想的なデータサイエンティストの環境 3.コラボレーションの欠如 3つ目はコラボレーションの欠如です。最初のAI/MLライフサイクルの図で示しましたように、AI/MLライフサイクルには複数のペルソナが介在します。そしてそれぞれが自分の役割を果たすために複数のペルソナとのコラボレーションが不可欠となります。例えばデータサイエンティストは必要なデータを入手するためにデータエンジニアと打ち合わせをしたり、データのセキュリティやパフォーマンスを確保するためにインフラチームとも打ち合わせをする必要も出てくるでしょう。さらにはMLモデルの組み込みやリリースについてアプリ開発との打ち合わせも必要になります。往々にしてあるのはそれぞれが話す言葉が他のペルソナにはちんぷんかんぷんだったり、一見簡単に思われる要求が実は様々な制約があり簡単には実現できなかったりするということです。そこでMLワークフローに必要なタスクとそこで使われる言語を標準化し、 それぞれのやり取りを自動的に行えるようにするプロセス を実現します。このプロセスはMLOpsと呼ばれます。MLOpsについては次の章で説明します。 解決策はMLOps − プロセス自動化によりセルフサービス化を実現 4.データのサイロ化 4つ目はデータのサイロ化です。データがサイロ化する原因は何でしょうか？必要なデータがどこにあるかわからない、データフローが分断されてアクセスできない、データが大きすぎて移動ができない、原因は多々あると思いますが、S&P Globalが2023年に451社のエンタープライズ企業に行った調査(非公開)によると、90％の顧客がAI開発に必要なデータはあると回答しているにも関わらず、62％がデータアクセスが重要な課題だと答えていることが明らかになっています。その内訳としては、「データは貯めるだけ貯めたが何に使ってよいかわからない」、または「データを活用しようにもデータ変換ができない」、「タイミングよくデータが収集できない」といったことが考えられると思います。それらを解決するには以下の3つの取り組みが必要だと考えています。 データを変換する仕組みをタイムリーに実装する バッチデータのストリーミング化 アジャイル的なアプローチ 　まずは「 1. データを変換する仕組みをタイムリーに実装する 」ことを考えてみましょう。ここでよく使われるのは Apache Camel というオープンソースのコンポーネントベースのルーティングエンジンがあり、各種プロトコルから各種プロトコルへの変換、データ変換を行います。さてここで「タイムリーに実装する」というところがミソなのですが、このCamelのコンポーネントをコンテナ化して、マイクロサービス化をしておくことで、既存のデータ変換の部分は変更を加えることなく、新しいデータ変換機能を追加できます。またKubernetesでコンテナ群を管理することにより、新しく追加したデータ変換コンポーネントのデータ量に追従したオートスケールができたりもします。実際にこのアーキテクチャはすでに基幹システムでも導入されている事例なのです。 　次に「 2. バッチデータのストリーミング化 」ですが、ここでは Apache Kafka がよく使われます。例えば機械学習モデルを最適化するために複数のデータを関連付けるとしましょう。いくつかはほぼリアルタイムにサンプリングが可能ですが、残りはバッチ処理、または更新タイミングが非常に遅かったりします。その場合ある特定のタイミングで関連性があるかを見極めることができないため、質の高い予測モデルを開発できないことも考えられるでしょう。Kafkaは非常に優れもので、データキャッシュとストリーミングの両方の特性を兼ね備えています。よく例えられるのは映画のフィルムです。連続したデータをタイムリーに取得できるだけでなく、過去に遡ってデータをキャプチャーもできるのです。では多くの開発者が同じデータにアクセスしたとしたら？データソースが追加されたりサンプリング周期の変更で一気にデータ量が数十倍になったら？そんな状況にも対応できるように設計されているのがKafkaの特徴です。更に前述したようにこれをコンテナ化してKubernetesで管理すると、自律的にスケールや修復もしてくれるようになります。 　最後に「 3. アジャイル的なアプローチ 」ですが、個人的にはこれがいちばん重要なのではないかと考えています。そもそもデータサイエンスは探索と深化を繰り返す作業でもあります。データを全部揃えてから分析するのではなく、揃ったデータから分析をスタートして、足りないデータがあればどんどん上記のCamelやKafkaのようなコンポーネントを追加して行けば良いのです。そのときに重要なのは常に結果を確認できるすべがあり、そのフィードバックを開発のループに戻せるようにしておくこと、継続的にこのループをできるだけ早く回すチーム体制も必要でしょう。 CamelとKafkaを利用したデータ変換とデータストリーミング さてこれらを組み合わせるとなにができるのか？　一つの例を紹介したいと思います。それはリアルタイムデータフローです。前述しましたようにMLモデルは鮮度が重要です。一週間に一度のバッチ処理で得られたインサイトからビジネス計画をねっていても後手後手に回ってしまいます。それはビジネス機会の損失、さらにはコストとリスクの増大にも繋がります。すでに現代ではリアルタイム処理が一般化しておりそれはAI/MLの世界でも例外ではないのです。ではリアルタイム処理を実現する技術としては何が必要なのでしょうか？ここでは以下の3つのコンポーネントを紹介したいと思います。 バケット通知ができるオブジェクトストレージ　 Ceph ストリーミングデータ処理をする　 Kafka イベント駆動のサーバーレス　　 KNative この3つを組み合わせてできるリアルタイム処理は イベント駆動型 と呼ばれていて、以下のような流れで動作します。この例は肺のレントゲン写真からの敗血症の患者の早期判断をするシステムですが、新型コロナの早期発見・対応にも応用できることは言うまでもありません。（データ変換のCamelは例えば「個人情報の削除」等の機能で使用されていますが、この図では記載を省いています） リアルタイムデータフローのユースケース MLOps - AI/ML活用をリアルワールドで実現する さて、前の章でMLOpsについて触れましたが多くのみなさんが「これどこかで見たことがある！？」と思われたのではないでしょうか？それもそのはずMLOpsはDevOpsのML版だからです。MLOpsという言葉が使われたのは2018年のGoogleのイベントが最初と言われていますので、Googleから引用しますと、「MLOps は、ML システム開発（Dev）と ML システム運用（Ops）の統合を目的とする ML エンジニアリングの文化と手法です。」ということになります。そしてMLOps を実践すると、統合、テスト、リリース、デプロイ、インフラストラクチャ管理など、ML システム構築のすべてのステップで自動化とモニタリングを推進できます。 MLモデル開発とMLOps・DataOpsの関係　 https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf すでに解説してきましたようにML開発自体はMLモデルを実際に活用するための小さな一つのピースに過ぎません。そのモデルをできるだけ早く開発、リリースし継続的にフィードバックして再学習するループを高速に回すためにはMLOps、DataOpsがとても重要になってきます。 そしてこれらを取り入れることでAI/MLのワークフローは以下の図のようにとてもスッキリします。 最も重要なのはここでは最初に提起した4つの課題が解決できていることです。 人材不足：セルフサービス化によりそれぞれのペルソナが自分の仕事に専念し生産性を最大化できる インフラとアプリの陳腐化： 常に最新の開発・テスト環境が提供されている コラボレーションの欠如：ペルソナ間の無駄な打ち合わせとコミュニケーションミスの低減 データのサイロ化：データ管理の一元化とリアルタイム対応によるデータの流動性向上 Red HatポートフォリオによるAI/MLソリューション とはいえAI/MLの世界で利用されているコンポーネントはほとんどがOSSです。それを一つ一つ選択、管理していくのは時間のかかる作業ですしスケールすればするほど生産性も落ちていきます。そのため主なOSSを一つのプラットフォームにまとめたソリューションが必要とされてきました。いわゆるML as a Serviceです。レッドハットがリードして開発しているオープンソースフレームワーク Open Data Hub （以降ODH）は以下のようなAI/ML開発に必要なコンポーネントをコンテナ型のサービスで提供するオープンプラットフォームで、オープンソースのAI/MLツールの開発・運用を自動化・セルフサービス化を実現します。 Open Data HubによるML as a Serviceの実現 さらにこの環境をオンデマンドで提供できるクラウド型もあります。Red Hat OpenShift Data ScienceはAWS上で簡単に利用が可能になっています。 Red Hat OpenShift Data Science また、まずは体験してみたいという方にはSandboxも提供していますのでぜひお試しください。 developers.redhat.com Dashboard ユーザー事例 最後にいくつかユーザー事例を紹介したいと思います。適切なAI/MLの実装をすることにより、あらゆる分野で大きな効果が実現できています。このBlogでは詳細の説明は割愛しますがご興味があればRed Hat担当者までご連絡ください。 ・ ロイヤルバンクオブカナダ銀行（不正検知） (英語) 1300万レコードを20分で分析 数日で新しいMLモデルを更新 従来の10倍のトレーニングが可能に https://www.redhat.com/ja/about/press-releases/royal-bank-canada-and-borealis-ai-announce-new-ai-private-cloud-platform-developed-red-hat-and-nvidia ・ExxonMobile（MLセルフサービス） 1つの共通プラットフォームを130チームで共有 年間プロジェクト数が10倍に データサイエンティストはMLモデル開発に集中 https://www.redhat.com/ja/success-stories/exxonmobil ・BMW（自動運転システム開発） 230PBのデータ分析基盤を3ヶ月で構築 9万コアのGPUクラスターの設定を自動化 レガシーアプリもOpenShift上で活用 https://www.redhat.com/ja/success-stories/bmwgroup ・HCA（敗血症の早期検出） 1日あたり3万人の患者をモニター 治療にとりかかる時間を5時間短縮 ヒット率が3.3％から92.2％に向上 https://www.redhat.com/ja/success-stories/hca-healthcare 関連記事 OpenShift AIでAI/MLもOpenShiftにおまかせ！ Apache Camel 超入門 Apache Kafka 超入門 胸部X線写真を自動で分析するデータパイプラインのデモ

OpenStackを担当しているソリューションアーキテクトの輿水です。 Public Cloudで利用できるRed Hat OpenShift Container Platform（以降OCP）のハンズオンや弊社のハンズオンワークショップについてご紹介してきましたが、OCPを、Public Cloudにを展開するのと同様に、Private CloudであるRed Hat OpenStack Platform（以降RHOSP）上にデプロイするOpenshift on OpenStackがあります。考えられるユースケースとしては、既にRHOSP環境があるのでそこでOCPを稼働させたい、Public CloudではなくPrivate CloudでOCPを稼働させたい、RHOSPのインスタンスとOCPのコンテナを一緒に使いたいケースなどが考えられます。 OpenStackとOpenshiftの関係性 RHOSPがコンピュートやストレージ、ネットワーク、ロードバランサー、暗号化などのリソースをOCPに提供します OCPはRHOSPによってプロビジョニングされたインフラ（Red Hat Enterprise Linux CoreOS）上でコンテナ化されたアプリケーションを実行します OCPはオンデマンドでRHOSPのリソースを使用します 関係性を少し細かく見てゆきます。 Compute service Red Hat OpenStack Compute (nova)。OCPのnodeとなる仮想マシンを制御します。コンテナはworker nodeで実行されます。 Object storage OpenStackのdefaultはSwiftですが、Red Hat Ceph Object Gateway（RGW）RGWを推奨します。OCPのInternal Registryに使用されます。バックエンドはRed Hat Ceph Block Storage (RBD)を利用します。 Block storage Red Hat OpenStack Block Storage (cinder) 。OCPのPersistent Storageに使用されます。バックエンドはRed Hat Ceph Block Storage (RBD)を利用します。 Image storage Red Hat OpenStack Image Service (glance) 。OCPに必要なRed Hat Enterprise Linux CoreOS (RHCOS)イメージが登録されます。また、Bootstrap nodeおよびクラスターの起動に使用される OCP Ignition ファイルが保存されます。バックエンドはRed Hat Ceph Block Storage (RBD)を利用します。 Networking service-OpenStack Open vSwitch (OVS) Networking service - OpenShift OpenShift software-defined networking (SDN) Ignition Red Hat OpenShiftのインストールプロセスで使用されるRed Hat Enterprise Linux CoreOS (RHCOS) ツール 以下で、インストーラーでプロビジョニングされるインフラストラクチャー方法を使用して Red Hat OpenShift Container Platform (OCP) をインストールするおおまかなステップについて記載します。なお、RHOSPとOCPのバージョン組み合わせ及びインストール方法（IPI/UPI）は複数あるため、サポート状況は OpenShift Container Platform on Red Hat OpenStack Platform Support Matrix を確認してください（Red Hat Portalへのログインが必要です）。 RHOSPのインストール RHOSPはRHOSP directorを利用してRed Hat Ceph Storageも含めてインストールします。 RHOSP上でOCPを利用する際のネットワークの構成方法として、デフォルトのネットワークコンポーネントを使用する方法と、PodとServiceに対してネットワークを提供するためにOctaviaを使用するKuryrというcontainer network interface (CNI) プラグインを使用する方法があります。KuryrはRHOSPのテナントネットワークとOpenShift SDNで二重のencapsulationされることを避けたい場合に使用されます。加えて、RHOSPのインスタンスとOCPのPodの相互接続を提供します。 OCPのインストール OCPはRHOSPのテナント内で実行され、各テナントのOCPクラスターは他のテナントから分離されます。OCPのインストールの事前準備としてRHOSPで以下の作業を行っておきます。 パブリックネットワークの作成 OCPのnodeに必要なflavorの作成 ユーザーおよびプロジェクト（テナント）の作成 例「shiftstack」と呼ばれるプロジェクト を作成し「shiftstack_user」というユーザーを作成 オブジェクトストレージを使用するためのテナントへのアクセスの付与 ユーザーのクォータ設定 OCPクラスターに必要なリソース要件を満たせるように設定 例： $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre $ openstack subnet create --dhcp --gateway 192.168.122.1 --network public --subnet-range 192.168.122.0/24 --allocation-pool start=192.168.122.151,end=192.168.122.200 public $ openstack flavor create --ram 16384 --disk 25 --vcpu 4 --public m1.large $ openstack project create shiftstack $ openstack user create --password 'redhat' shiftstack_user $ openstack role add --user shiftstack_user --project shiftstack member $ openstack role add --user shiftstack_user --project shiftstack Member $ openstack quota set --cores 28 --ram 120000 shiftstack 作成したユーザー（例ではshiftstack_user）でdirectorホストからOCPをインストールします。この際RHOSPのstackユーザーとして操作する必要があるので、RHOSPのCLIを利用するために必要なRCファイルと、RHOSPに接続するための設定が含まれるcloud.yamlファイルをOpenStackのダッシュボードから取得します。Red Hat OpenShift Cluster Manager からダウンロードしたOCP インストールプログラム、クライアント、およびプルシークレットを入手して、ガイドに従ってinstall-config.yamlを生成します。インストールプログラムは複数のOCPクラスターを管理できるため、クラスター毎にディレクトリを分けています。（この例ではocpra-configとocpraを利用） 例： $ openshift-install --dir=ocpra-config create install-config ? SSH Public Key /home/stack/.ssh/id_rsa.pub ? Platform openstack ? Cloud openstack ? ExternalNetwork public ? APIFloatingIPAddress 192.168.122.152 ? FlavorName m1.large ? Base Domain example.com ? Cluster Name ocpra ? Pull Secret [? for help] ****************************************** SSH Public Key：OCPのnodeにアクセスするための公開鍵。 stack ユーザーの公開鍵を使用します。 Platform：RHOCPをインストールするクラウドプロバイダー。RHOSPにインストールする場合は「openstack」を指定します。 Cloud：ダンロードしたclouds.yaml ExternalNetwork:：「 --external」で定義されるネットワーク APIFloatingIPAddress:：APIアクセスのための Floating IP FlavorName：OCPのnodeとなるインスタンスのフレーバー Base Domain：クラスターのベースドメイン名。 Cluster Name：クラスターの名前。この名前は、ベースドメイン名の接頭辞として . として追加されます。 Pull Secret：「Install OpenShift on Red Hat OpenStack Platform with installer-provisioned infrastructure」の「Pull Secret」セクションからコピーした値。 作成されたinstall-config.yamlを利用してOCPをインストールします。 $ cp ocpra-config/install-config.yaml ocpra/ $ openshift-install --dir=ocpra create cluster OCPインストール後は、RHOSPのダッシュボードで、OCPで使用しているnodeやネットワークが確認できます。 既にRHOSP環境が稼働している場合はOCPのインストールマニュアルを参照してください。RHOSPも含めて構築する場合はRHOSPのインストールマニュアルも必要です。また、OCP 4.6には対応していないのですが、OCP 4.4とRHOSP 16を組み合わせた場合のリファレンスアーキテクチャーの日本語ドキュメントが公開されているので、参考にしてください。 Red Hat OpenStack Platform 13 および 16.0 への Red Hat OpenShift Container Platform 4.4 のデプロイ access.redhat.com access.redhat.com

OpenStackを中心にCloud製品を担当しているソリューションアーキテクトの輿水です。 Red Hat OpenShift on IBM Cloudの無料で使えるHands on Lab環境を使った後に、通常（有料）の環境を構築してみました。既にライト・アカウントで登録している場合は、住所やカード情報を入れることでアカウントがアップグレードされます。 ※2021年1月末まで200ドル分を利用できる模様です 早速、用意されている Red Hat OpenShift on IBM Cloud 概説 に従って環境を作ってみます。 Red Hat OpenShift on IBM Cloud 概説 IBM Cloud アカウントでログインするとダッシュボードが表示されるので、上部の「カタログ」をクリックします。 使用できるプロダクトの一覧から「Red Hat OpenShift on IBM Cloud」を選択します。Recommended for youで「Red Hat OpenShift on IBM Cloud」が表示される場合もありますが、表示されてない場合は「OpenShift」で検索してください。 クラスターの構成を決める画面が表示されるます。 作成できるクラスターには「クラシック OpenShift クラスター」と「VPC クラスター」の２種類があります。クラシックは通常のPublic Cloud、VPCはPrivate CloudのセキュリティーとPublic Cloudのスケーラビリティーを兼ね備えた仮想プライベート・クラウドとのことなので、今回は通常の「クラシック OpenShift クラスター」を選択しました。OCPのバージョンはこのドキュメントでは (OpenShift 4.3.35) とありますが、選択画面ではいくつかのバージョンがあるので、選べる中で最新版（4.5.18）を選んでみました。次にノードをどのように配置するかを決めます。ドキュメントの中では「 高可用性のためのクラスターの計画 」に詳細が記載されています。 単一ゾーンクラスター １箇所のリージョン内の、１つのゾーンに worker nodeを配置します。 マルチゾーンクラスター １箇所のリージョン内の複数のゾーンに worker nodeを配置します。ゾーンの障害に対して耐障害性を持たせることができます。 グローバル・ロドバランサーを持つ複数クラスター 複数のゾーンまたはリージョンをまたいでセットアップされ、グローバル・ロード・バランサーを介して接続された複数クラスターにworker nodeを配置できます。 「Geography」Asia Pacific / Europe / North America / South America 「Availability」Single Zone / Multi Zone 「Worker zone」 「Availability」でSingle Zone を選んだ場合は「Worker zone」では１箇所のzoneを選択 「Availability」でMulti Zoneを選んだ場合は「Metoro」を指定して単一または複数の「Worker zone」を選択 そのWorker zoneを初めて使う場合はネットワーク用のサブネット（VLAN）が作成されてないので、自動的に作成されます（←自動でなくて作成する必要があるかも）。複数zoneの場合は、zone毎に異なるサブネットを割り当ててルーティングするか、VLANをzone間にまたがるようにすることができます。デフォルトでは各zoneに異なるVLANが割り当てられ、自動的にMulti zone load balancerが作成されます。 各zoneに作成するWokerの数とflavorを選択（または作成）します。標準では３台、4vCPU 16Gです。なお、右側に時間あたりと月間の場合にトータルコストの見積もりが表示されます。個人で試す場合は、そこを気にしつつ環境作成しましょう。 左下のCreateボタンをクリックして次の画面が表示されれば、クラスターの作成が始まっています。これ以外のポップアップのアラートが表示された場合は、アラートの内容を確認して、構成の指定に漏れがないか等を確認してください。 表示された画面の左側「Overview」をクリックするとクラスターのprovisioningの進捗状況が確認できます。途中で右側の「worker node」の進捗状況がPendingやCriticalになったりしますが、最終的にNormalになればクラスターの作成が完了です。クラスター規模（zoneやworker nodeの数）が大きいほどクラスター作成までの時間がかかります。3 zone × 3 worker nodesの場合は相当待ちます。クラスター作成が完了して各種サービスが稼働すれば右上にあるOpenShift web console にアクセスが可能になります。ドキュメントの注記によれば「Normalになった後、約10分程度」とのことですので、しばし待ちます。 クラスターの作成が完了するまで、しばらく時間がかかる可能性があります。 クラスターの状態が Normal になってから、クラスター・ネットワークおよびロード・バランシング・コンポーネントで、OpenShift Web コンソールおよびその他の経路に使用するクラスター・ドメインがデプロイされて更新されるまでに約 10 分かかります。Ingress サブドメインが <cluster_name>.<globally_unique_account_HASH>-0001. .containers.appdomain.cloud のパターンに従っていることを確認して、クラスターの準備が整うまで待機してから、次の手順に進んでください。 Red Hat OpenShift on IBM Cloudはフルマネージドサービスであり、worker nodeの指定は可能なのですが、masterの指定はできません。クラスターの中のノードを確認すると「master,worker」と表示されておりましたが、「 ワーカー・ノードのセットアップ計画 」の中で以下の記載があり、master nodeのプロセスが稼働している訳ではない模様です。 ワーカー・ノードの役割が master になるのはなぜですか? oc get nodes または oc describe node <worker_node> を実行すると、ワーカー・ノードの役割に「 master,worker」と表示されることがあります。 OpenShift クラスターでは、オペレーターがワーカー・ノードに正常にデプロイできるように、オペレーターは nodeSelector として master 役割を使用します。 ワーカー・ノードでマスター・ノードのプロセスが実行されているわけではありません。 masterの可用性については「 高可用性のためのクラスターの計画 」の中で言及されており、単一ゾーン・クラスターの場合も可用性が担保されています。 単一ゾーン・クラスターのマスターの可用性は高いのでしょうか? クラスターを単一ゾーンの都市に作成する場合、クラシック・クラスターの Kubernetes マスターは高可用性です。マスター更新時などの停止を防ぐために、マスターの API サーバー、etcd、スケジューラー、およびコントローラー・マネージャーのレプリカが別の物理ホスト上に配置されます。 クラスターが複数ゾーンの大都市ロケーションのいずれかにある場合は、自動的に、レプリカを 3 つ備えたマスターがデプロイされ、その大都市のゾーン間に分散されます。 OpenShift マスターはどのようにセットアップされますか? 複数ゾーンの大都市ロケーションにクラスターを作成すると、可用性の高いマスターが自動的にデプロイされ、3 つのレプリカがその都市のゾーン間に分散されます。 例えば、dal10、dal12、または dal13 ゾーンにクラスターが存在する場合は、複数ゾーン大都市であるダラスの各ゾーンにマスターのレプリカが分散されます。 作成したクラスター一覧はIBM CloudのダッシュボードからOpenShiftを選択すると確認でき、そのクラスターを選択してDeleteを選べば削除できます。 お正月の間に試してみて削除し忘れなどにお気をつけください。 Public Cloud上で稼働するフルマネージドなOpenShiftサービスには AOR（Azure Red Hat OpenShift ）やROSA（Red Hat OpenShift Service on Amazon）もありますので、今後は比較など行ってゆく予定です。

OpenStackを中心にCloud製品を担当しているソリューションアーキテクトの輿水です。 クラウドで利用可能なManaged OpenShiftと呼ばれるものには、Amazon Red Hat OpenShift、Azure Red Hat OpenShift、Red Hat OpenShift on IBM Cloudがあります。今回は、 Red Hat OpenShift on IBM Cloud 〜 ROKS （Red Hat OpenShift Kubernetes Service）のHands on Lab環境を利用してみます。IBM Cloudのライト・アカウントの登録が必要になりますが費用は発生しません。 （もしかすると同一アカウントで利用できる回数と時間に制限があるかもしれません） Hands on Lab環境を使うための準備 IBM Cloudのライト・アカウントの登録：登録時はメールアドレス、氏名程度の情報のみの入力で問題ありません Hands on Lab環境でできること IBM CloudポータルでのOpenShiftクラスターの管理 作成されたOpenShiftクラスターのOpenShift web consoleの利用 OpenShift web consoleを利用してアプリケーションをデプロイする command line interface (CLI)を利用してノードやプロジェクトの確認、アプリケーションのデプロイ OpenShift web consoleを利用してPodのリソース使用状況やログ、イベントの確認 OpenShiftに組み込まれているモニタリングの仕組みを利用してみる アプリケーションのスケーリング 利用の手順 アカウント登録 メールアドレス、初期パスワード、氏名を入力すると、登録したメールアドレスにIBM Cloudへのログインの案内のメールが届きますので、それに従ってログインしてください。 アカウントを登録してログインした状態で IBM Demos にアクセスします。 「Featured Collections」の左上の「Red Hat OpenShift on IBM Cloud」をクリックします、 次のページの一番下の左に「Hands on Labs」があるのでその横の「Hands on Labs for Red Hat OpenShift on IBM Cloud」をクリックします。 次のページの２段目「Hands On Labs」から「Lab 1: Red Hat OpenShift on IBM Cloud」の「Launch Lab」をクリックします。 Lab環境が自動的に構築されます。構築されるまでには少々時間がかかります。 Lab環境 左側にGetting StaredとExercise一覧が表示され、それに従って学習できるようになっています。Getting Staredの中にLab環境の説明が記載されています。 Lab環境には制限時間があり右上に「Remaining Time」が表示されています。利用時間の延長も可能でトータルで数時間利用できます。 （もしかすると同一アカウントで利用できる回数と時間に制限があるかもしれません） Exercise 1を開いてOpenShiftのweb consoleへのアクセス方法を確認します。「Red Hat OpenShift on IBM Cloud Basics」の本文の「Access the OpenShift web console」の部分で「Launch the IBM Cloud portal」のURLが表示されていますので、そのURLをクリックしてIBM Cloud portalにアクセスします。 ちなみにIBM Cloud portalを見るとOpenShiftのバージョンは実は4.4でした。この画面の右上に「OpenShift web console」があるので、クリックします。 見慣れたOpenShift web consoleが開きます。 ComputeのNodesを確認するとLab環境のOpenShiftクラスターは２台のノードで構成されていることがわかります。 弊社のワークショップで実施した内容（プロジェクトの作成やアプリケーションのビルド＆デプロイ）は当たり前ですが問題なく動作します。ストレージ周りを見てみると、Storage Classは用意されていますので、PV（Persistent Volume）を使うアプリケーションを試すことも可能です。 駆け足で説明しましたが、Lab環境を使ってみた感想としてはExercise内容も豊富で、無料でここまで体験できるのは素晴らしいと思います。ぜひ、使ってみてください。

OpenStackを中心にCloud製品を担当しているソリューションアーキテクトの輿水です。 「Red Hat OpenShift 4 Ops基礎編」「Red Hat OpenShift Container Storage編」をざっくり紹介しましたが、更に理解を深めたい方のためにオプションの演習が用意されています。OpenShiftの環境を運用管理する際に必要と考えられる項目です。 演習で実施する項目（選択制） OpenShiftクラスタのインストールの検証 アプリケーション管理の基礎 MachineSets・Machines・Nodesについて OpenShift infra node OpenShift ログ集約 OpenShift Monitoring クラスタのメータリング プロジェクトのクォータ OpenShift の Network Policy ベースの SDN Taint と Toleration OpenShiftクラスタのインストールの検証 演習ではOpenShift環境が既にInstaller-provisioned infrastructure （IPI）でインストールされているので、新たなインストールは実施しません。インストール完了後に生成されているファイルや情報についてocツールやWebコンソールを用いて確認します。 アプリケーション管理の基礎 ocツールを使用してサンプルアプリケーションをデプロイし、OpenShift Container Platform上でのコアコンポーネントやオブジェクト、アプリケーション管理の基本について学習します。「Ops基礎編」と重複する部分もありますが、PodやServiceの関連やyamlファイル内の記載に関する内容について詳しく説明しています。 アプリケーションのデプロイ方法 PodやServiceについての説明 PodやServiceのyamlファイルの詳細情報の見方 ReplicationControllersについて DeploymentConfigurationについて ReplicatonControllerとDeploymentConfigの関連性 アプリケーションのスケーリング アプリケーションのセルフヒーリング Routeについて MachineSets・Machines・Nodesについて nodeはコンテナがオーケストレーションされ実行される場所です。OpenShift 4においてnodeの作成と削除を含め、クラスターサイズをメンテナンスするために利用されるMachineSetとMachineについて学びます。「Storage編」の中でもこれらを利用してOCS用のnodeを追加しています。この演習ではクラスタのスケールアップとスケールダウンを行います。 replicas数を2にしてMachineSetをスケーリング Machineがプロビジョニングされnodeが使用可能な状態になる スケールアップしたMachineSetのreplicas数を2から1にスケールダウン MachineSetが消去されnodeも削除される OpenShift infra node クラスターの運用管理に必要なコンポーネントが稼働するmaster nodeとユーザーのアプリケーションが稼働するworker nodeがあります。OpenShiftでは運用管理コンポーネントのいくつかを稼働させるinfra nodeという役割があります。演習ではOpenShiftのinfra nodeを追加し、routerやregistryなどの運用管理コンポーネントを通常のworker nodeからinfra nodeの役割を持つnodeに移動する操作を行います。それまで稼働していたPodが終了し、新しいPodが起動してくる状況を確認できます。 OpenShiftの運用管理コンポーネント kubernetesとOpenShiftのcontrol plane services （"masters"） router container image registry cluster metrics collection ("monitoring") cluster aggregated logging service brokers routerがinfra nodeで稼働するよう指示するnodeSelector設定を適用することでrouterがinfra nodeで稼働する OpenShift ログ集約 OpenShift機能の一つに、実行中の環境とアプリケーションからログを収集して集約する機能があり、Elasticsearch、Fluentd、Kibana（EFK）によるログ集約のソリューションが含まれています。デフォルトではインストールされていないため、先述のinfra nodeにCluster Logging インスタンスを作成し構成する演習を行います。※infra nodeを作っておく必要があります 独自のネームスペースopenshift-loggingを作成する Elasticsearch と Cluster Logging Operator をクラスターにインストールする Logging CustomResource (CR) インスタンスを作成する Logging インストールを確認する Kibana にアクセスする Kibana を使ってクエリを行う インストールされたElasticsearch と Cluster Logging Operator EFKに関連するPodやPVC OpenShift Monitoring OpenShift Monitoring 機能について学びます。 Alertingの構成の確認 Metrics UIでPromQL (Prometheuses Query Language) クエリの実行 Dashboards UI (Grafana)のアクセスとリソースの表示 クラスタのメータリング Operator Meteringは、クラスタ全体でリソースがどのように使用されたかを提供するチャージバックおよびReportのツールです。WebコンソールからMetering Operatorをデプロイして、スケジュールに従ったレポート作成やワンタイムのレポート作成を行います。 OperatorHubからMetering Operatorのデプロイ Meteringインスタンスをインストール インストールの確認 Reportの作成 プロジェクトのクォータ デフォルトではプロジェクト内で使用できるオブジェクトの数やリソース（CPU、メモリなど）を制限しません。ResourceQuota と LimitRangeを利用してプロジェクトにクォータを適用する方法を学びます。 クラスタリソースのクォータ プロジェクト単位ではなく、クラスターにクォータを設定する方法を学びます。 ユーザーごとのクォータの設定 Labelによるクォータ OpenShift の Network Policy ベースの SDN OpenShiftはOpen vSwitch をベースにしたSDNを持っています。Network Policy ベースのアクセス制御を理解するために、NetworkPolicy カスタムリソース (CR) を利用することで異なるプロジェクト間でのアクセスを制限を行います。 Taint と Toleration infra nodeを利用した際にnodeSelector を使用してワークロードを配置する場所を制御しました。これに対して、特定のnodeにワークロードを配置しないといった要求に対して、Taintと Tolerationを使用してワークロードを制御する方法を実施します。 ざっくりと項目を並べましたが、node追加などでは処理されるまでの待ち時間もあるため、Ops基礎編・Storage編で２〜３時間程度、オプションも実施すると１日がかりになるくらいのボリュームがあります。ワークショップ環境は１日ご利用いただく前提で提供しています。

OpenStackを中心にCloud製品を担当しているソリューションアーキテクトの輿水です。 「Red Hat OpenShift 4 Ops基礎編」に続いて「Red Hat OpenShift Container Storage編」についてざっくり紹介いたします。OpenShiftでは、OpenShiftクラスターが動かすアプリケーション（ロギングやモニタリングなどのクラスターサービス）やユーザーが動かすアプリケーション（データベースなどのstatefulなアプリケーション）のために永続的なストレージが必要になります。 Persistent Volume（PV）：KubernetesのPodが利用できる永続ストレージ Persistent Volume Claim （PVC）：ユーザーが、PVを必要とする時にPVの要求を行うもの StorageClass：バックエンドのストレージシステムを定義 演習ではRed Hat OpenShift Container Storage（以降OSC）用に新たなworker nodeの追加を行い、OSC Operatorを利用してOpenShiftクラスターにOCSをデプロイし、アプリケーションからOCSのPVを利用するための設定方法などを学ぶことができます。 OpenShiftのために用意された最適なストレージ Red Hat OpenShift Container Storage編 内容のざっくり紹介 演習で実施する項目 Red Hat OpenShift Container Storageをデプロイするためのnodeを準備する OCS Operatorを使用してOCPクラスター上にOCSクラスターを作成する OCSが提供するRWO PVとRWX PVを使用して動作を確認する 1.Red Hat OpenShift Container Storageをデプロイするためのnodeを準備する 演習開始時にはあらかじめOCPクラスターにmaster nodeとworker nodeが用意されています。OCSはworker nodeで共存して稼働することも可能ですが、新たにOCS専用のworker nodeを３台、OCPクラスターに追加します。インフラ管理者の観点では、こういったクラスターマシンの追加や保守作業が必要になりますので、その操作方法も学んでいただけると思います。IPI（Installer Provisioned Infrastructure）方式でインストールしたOCPクラスターではMachine Setを使用することで簡単に新しいnodeを追加することが可能です。UPI方式の場合はMachine Setは利用できないため、手動でのnode追加が必要になります。 参照： マシン管理 4.6 | Red Hat Customer Portal 新しいMachine Setを作成 worker nodeの追加 追加したworker nodeにOCSで使用するためのラベルを付与 OCSクラスターを構成するには、3つの異なるAvailability Zoneのworker nodeを選択することが必要です。異なるAvailability Zoneではないworker nodeを選択することはサポートされません。そのため、Availability ZoneごとのMachine Setを作成します。そのMachine Setを作った状態ではMachineは作成されないので、oc scaleコマンドを利用してreplica数を1にセットすることでMachineを作成します。また、OCSを稼働させるnodeには「cluster.ocs.openshift.io/openshift-storage」というラベルが必要なため、oc labelコマンドでラベルを付与します。後述のOCS OperatorはOCSを構成する様々なPodをデプロイしますが、これらのPodはこのラベルが付いているnodeで稼働するようになっています。 Machine Set作成 replicas数に1を指定してMachine作成 ラベルが付いていることを確認 2.OCS Operatorを使用してOCPクラスター上にOCSクラスターを作成する OCS Operatorをインストールし、OCS Operatorを利用してOCSクラスターを作成します。これらの操作はCLIでも行うことができますが、演習ではWebコンソールを使って行います。Ops基礎編で行った操作と同様に、Webコンソールの「Operators」から「OperatorHub」を選択し「OpenShift Container Storage Operator」を手順に従ってインストールします。OCS Operatorのインストールが終わると、openshift-storageネームスペースにいくつかのPodが作成されていることが確認できます。 OpenShift Container Storage Operator インストール時に設定する項目 インストールされたOperator Podの一覧（一部） インストールしたOCS Operatorを利用して、OCSクラスターを作成します。クラスターを構成するnodeを選択し、Storage Class、OCS Service Capacityを設定して作成します。nodeの選択については、1.で準備した「cluster.ocs.openshift.io/openshift-storage」のラベルが付いているnodeが自動的に選択されていることが確認できます。 クラスター作成後は、クラスターの状態をOCPのWebコンソールの「Persistent Storage」で確認することがでできます。また、Rook-Ceph toolboxを利用してCephクラスターを確認することも行います。 3.OCSが提供するRWO PVとRWX PVを使用してPVの動作を確認する OCSクラスターが作成できたところで、RWO PVとRWX PVを作成してアプリケーションから利用します。RWO PVは、ひとつのworker node上で稼働するアプリケーションPodにバインドされ、PodがマウントすることでアプリケーションはPVにRead/Writeすることができます。RWX PVは、複数のworker nodeで稼働する複数のアプリケーションPodが共有してRead-Writeすることができます。 PVC(Persistent Volume Claim)を発行し、PVが作られることを確認する RWO(ReadWriteOnce) PVCを使ったアプリケーションをデプロイする 作成したPVの実体であるCeph RBDボリュームを確認する CephFSが提供するRWX PVを作成し、アプリケーションから使用する まずは、シンプルに、OCSをバックエンドとするStorageClassに対してボリュームサイズを指定するPVCを発行してみます。PVCをに記載した内容に応じたPVが作成されることが確認できます。これはOCSがDynamic Provisioning に対応しているため、PVCの発行後自動的にOCSにボリュームを作るよう命令し、そのボリュームがPVとして登録されるからです。 RWO PVの演習ではRailsアプリケーションとPVを利用するPostgreSQLデータベースをデプロイして、PVC発行・PV作成の動きと、アプリケーションによって書き込まれたデータが、アプリケーションを削除しても永続的に残っていることを確認します。RWX PVではfile-uploaderアプリケーションをデプロイして、複数のアプリケショーンが同一のRWX PVをどのように利用するかを確認します。 OpenShiftを利用する際に、ストレージバックエンドが何であるかを意識することはあまりないとは思いますが、このワークショップではOCSとOCPが統合されていて、運用面も含めて最適であるかを実感していただけると思います。OCP＋OCS合わせてのハンズオンは他ではあまりないので、是非、体験していただければと思います。

OpenStackを中心にCloud製品を担当しているソリューションアーキテクトの輿水です。今回はOpenStackではなくてOpenShiftについてです。 Red Hat では「 Container and Cloud Native Roadshow 」というイベントを不定期に開催しています。Red Hat OpenShift 4のハンズオンワークショップを通して、コンテナを利用したクラウドネイティブなインフラストラクチャの運用管理に関する基礎知識やプラクティスを学ぶイベントです。内容は開発者向けトラックと運用管理者向けトラックに分かれており、ここでは運用者向けトラックについてご紹介いたします。最近では11月末に開催しましたが、今後はハンズオンワークショップを積極的に開催してゆく予定です。 ハンズオンワークショップ画面 ハンズオンワークショップのポイント 利用者はひとつのRed Hat OpenShift 4 クラスター環境を専有してハンズオンを行う ガイドに従って自分のペースで実施 オンライン・ワークショップ Etherpadなどの共有ツールでインストラクターと質疑応答可能 運用者向けトラックは「Red Hat OpenShift 4 Ops基礎編」と「Red Hat OpenShift Container Storage編」＋「オプション：基礎より少し踏み込んだ項目」で構成されています。Red Hat OpenShiftとKubernetesとの違いや、Red Hat OpenShiftが独自に持つ概念（例えばプロジェクトやImageStreamとは何か？）などはワークショップ中では改めては説明いたしませんので、それらの内容はワークショップの前に、あらかじめ座学で学んでおくことをおすすめします。また、Red Hat OpenShift自体をインストールする事はワークショップに含まれていない点と、この環境で使用するRed Hat OpenShift 4のバージョンは4.5以上ですがバージョンによる差異を感じる内容ではない点はご了承ください。 Red Hat OpenShift 4 Ops基礎編 OpenShiftのコンセプトと基本的なクラスター管理方法を学びます。コンテナやKubernetesの経験がある方には違いを感じて頂きやすい内容です。UIを使ったアプリケーションのデプロイや、Prometheusを使用したモニタリング、Operator Lifecycle Manager を利用したOperatorによる機能追加などを学ぶことができます。 Red Hat OpenShift Container Storage編 OpenShiftに最適なクラウドネイティブストレージであるOpenShift Container Storage（以降OCS）の利用方法を学びます。 Operatorを利用してOpenShiftクラスターにOCSをデプロイし、アプリケーションからOCSの永続ストレージ（PV）を利用するための設定方法などを学ぶことができます。 Red Hat OpenShift 4 Ops基礎編 内容のざっくり紹介 演習で実施する項目 OpenShiftクラスターへのログインと動作確認 コンテナイメージのビルドとデプロイ Prometheus Operatorのデプロイとアプリケーションの監視 1.OpenShift4クラスターへのログインと動作確認 この演習では、CLI（ocコマンド）およびWebコンソールを利用してOpenShiftクラスターへのログインを行い、環境やリソースの動作確認を行います。 OpenShiftでは各プロジェクトに属するあらゆるリソースのメトリクスを取得できるようになっており、PrometheusやGrafanaなどを使うことでモニタリングおよび描画を実現しています。PrometheusはOpenShiftのUIに組み込まれており、WebコンソールからプロジェクトのCPUやメモリなどのリソース利用状況をグラフなどで確認できます。Webコンソールでは、クラスターを構成するNodeの情報、例えばmaster / worker のRole、そのNodeのCPUやメモリなどのリソース利用状況、そのNode上で動作するPod一覧を確認できます。Nodeの変更操作も可能ですが、演習では行いません。また、ocコマンドでのプロジェクトのワークロードの確認などを行います。この辺の内容は、一度でもOpenShiftを触ったことがある方には超基本かもしれません。 2.コンテナイメージのビルドとデプロイ OpenShiftクラスターに対するコンテナイメージのビルドやデプロイ操作をOpenShiftの機能を使用して行います。演習では S2I（Source-to-Image）というツールを使って「リポジトリURL : GitHubなどソースコード格納場所 」「S2I Builder Image : S2Iスクリプトが含まれているDockerイメージ」を指定してコンテナイメージを生成し、コンテナアプリケーションをデプロイします。OpenShiftは、カタログ機能 (Developer Catalog)を備えており、JavaやPython、nginxなどのS2I Builder Imageをカタログ上で選択することがきます。これらを利用してアプリケーションを簡単にOpenShiftクラスター上にデプロイできます。 演習での大まかな流れは「プロジェクトの作成→Developer Catalogからソースを指定してビルド＆デプロイ→作成されたアプリケーションを外部に公開するためのRoute作成」となってます。演習ではblogアプリケーションをデプロイしています。 デプロイされたアプリケーションの情報 3.Prometheus Operatorのデプロイとアプリケーションの監視 OpenShiftのざっくりとした操作方法とアプリケーションのデプロイを理解したところで、Operatorの導入、Operatorとアプリケーションの連携やOperatorに対する操作を学びつつOpenShiftの理解を深めます。この演習ではPrometheus Operatorを利用します。 Prometheus Operatorは、Kubernetesサービスのシンプルな監視定義およびPrometheusインスタンスのデプロイと管理を提供します。 Kubernetesネームスペース、特定のアプリケーション、またはチーム用のPrometheusインスタンスをOperatorを使って簡単に起動できます。 CRD（Custom Resource Definition）を通してPrometheusのバージョンや永続性、保存ポリシー、レプリカなどの基本設定ができます。 Kubernetesラベルクエリに基づいて、監視構成を自動的に生成します。 ステップ 監視対象となるJBoss EAPのアプリケーションを立ち上げる Prometheus JMX Exporterを利用してJMXからメトリクスを収集する Prometheus Operatorを活用して、JMXメトリクスの情報を可視化する 監視対象となるアプリケーション用の「jmx」というプロジェクトを作成し、アプリケーションをレポジトリから「jboss-eap-prometheus」イメージをビルドします。ビルドされたイメージはImageStreamに登録されます。登録された「jboss-eap-prometheus」を利用してアプリケーションをデプロイします。デプロイ後はアプリケーションを外部に公開し、アクセスできれば完了です。一連の操作の流れとしては「2.」と同じですが、Webコンソールではなく、ocコマンドで実施し、ビルド状況のログの確認なども行います。 Prometheus Operator用のプロジェクト「jmx-monitor」を作成します。OpenShiftクラスターに付随しているOperatorHubには様々なOperatorが登録されています。その中からPrometheusを検索し、特定のネームスペースに対してインストールするように指定して（デフォルトはAll namespaces on the clusterなので、A specific namespace on the clusterに変更する）、プロジェクト「jmx-monitor」にインストールします。インストール後の時点では、CRD（Custom Resource Definition）の登録やPod上へのPrometheus Operatorのデプロイが行われるだけで起動していません。これらの動作や設定内容をWebコンソールおよびocコマンドで確認しながら実施します。 先の処理で、Prometheus Operatorをデプロイした「jmx-monitor」プロジェクトと、アプリケーションをデプロイした「jmx」プロジェクトが存在しています。Prometheus Operatorがjmxを監視対象にするためにPrometheus Operatorのカスタムリソースを設定します。 参照： OpenShift Monitoring - 自律化したPrometheus運用 - - Speaker Deck 「Kind: Prometheus」でjmx-monitorを指定し設定すると、Prometheusに必要なコンテナがレプリカの数だけ起動します。起動したprometheus-operaterに対してRouterを設定し、外部からのアクセスを可能にします。「jmx-monitor」Podと「jmx」Pod間が通信可能になるようPodネットワーク許可設定を行います。「Kind: ServiceMonitor」を設定し、jmxを監視対象として設定します。 文章だけ見ると短く感じるかもしれませんが、実際に演習を行うとそれなりなボリュームです。演習ガイドに従って進めればプロジェクト作成、ビルド＆デプロイ、Route設定の一連の流れとOperator設定を理解できると思います。ワークショップにご興味があればご連絡ください。

クラウドインフラ全般を担当しているソリューションアーキテクトの伊藤です。   Red Hat OpenShift Platform(OCP)の今日時点での最新版であるOCP4.6.9を使ってGPUを扱ったワークロードを実行する環境を整えたいと思います。 AWS上に真っ新なOpenShiftをデプロイして、GPUが利用可能な状態までインストール作業を行い、最後にTensoflowからGPUを使ってワークロードを実行できるようGPUデバイスを確認します。 OCP w/ GPUのインストール OCP自体のデプロイ GPUインスタンスを利用してのインストール  マニフェストを生成して、特定AZでデプロイするインスタンスタイプを変更する  install-config.yamlからマニフェストを作成する p2.xlargeインスタンスタイプを変更する クラスタをデプロイする エンタイトルメントの設定 エンタイトルメントファイルを取得するまで １．レッドハットカスタマーポータルのRed Hatサブスクリプション管理[2]を開く ２．RHEL8EUSリポジトリにアクセス可能なサブスクリプションを探す クラスタにエンタイトルメントファイルが導入されていることを確認する NFD Operatorのインストール NodeFeatureDiscovery CRの作成 GPU Operatorのインストール ClusterPolicy CRの作成 GPUコンテナ起動の確認 注意点 エンタイトルメントの設定について ClustePolicyの作成 まとめ   OCP w/ GPUのインストール OCP自体のデプロイ 今回はOCPをAWS上でIPIというインストールタイプを使用してデプロイします。 IPIはインストーラ自身がインフラストラクチャ(AWS)が提供するAPIを操作してOCPをデプロイします。 大きく手順は変わりませんので、以下のRHEB過去記事 [0] をご参照ください。 [0]. https://rheb.hatenablog.com/entry/openshift41-aws-ipi 過去記事から、GPUを利用する際の変更点を以下に記載します。 GPUインスタンスを利用してのインストール GPUインスタンスを使用しますので、以下のようにinstall-config.yamlを変更します。 このdiffではAWSオレゴンリージョンを使用しています。   [takitou@takuya-PC ~]$ diff -uda aws469/install-config.yaml gpucluster-469/install-config.yaml --- aws469/install-config.yaml  2020-12-24 21:38:25.856836200 +0900 +++ gpucluster-469/install-config.yaml  2020-12-24 21:37:43.110992200 +0900 @@ -4,17 +4,29 @@ - architecture: amd64    hyperthreading: Enabled    name: worker -  platform: {} +  platform: +    aws: +      zones: +        - us-west-2a +        - us-west-2b +        - us-west-2c +      type: p2.xlarge    replicas: 3 controlPlane:    architecture: amd64    hyperthreading: Enabled    name: master -  platform: {} +  platform: +    aws: +      zones: +        - us-west-2a +        - us-west-2b +        - us-west-2c +      type: m5.xlarge    replicas: 3 metadata:    creationTimestamp: null networking:    clusterNetwork:    - cidr: 10.128.0.0/14 [takitou@takuya-PC ~]$     基本的にはこのinstall-config.yamlを使ってクラスタをデプロイしてしまえば良いのですが、 GPUインスタンスが提供されていないや一時的なリソースが枯渇しているなどの利用から 特定のAZで取得したいリソースが取得できないことがあります。 回避方法は以下の通りです、  マニフェストを生成して、特定AZでデプロイするインスタンスタイプを変更する  install-config.yamlからマニフェストを作成する (install-config.yamlは消去されます) [takitou@takuya-PC gpucluster-469]$ openshift-install create manifests INFO Credentials loaded from the "default" profile in file "/home/takitou/.aws/credentials" INFO Consuming Install Config from target directory INFO Manifests created in: manifests and openshift [takitou@takuya-PC gpucluster-469]$     p2.xlargeインスタンスタイプを変更する [takitou@takuya-PC gpucluster-469]$ grep -r p2.xlarge * manifests/cluster-config.yaml:          type: p2.xlarge openshift/99_openshift-cluster-api_worker-machineset-0.yaml:          instanceType: p2.xlarge openshift/99_openshift-cluster-api_worker-machineset-1.yaml:          instanceType: p2.xlarge openshift/99_openshift-cluster-api_worker-machineset-2.yaml:          instanceType: p2.xlarge   [takitou@takuya-PC gpucluster-469]$ diff -uda ../99_openshift-cluster-api_worker-machineset-2.yaml.bk openshift/99_openshift-cluster-api_worker-machineset-2.yaml --- ../99_openshift-cluster-api_worker-machineset-2.yaml.bk     2020-12-24 21:41:20.842380300 +0900 +++ openshift/99_openshift-cluster-api_worker-machineset-2.yaml 2020-12-24 21:41:30.322290100 +0900 @@ -41,7 +41,7 @@            deviceIndex: 0            iamInstanceProfile:              id: gpucluster-469-jf7fk-worker-profile -          instanceType: p2.xlarge +          instanceType: m5.2xlarge            kind: AWSMachineProviderConfig            metadata:              creationTimestamp: null [takitou@takuya-PC gpucluster-469]$     クラスタをデプロイする [takitou@takuya-PC gpucluster-469]$ openshift-install create cluster --dir=. --log-level=debug   エンタイトルメントの設定 通常のサーバでも特殊なリソースを利用する場合はカーネルの開発パッケージを取得してドライバをコンパイルするケースはよくあると思います。 コンテナ環境においても例にもれずこの作業が必要になります。 しかしながらOCPを使ったコンテナ環境においては自動でドライバのコンパイルや配置を行ってくれます。 この章である”エンタイトルメントの設定”というのは、レッドハットのパッケージリポジトリからカーネルの開発パッケージを取得するために必要となる証明書をOCPクラスタに投入するという作業になります。   以下のblog [1] を参照しています。 ”Entitled Builds on non-RHEL hosts”という章でエンタイトルメントファイルを取得し、 ”Cluster-Wide Entitled Builds on OpenShift”という章でクラスタにMCOを介してエンタイトルメントファイルを行えば、クラスタに存在するPodからレッドハットのパッケージリポジトリにアクセスすることが可能になります。 [1].  https://www.openshift.com/blog/how-to-use-entitled-image-builds-to-build-drivercontainers-with-ubi-on-openshift   エンタイトルメントファイルを取得するまで blog [1] を読むことでおおよその手順は分かるかと思いますが、どのようにエンタイトルメントファイルを取得すればよいか、悩まれることが多いかと思います。実際私はそうでした。 こちらではエンタイトルメントファイルを取得するまでを紹介します。   １．レッドハットカスタマーポータルのRed Hatサブスクリプション管理 [2] を開く [2]. https://access.redhat.com/management/ ２．RHEL8EUSリポジトリにアクセス可能なサブスクリプションを探す リポジトリ名 rhel-8-for-x86_64-baseos-eus-* にアクセス可能なサブスクリプションを探します。 この例では2システム見つかりました。ホスト名が記載されているはずなのでクリックします。 ホスト名をクリックしたら、続いてサブスクリプションタブをクリックします。 ここに現れる証明書のダウンロードというのをクリックしてzipファイルをダウンロードします。 注意点としてはここで利用する証明書には有効期限があるということです。 ダウンロードした時点でのサブスクリプションが有効な期間でのみ機能します。 ダウンロードしたファイルは2度ほどzipファイルを解凍して、出てきたpemファイルをさきほどのblog [1] 手順に従ってbase64エンコードしてMachineConfigマニフェストファイルを完成させます。その後MachineConfigをcreateしてください。 $ sed "s/BASE64_ENCODED_PEM_FILE/$(base64 -w 0 {ID}.pem)/g" 0003-cluster-wide-machineconfigs.yaml.template > 0003-cluster-wide-machineconfigs.yaml $ oc create -f 0003-cluster-wide-machineconfigs.yaml 無事に追加されると新たなノードのコンフィグが描画され、ノードは新たなコンフィグを適用するために自動的に順繰りに再起動していきます。 ローリングアップデートの様子はOCPのWebUIから確認することができます。   クラスタにエンタイトルメントファイルが導入されていることを確認する MachineConfigを経由してエンタイトルメントを追加すると、コンテナからレッドハットのパッケージリポジトリにアクセスすることが確認できます。 blogの通りpodを試しに作成してlogを確認します。   $ oc create -f 0004-cluster-wide-entitled-pod.yaml $ oc logs cluster-entitled-build-pod | grep kernel-devel | tail -n 1 kernel-devel-4.18.0-147.0.3.el8_1.x86_64 : Development package for ...     NFD Operatorのインストール NFDをインストールします。OCPのWebUIから導入することができます。 OCPのWebUIのAdministrator viewからOperators => OperatorHubへ行き検索窓にNFDを入力すると今回インストールするべきNFD Operatorを見つけることができます。     NodeFeatureDiscovery CRの作成 NFD Operatorを導入し、NodeFeatureDiscovery CRが利用可能になったらNFD CRを作成します。 Create NodeFeatureDiscoveryをクリックしたときに出るパラメータはデフォルトのままで問題ありません。   NFD CRを作成するとNodeのメタデータがいくつか追加されているものが確認できます。 この後、pciバスに接続されたベンダーIDを検出したことを示すラベルを元に、GPU Operatorが動作していきます。   [takitou@takuya-PC ~]$ diff -uda ip-10-0-154-235.us-west-2.compute.internal.2338 ip-10-0-154-235.us-west-2.compute.internal.250111 --- ip-10-0-154-235.us-west-2.compute.internal.2338      2020-12-24 23:38:57.187241600 +0900 +++ ip-10-0-154-235.us-west-2.compute.internal.250111    2020-12-25 01:16:10.546698200 +0900 @@ -4,10 +4,13 @@    annotations:      csi.volume.kubernetes.io/nodeid: '{" ebs.csi.aws.com":"i- "}'      machine.openshift.io/machine: openshift-machine-api/gpucluster-469-jf7fk-worker-us-west-2a-rbmh2 -    machineconfiguration.openshift.io/currentConfig: rendered-worker-5902397f3d48060b278c42c954908e12 -    machineconfiguration.openshift.io/desiredConfig: rendered-worker-5902397f3d48060b278c42c954908e12 +    machineconfiguration.openshift.io/currentConfig: rendered-worker-e8d29294cb3ee4c54eb943cf4e0b0f0c +    machineconfiguration.openshift.io/desiredConfig: rendered-worker-e8d29294cb3ee4c54eb943cf4e0b0f0c      machineconfiguration.openshift.io/reason: ""      machineconfiguration.openshift.io/state: Done +    nfd.node.kubernetes.io/extended-resources: "" +    nfd.node.kubernetes.io/feature-labels: cpu-cpuid.ADX,cpu-cpuid.AESNI,cpu-cpuid.AVX,cpu-cpuid.AVX2,cpu-cpuid.FMA3,cpu-cpuid.HLE,cpu-cpuid.RTM,cpu-hardware_multithreading,cpu-pstate.turbo,custom-rdma.available,kernel-selinux.enabled,kernel-version.full,kernel-version.major,kernel-version.minor,kernel-version.revision,pci-1013.present,pci-10de.present,pci-1d0f.present,storage-nonrotationaldisk,system-os_release.ID,system-os_release.VERSION_ID,system-os_release.VERSION_ID.major,system-os_release.VERSION_ID.minor +    nfd.node.kubernetes.io/worker.version: "1.15"      volumes.kubernetes.io/controller-managed-attach-detach: "true"    creationTimestamp: "2020-12-24T13:01:59Z"    labels: @@ -16,6 +19,29 @@      beta.kubernetes.io/os: linux      failure-domain.beta.kubernetes.io/region: us-west-2      failure-domain.beta.kubernetes.io/zone: us-west-2a +    feature.node.kubernetes.io/cpu-cpuid.ADX: "true" +    feature.node.kubernetes.io/cpu-cpuid.AESNI: "true" +    feature.node.kubernetes.io/cpu-cpuid.AVX: "true" +    feature.node.kubernetes.io/cpu-cpuid.AVX2: "true" +    feature.node.kubernetes.io/cpu-cpuid.FMA3: "true" +    feature.node.kubernetes.io/cpu-cpuid.HLE: "true" +    feature.node.kubernetes.io/cpu-cpuid.RTM: "true" +    feature.node.kubernetes.io/cpu-hardware_multithreading: "true" +    feature.node.kubernetes.io/cpu-pstate.turbo: "true" +    feature.node.kubernetes.io/custom-rdma.available: "true" +    feature.node.kubernetes.io/kernel-selinux.enabled: "true" +    feature.node.kubernetes.io/kernel-version.full: 4.18.0-193.37.1.el8_2.x86_64 +    feature.node.kubernetes.io/kernel-version.major: "4" +    feature.node.kubernetes.io/kernel-version.minor: "18" +    feature.node.kubernetes.io/kernel-version.revision: "0" +    feature.node.kubernetes.io/pci-1013.present: "true" +    feature.node.kubernetes.io/pci-10de.present: "true" +    feature.node.kubernetes.io/pci-1d0f.present: "true" +    feature.node.kubernetes.io/storage-nonrotationaldisk: "true" +    feature.node.kubernetes.io/system-os_release.ID: rhcos +    feature.node.kubernetes.io/system-os_release.VERSION_ID: "4.6" +    feature.node.kubernetes.io/system-os_release.VERSION_ID.major: "4" +    feature.node.kubernetes.io/system-os_release.VERSION_ID.minor: "6"      kubernetes.io/arch: amd64      kubernetes.io/hostname: ip-10-0-154-235      kubernetes.io/os: linux     GPU Operatorのインストール GPU Operatorをインストールします。OCPのWebUIから導入することができます。 GPU OperatorはNVIDIAが提供するOperatorとなっています。   ClusterPolicy CRの作成 GPU Operatorを導入し、ClusterPolicy CRが利用可能になったらClusterPolicy CRを作成します。     以下のようにyamlでの生成、編集が慣れていれば、yaml viewを使って編集することもできます。 ClusterPolicyのマニフェストでは各リソースで導入するバージョンを変更することが可能です。 デフォルト値での導入では要件とマッチしないケースなどでは、マニフェストの値を変更することで任意のバージョンを導入することができます。 全てのコンポーネントがコンテナ化されており、バージョンを変更してテストしたいなどのニーズにはコンテナの破棄と作成によって柔軟にかつ確実に対応することができます。     GPUコンテナ起動の確認 TensorFlowを実行するコンテナを以下のように生成します。 resouces => limits => nvidia.com/gpu:1 で取得するリソースを指定しています。 apiVersion: v1 kind: Pod metadata:   name: tens-pod spec:   containers:     - name: tens-container     image: tensorflow/tensorflow:latest-gpu-py3     command: ["/bin/sleep"]     args: ["3600"]     resources:       limits:         nvidia.com/gpu: 1  デバイスのリストを取得して確認します。 お疲れ様でした！無事GPUリソースを取得してコンテナを実行できていることが確認できました。 慣れてくると自分のPCからインストーラのコマンドを叩いてOCPのインストールに30分(待つだけ)、エンタイトルメントとOperatorの導入10分程度で完了し、昼食を取っている間にGPUコンテナ環境の構築が可能です。 注意点 エンタイトルメントの設定について このエントリーを書く以前からOperatorの動作検証などを頻繁に行っており、 今回このエントリーを書く最初に使ったGPU Operatorが必要とするエンタイトルメントファイルはかなり前のファイルでした。 このエンタイトルメントファイルの有効期限が切れており、このエントリーを書くときに検証した最初のステップでは見事に失敗しました。。 必要となるエンタイトルメントが含まれているサブスクリプションを選択しているか、有効期限のあるサブスクリプションを選択したか確認してMachineConfigに投入してください。   ClustePolicyの作成 NVIDIAのBlogではGPU OperatorのインストールはHelmを使ったパターンで紹介されています。 今回は簡易に導入することができるのを確認するためにWebUIを使いOperatorHubからインストールをしました。   まとめ   いかがでしたでしょうか、簡単にGPUコンテナ環境をセットアップすることができることが確認できたかと思います。 コンテナとGPUを使ったプラットフォームをご検討している際にも、お気軽にご相談ください。  

こんにちは、Red Hat SSA の小杉です。 本日は LinkedIn の レポート を深く読み、 LinkedIn がなぜ Apache Kafka を作ったのかについて見てみたいと思います。 kenta-kosugi.medium.com なお、LinkedIn で利用されているアクティビティデータは顧客が UI を操作したことに着目した"イベント"です。 Netflix でも Apache Kafka を使ったデータパイプラインを構築しており、そこでは以下の”イベント"を大量に扱っています。 ビデオ視聴活動 UI アクティビティ エラー パフォーマンスイベント トラブルシューティングと診断イベント netflixtechblog.com

OpenStackを担当しているソリューションアーキテクトの輿水です。 Red Hat OpenStack Platform 16 からリリースサイクルが年単位に変更されたこともあり、表立っては大きな動きはありません。あくまで「表立ってはありません」というだけで、日々機能拡張や改善が行われています。新リリースが発表される訳ではないので地味過ぎて「OpenStackってどうなってるんだっけ？」という状態だと思いますので、今更かもしれませんが、Red Hat OpenStack Platformのリリースについて緩くお話したいと思います。 メジャーバージョンリリース Upstreamのリリースを元にRed Hatがエンタープライズ向けに機能拡張などを行ってリリースするもので、RHOSP 13（Queensベース）やRHOSP 16（Trainベース）と表記されます。 マイナーバージョンリリース RHOSP 15以前では、バグフィックスやCVEs、拡張機能が提供されおり、後々のアップグレードのためにRHOSPを最新状態にしておいてくださいとお願いはしておりましたが、マイナーバージョンについてあまり意識することはなかったと思います。RHOSP 16から、RHOSP 16.0 / 16.1 といったマイナーバージョンが表記されるようになりました。RHOSP 16は Red Hat Enterprise Linux 8 のマイナーバージョンに密接に結びついており、利用するRHEL 8マイナーバージョンに対応してRHOSPのマイナーバージョンが変わります。このため、例えば16.0から16.1にアップデートする際は、OpenStackが稼働しているホストのOS再起動が必要になります。 16以前のロングライフリリース版RHOSP 13においては、現在メンテナンスサポート期間のため、数ヶ月に一度、メンテナンスリリースがあります。RHOSP 13の最新版は10/28にリリースされており、バグ修正と機能拡張についてはリリースノートをご確認ください。 https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/13/html/release_notes/chap-release_notes#red_hat_openstack_platform_13_maintenance_release_october_28_2020 ポイントリリース 16.1.zで表記されるリリースです。バグフィックスやCVEs、拡張機能が提供されます。ポイントリリースは概ね２ヶ月ごとにリリースされます。Red Hatが出している公式ドキュメントの リリースノート 16.1 | Red Hat Customer Portal を確認すると、今現在、16.1.2がリリースされていることがわかります。 RHOSP環境構築後、マイナーバージョンやポイントリリースについて、あまり意識することはないと思いますが、RHOSP 13からRHOSP 16.1へのin-placeアップグレードでは、RHOSP 13を最新版にアップデートすることを求められます。RHOSP 16については、16.0は既にフルサポート期限が終了しているため、現時点で導入するのであればバージョンは16.1になりますが、ストレージやネットワーク、Telemetryに関する機能はz単位で拡張されている場合もあるので、必要な機能がTP（テクノロジープレビュー）なのかGAなのかご確認いただければと思います。お探しの情報が見つからない場合などは、お問い合わせください。回答できる範囲で、回答させていただきます。 Red Hat OpenStack Platform 16.1 → 16.1.zへのマイナーアップデートの手順は「 Red Hat OpenStack Platform の最新状態の維持 」というドキュメントで公開されています。 Red Hat OpenStack Platform の最新状態の維持の流れ マイナーアップデートの準備 16.1はRHEL 8.2でサポートされているため、アンダークラウドとオーバークラウドのレポジトリをRHEL 8.2にロックする作業が必要です。ドキュメントではPlaybookを利用してアンダークラウド、オーバークラウド（ controller、compute ）の設定しています。昔ながらの１台ずつ手動で実行する方法もありますが、繰り返し同様の操作をする部分は積極的にPlaybook化しています。次にExtended Update Support (EUS) リポジトリーへの変更を行います。EUSレポジトリーにはRHEL 8.2 の最新のセキュリティーパッチおよびバグ修正が含まれています。更にRHOSPと AnsibleのリポジトリーをRHOSP 16.1用、ansible2.9用に変更します。16.0からアップデートしている際は、既存の設定はRHOSP 16用、ansible2.8用が設定されているので、これらを無効にします。container-toolsモジュールとvirtモジュールのバージョンを指定のものに変更し、コンテナーイメージ準備ファイルの中でtagを16.1に設定します。 アンダークラウドの更新 director（アンダークラウド）自体のアップグレードを行います。directorの再起動を伴いますがオーバークラウドの稼働には影響しません。アンダークラウドの更新後、オーバークラウド用のイメージをアンダークラウドに登録します。 オーバークラウドの更新 アンダークラウドからオーバークラウド（ controller、compute ）の更新を行います。この時点では、ノードの再起動などは行われません。この手順の中で、OpenStack Block StorageとOpenStack Computeに対して、データベースのオンラインアップグレードを行います。 オーバークラウドのリブート オーバークラウドのcontrollerを１台ずつPacemakerクラスター停止した後に、再起動します。controller１台が再起動している間、他の２台がサービスを継続するので停止は発生しません。これを他の２台に対して繰り返します。controllerの再起動後、computeを再起動します。再起動対象のcompute上に停止させたくないインスタンスがある場合は、他のcomputeにインスタンスを移行した後に再起動してください。 マイナーアップデートを行う場合も、事前に検証を行ってください。 RHOSP 15 から16.1へのアップグレード また、先日「RHOSP 13 から16.1へのアップグレード」について触れましたが、15から16.1へのアップグレードの手順も公開されましたので、現在RHOSP 15をご利用の方は参考にしていただければと思います。 access.redhat.com 最近、パッケージの場所を聞かれたので記載しておきます。アクセスするためにはRed Hat Customer Portalのアカウントと、該当するサブスクリプションが必要です。 ▼RHOSP 16.1のソフトウェア https://access.redhat.com/downloads/content/191/ver=16.1/rhel---8/16.1/x86_64/product-software ▼OpenStack Platform 用 Open vSwitch (OVS) パッケージ https://access.redhat.com/downloads/content/329/ver=/rhel---8/8/x86_64/packages

この記事は Rookと仲間たち、クラウドネイティブなストレージの Advent Calendar 2020 25日目の記事です。(過ぎてるけど…) こんにちは。レッドハットでストレージを中心にクラウドインフラを生業にしている宇都宮です。 今日はOpenShiftをはじめとするコンテナ環境における…に限らずの一般的な環境でストレージがハマりやすいわけについての 愚痴 お話しをしたいと思います。 あんまりストレージ詳しくないかたに読んでもらって、へぇと思っていただければ嬉しいです。 コンテナ環境でハマるストレージの落とし穴 コンテナ環境におけるストレージは、CSI(Container Storage Interface)の仕組みができてから、使い始めるにはかなり簡単になりました。パブリッククラウドにしろオンプレにしろ、そこにあるストレージをコンテナストレージとして使えるようになったからです。 とは言えまだまだチャレンジが多いエリアではあります。それはどんなストレージを要求するアプリケーションがコンテナで動いてくるのか分からないことに起因します。 例えばOpenShiftやKubernetesの環境で、そこにあるブロックストレージがRWO PVとして使えるからこれで大丈夫だろ、と間に合わせた後、ユーザーから『RWX PVが欲しい』と言われたとします。 ほぼ全てのブロックストレージはRWXはできませんので、RWXができるストレージを用意してなくてはなりません。NASが用意できればベストですが、ちゃんとしたNASを買うには3-4桁万円は要るので、そんな追加投資は難しい。急場しのぎでNFSサーバーを立てるパターンが良くありますが…アクセス制御が十分でない、Quotaも効かせられない、ベンダーサポートも期待できない、運用上で安定性に欠けるNFSサーバーがガンガン使われていき、いつ止まるか恐れおののきながら運用することになります。これはとてもおすすめできません。 この例の他にも、Snapshotを取りたいとか、ハイブリッドクラウド対応したいとか、様々なユーザーの要求は来る可能性はあります。また運用管理側でもツラい思いをする可能性もあります。 なぜストレージはハマりやすいのか コンテナ環境に限らず、一般的にストレージはハマりやすいシステムコンポーネントです。データを格納するだけのものがなぜハマりやすいのでしょうか。 第一の理由は、少なからずストレージを検討する時間が充分でないケースがあることです。 ストレージは大抵、システム検討において最後の方の段階で考えられます。これ自体は自然なことで、ビジネスパフォーマンスに直結するアプリケーションのレイヤーから、MW、OS、サーバーHW…と順番に降りて検討するのはある種の定跡です。ストレージへの要件は上の層にあるコンポーネントの要求が積み重なって出てくるので、最後にストレージの検討になるのは仕方ないことですが、問題はその時に充分な時間がない事です。 データを保管する物置なんだから簡単に決められるでしょ、と思っていたら痛い目を見ます。ストレージだって単にデータを保管するだけの簡単なものではありません。これが第二の理由です。 ストレージは思っている以上に、考慮すべき要素が多いものです。ブロック・ファイル・オブジェクトの種類はもちろん、接続インターフェースとプロトコル、冗長化の方法、容量、性能、デバイスの種類、コスト…とにかくまあ、たくさんあります。 厄介な(そして、面白い)ことに、これらの要素は独立ではなく依存関係があります。 例えば10PBのストレージが必要だという場合、これだけ大容量だとかなりの台数のサーバーやクライアントから共用することになるでしょうから、ブロックではなくファイルかオブジェクトになるでしょう。また、スケールアップでこの容量はほぼ不可能なので、スケールアウトの分散型ストレージになるでしょう。まず、分散ファイルシステムと分散オブジェクトストアのどちらが望ましいか？を決めなくてはなりません。 また具体的な構成を決める段階でも、コストを考えるとデバイスはHDDを使うことが得策でしょうし、RAID1のようなミラーリング/レプリケーションだと容量効率が悪いのでRAID6やErasure Codingを使うほうがコスト的に良さそうです。HDDのErasure CodingとなるとIOPSやレイテンシは期待できないですが、用途としてそれでも問題ないか…？などなど、ドミノのように次々と繋がってきます。 このあたりの繋がりは、ストレージに明るくない人にとっては結構つらいところがあると思います。なるべく早い段階からストレージに明るい人やベンダーを巻き込んで検討をする方がよいと思います。 クラウドネイティブとストレージ クラウドネイティブの考えは人によって三々五々違うでしょうが、プラットフォームを問わずにその場その場のリソースでダイナミックにアプリケーションを開発&稼働させるという観点では、そもそもストレージはクラウドネイティブと本質的に相容れにくいものと個人的には考えます。 あらゆるプラットフォームにあるアプリケーションから等しくデータにアクセスできるストレージは、クラウドネイティブのコンセプトに合致すると思います。 しかし相互接続性や性能やセキュリティなどの様々な観点から、全てのデータをこのようなストレージに入れることは事実上できません。どうしてもデータとデータを使うアプリケーションの特性上、ストレージは局所性を持つことを否めない、これが本質的に相容れにくいと考える理由です。 クラウドネイティブストレージって？ 本質的に相容れにくいのに、クラウドネイティブストレージって何だ？と思いますよね。 何をもってクラウドネイティブストレージなのかの定義は正直ハッキリとは分からないし、言ったもん勝ちみたいな雰囲気も感じます。 少なくともクラウドネイティブな開発手法や基盤で使える必要はありそうなので、コンテナ環境で永続ストレージとして使える事は求められそうです。 しかしそれ以上に何を備えるべきかは考え方によって違うと思います。 これは一つの主張ですが、Red Hat OpenShift Container StorageおよびRook-Cephは、 パブリッククラウドでもオンプレでもプラットフォームを問わず全く同じストレージシステムとして利用でき、 無停止で容易にアップデートおよびスケールでき、 全ての操作がAPIで行え、 他のリソースと同様に管理でき、 継続的に利用できる(=可用性が高い) ような特徴があります。これはクラウドネイティブな環境で使われるストレージにはこういう性質が必要だという主張です。 これが絶対というわけではもちろんなく、あくまで一つの答えであり、参考です。 もっとユーザーさん自身にしっくりする主張やストレージがあるかもしれませんし、これから生まれてくるかもしれません。 ご自身の環境にしっくりくるストレージを追究する事が重要ですので、継続的にストレージ動向をチェックしてもらえればと思います。 ストレージを生業にする者としての思い 今年も少なくないシステムトラブルのニュースがありました。そのうちいくつかはストレージが原因のものもありました。 これはインフラ全般的に言える事かもしれませんが、ストレージは悪目立ちしがちなコンポーネントです。データが新たな企業活動の資源だと言われて久しいながら、そのデータを預かるストレージが企業や組織体のパフォーマンスに直結する事は少なく、花形的な見え方で目立つことはほぼありません。 その割に簡単ではなく、僅かなミスが命取りになる修羅の世界と思われるかもしれません。 しかし反対の見方をすれば、ストレージほど安定稼働が求められているものは無いと思いますし、どんなシステムでもストレージには何かしら課題を抱えているもので、いわば最も銀の弾丸が求められている要素のひとつだと思います。 だからこそ毎年毎年新しいストレージ技術が研究開発され、大量のストレージスタートアップが生まれるのだと。 ストレージは世界中から求められている技術で、かつ進化し続ける奥が深い世界です。だからこそ、ストレージはつらいことも多いけど、来年も再来年もストレージで食って行こうと思うし、ストレージが好きだし面白いなあと思います。 というわけで、最後はやけにエモい話でしたが、今回はここまで。 それでは皆さん、良いお年を。

みなさんこんにちは。レッドハットの杉村です。Ansible のテクニカルサポートをしています。 2020年も終わりになりますが、Ansible のこの一年について振り返ってみようと思います。 Ansible Engine 新しいリリースはありませんでした。コミュニティ版は 2020/08/13 に 2.10 がリリースされています。 github.com 2.10 のサポートは残念ながらまだ提供できないという状況にあります。 access.redhat.com Ansible Tower 3.7 (2020/05/28) アーキテクチャを一新。パフォーマンスも大きく改善されまして、記事を一つ紹介しました。 rheb.hatenablog.com 3.8 (2020/11/18) Ansible Automation Platform 1.2 としてのリリースとなりまして、Private Automation Hub 4.2.0 を同梱するようになりました。こちらについても記事を一つ書いています。 rheb.hatenablog.com Tower としても大きな変更がいくつかありました。主なところはこのようなものがあります。 従来のライセンスキーファイル(JSON形式)を廃止し、メールで送付されるのを待つことがなくなった ダイナミックインベントリの設定方法を改善し、各インベントリプラグインでできることが全てTowerでもできるようになった プロジェクトに「Remote Archive」が利用できるようになった Automation Hub との連携が強化された コマンドラインツールや ansible.tower コレクションから設定の import/export ができるように改良された docs.ansible.com 個人的には 11月にはこちらのイベントに登壇する機会がありました。多くの皆さんに参加していただき、ありがとうございます。 enterprise-server.connpass.com 資料はこちらです。 おわりに Red Hat でテクニカルサポートの仕事をするようになりまして2年少々が過ぎましたが、Ansible も幅広く使っていただけるようになりましてありがたく感じています。 来年もさらに大きな変更が予定されています。安心してお使いいただけるよう、引き続き頑張っていこうと思います。 Ansible Towerの評価ライセンスリクエストはこちらからご利用いただけますのでお試しください。 www.redhat.com Red Hat Developer Subscription でも60日評価版をご利用いただけます。管理対象としては16ノードまで使うことができます。 developers.redhat.com rheb.hatenablog.com Happy Automation!

みなさんメリークリスマス。Red Hatのさいとうです。 Ansibleユーザグループの Advent Calender 最終日の記事として、2021年のAnsibleにどのような変化がありそうなのかといったあたりの個人的な予想を書こうと思います。 2020年のAnsibleのふりかえりについては、 コチラ をどうぞ。 Ansible Festから予想する2021年の変化 Ansible Projectで、翌年にどのような変化がおこりそうなのか...という情報の多くは、毎年開催される Ansible Fest のテクニカルトラックの情報から、ある程度予想することができます。2020年のAnsible FestはCOVID-19の影響から、完全なオンラインカンファレンスとして開催されました。内容はどなたでも無料で視聴できますがアカウント登録が必要です。 それでは、キーノートセッション(The future of Red Hat Ansible Automation Platform)で紹介されていた、2021年に提供されるであろう新しい機能について、以下にまとめてみます。 The future of Red Hat Ansible Automation Platform このキーノートセッションでは、タイトル通りAnsible Projectが今後注力していく技術分野について紹介されています。キーとなっているトピックは以下の2つです。 Private Automation-Hub Private Automation-Hub を利用して、RedHat Certified CollectionsとCommunity Collectionsをシームレスに利用できる環境の提供(RHELにおけるSatelliteのような利用イメージ)することがアナウンスされました。この新しいプロダクトはOSSの galaxy_ng のダウンストリーム版で、既に海外の一部のユーザでは利用されはじめています。 このPrivate Automation-Hubは、2020年にリリースされたAnsible Tower 3.8.0のインストールプログラムを利用してインストールします。このためTower 3.8.0のインストーラには、最近では比較的大きな規模の改修が入っています。リリース初版ということもあって、機能面での課題はまだまだ多い状態ですが、利用方法は コチラ で紹介されていますので、興味のあるかたは是非テストしてみてください。 Container Runtime for Ansible Ansible Playbookの実行環境をコンテナ化して提供してほしいという要望は、以前から多くのエンタープライズユーザから寄せられていました。今回のAnsible Festでは、このコンテナランタイムに対する現実的かつ具体的なアプローチとして、Ansible BuilderとAnsible Runnerを利用した実装が紹介されています。 Ansible Builder Ansible Runner Ansible Builderは、Ansibleの実行環境となるコンテナイメージを作成するためのプロダクトです。最新版(0.5.1)では、Ansibleが含まれたコンテナイメージをベースとして、追加で必要となるcollections, galaxy role そして、それらが依存しているPythonモジュール群をまとめてコンテナ化するための機能を提供しています。 このAnsible Builderで生成したコンテナイメージは、次期リリースのAnsible Runner v2.0.0から利用することができます。これまでのコンテナランタイムというと、以下のコミュニティドキュメントで紹介されているように、dockerコマンド経由でAnsible Playbookを指定して実行していましたが、Ansible Runner v2.0.0以降の実装では、ansible-runnerコマンドにコンテナイメージパスを引数として渡すことでシームレスに実行することができるようになりました。 Using Runner as a container interface to Ansible この最新版のAnsible Runner v2.0.0は、Ansible TowerのIsolated Nodeに対するジョブ実行で利用されている現在のv1.x系とは異なり、完全にコンテナランタイムを意識した実装となっています。2021年内におそらくリリースされるものと予想していますが、このバージョンのリリースとともに、Ansible Playbookのランタイムはコンテナでの利用が一般化するのではないかと考えています(私見です)。 この、Ansible Builder & Ansible Runnerについては、Ansible Festの技術トラック(Creating and using Ansible execution environments セッション)で更に詳しく紹介されています。Ansible Festに登録済のかたは必見です。 2021年のAnsibleとわたし 個人的に、2021年は、Ansible Playbookのランタイムが大きく変化する年になるのではないかと予想しています。 この赤帽エンジニアブログでも、チャンス(ぼくの空き時間)があれば、Ansible RunnerとAnsible Builderの利用方法について紹介したいと考えていますので、その時にまたお会いしましょう。来年は時間があるといいなぁ。 それでは皆さん、Happy Automation and Happy Christmas :)

  こんにちは、クラウドインフラ全般を担当しているソリューションアーキテクトの伊藤です。   OpenShift VirtualizationはRed Hat OpenShift Platform(OCP)上で仮想マシンを動作、管理させるためのコンポーネントになります。 OpenShift VirtualizationはCNCFのサンドボックスプロジェクトであるKubeVirt [1]を元にして開発、提供されており、OpenShiftのWebUIにあるOperatorHubより利用が可能です。   [1].  https://kubevirt.io/   ■アーキテクチャ ・仮想マシンはPodとして動作します ・仮想マシンの定義 ・仮想マシンをPodとして扱われている状態 ・VMとコンテナを一緒に扱う ■デモビデオ ■Katacodaによるハンズオン ■OpenShift Virtualizationの紹介、使いどころ OpenShift VirtualizationはOCP 4.5 よりGAとなりました。現在提供されている最新のOCPはバージョン4.6ですが、対応するOpenShift Virtualizationは別のバージョン番号で管理されており、それぞれOCP4.5ではOpenShift Virtualization 2.4、OCP4.6ではOpenShift Virtualization 2.5となっております。   OpenShift Virtualizationは仮想マシンをKubernetesのカスタムリソースとして扱います。 つまり従来の仮想マシン、仮想インスタンスそのものを扱うOpenStackや仮想マシン管理ソフトウェアとは異なるアプローチで設計されており、 永続ストレージのPV、ネットワーク機能のMultusをはじめ、Service、RouteといったOpenShift、Kubernetesによって提供されるリソースを活用することが可能です。 これによりOpenShift Virtualizationは従来の仮想マシン環境とコンテナ環境をシームレスに接続、移行するのに適したソリューションとなっています。   OpenShift Virtualizationコンポーネントのために追加で必要なサブスクリプションはありません、OpenShiftのサブスクリプションをお持ちのかたはどなたでもご利用頂くことが可能です。[2]   [2].  https://docs.openshift.com/container-platform/4.6/welcome/oke_about.html こちらのTable 1の [ OpenShift Virtualization ]をご確認ください。   OpenShift Virtualizationで使用できるゲストOSはRHEL6, 7および8、Windows Server 2012R2, 2016および2019と Windows10になっています。 Multusを介して、複数のNICやSR-IOVを扱う事とボンディングの利用ができます。     ■アーキテクチャ ・仮想マシンはPodとして動作します ・仮想マシンの定義 CRDで仮想マシンを定義します。このCRDはOpenShift VirtualizationのOperator Frameworkが提供します。 ・仮想マシンをPodとして扱われている状態 ・VMとコンテナを一緒に扱う   ■デモビデオ [3] のURLでは、OpenShift Virtualization自体のデプロイ、VMの管理、Windows Server 2019のデプロイといった基本的な機能と操作についてデモをしています。 また、既存の仮想マシン管理ソフトウェアであるVMware vSphereとRed Hat Virtualizationから OpenShift Virtualizationへ仮想マシンをインポートするデモについてもご確認頂けます。[4],[5]     [3].  https://demo.openshift.com/en/latest/openshift-virtualization/   [4].  https://youtu.be/nUgd7sN-9NA [5].  https://youtu.be/TDXg4j3VXrg   ■Katacodaによるハンズオン 以下の[6] のURLからKubeVirtでのハンズオンを体験することができます。 また、[7]のURLでは、手元のPCを使ってOpenShift Virtualizationのハンズオンラボを簡単に構築し試すことができます。   [6].  https://www.katacoda.com/kubevirt [7].  https://github.com/rdoxenham/openshift-virt-labs  

Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Quarkus.io のブログ記事、 How to Use Kafka, Schema Registry and Avro with Quarkus の翻訳記事です。 Kafka の世界では、Apache Avro は圧倒的に最も使用されているシリアライゼーションプロトコルです。Avro はデータシリアライズシステムです。Kafka と組み合わせることで、スキーマベースの堅牢で高速なバイナリシリアライズを実現します。 このブログ記事では、Quarkus アプリケーションでスキーマレジストリを使用して Avro を使用する方法を見ていきます。このブログでは、JVM モードを中心に紹介しています。ネイティブモードについては別の記事で取り上げます。 私たちは簡単なアプリケーションを書いていきます。それは HTTP リクエストを受信して、Kafka にペイロードを書き込んで、Kafka から読み出すというアプリです。簡単に言うと、同じアプリケーションが Kafka に書き込んでそこから読むということになります。ですが、明らかに現実世界では別のアプリケーションになるでしょう。 開始方法 では、最初から始めてみましょう。 https://code.quarkus.io にアクセスしてプロジェクトを作成し、以下の拡張機能を選択します。 RESTEasy JSON-B SmallRye Reactive Messaging - Kafka Connector Apache Avro プロジェクトをダウンロードして、お好きな IDE で開いてください。 生成された pom.xml にいくつかのコンテンツを追加する必要があります。 pom.xml ファイルを開き、以下の dependency を追加します。 <dependency> <groupId> io.apicurio </groupId> <artifactId> apicurio-registry-utils-serde </artifactId> <version> 1.2.2.Final </version> <exclusions> <exclusion> <groupId> org.jboss.spec.javax.interceptor </groupId> <artifactId> jboss-interceptors-api_1.2_spec </artifactId> </exclusion> </exclusions> </dependency> この依存関係は、Avro シリアライザとデシリアライザを提供します。このシリアライザ/デシリアライザには複数のバージョンがあります。このブログ記事では、Apicurio から提供されたものを使用しています。Confluent のものを使うこともできます（アーティファクトは Maven Central にはないので、追加のリポジトリを追加する必要があります）。 また、 avro-maven-plugin を追加する必要があります。 <build><plugins> の下に、以下を追加します。 <plugin> <groupId> org.apache.avro </groupId> <artifactId> avro-maven-plugin </artifactId> <version> 1.9.2 </version> <executions> <execution> <phase> generate-sources </phase> <goals> <goal> schema </goal> </goals> <configuration> <sourceDirectory> src/main/avro </sourceDirectory> <outputDirectory> ${project.build.directory}/generated-sources </outputDirectory> <stringType> String </stringType> </configuration> </execution> </executions> </plugin> このプラグインは、 src/main/avro ディレクトリにある Avro スキーマ ファイルからコードを生成します。この設定で、ようやくコードを書き始められます。 Avro スキーマ まず、Kafka で読み書きするオブジェクトを表すスキーマを書く必要があります。以下の内容の src/main/avro/movie.avsc ファイルを作成します。 { " namespace ": " me.escoffier.quarkus ", " type ": " record ", " name ": " Movie ", " fields ": [ { " name ": " title ", " type ": " string " } , { " name ": " year ", " type ": " int " } ] } pom.xml ファイルで設定された avro-maven-plugin は、 title と year の属性を持つ me.escoffier.quarkus.Movie クラスを生成します。クラスを生成するには、以下を実行します。 mvn generate-sources Movie リソース 最初に書くクラスは HTTP リクエストを受け取り、（Movie の）データをKafkaに書き込みます。 src/main/java/me/escoffier/MovieResource.java を以下の内容で作成します。 package me.escoffier; import me.escoffier.quarkus.Movie; import org.eclipse.microprofile.reactive.messaging.Channel; import org.eclipse.microprofile.reactive.messaging.Emitter; import org.jboss.logging.Logger; import javax.inject.Inject; import javax.ws.rs.Consumes; import javax.ws.rs.POST; import javax.ws.rs.Path; import javax.ws.rs.Produces; import javax.ws.rs.core.MediaType; import javax.ws.rs.core.Response; @Path( "/movies" ) @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public class MovieResource { private static final Logger LOGGER = Logger.getLogger( "MovieResource" ); @Inject @Channel( "movies" ) Emitter<Movie> emitter; @POST public Response enqueueMovie(Movie movie) { LOGGER.infof( "Sending movie %s to Kafka" , movie.getTitle() ); emitter.send(movie); return Response.accepted().build(); } } この JAX-RS リソースは簡単です。これは単一のエンドポイントメソッドを持ち、 /movies で JSON ペイロードを受信します。RESTEasy は JSON ドキュメントを自動的に Movie オブジェクトにマッピングします。 avsc ファイルで説明されているように、期待される JSON には title と year の 2 つのフィールドが含まれています。 リアクティブメッセージングで Quarkus を使用する場合、Kafka と直接やりとりすることはありません。あなたは Emitter を注入します。これはオブジェクト（私たちのmovie）をチャネルに送ります。アプリケーションの設定では、このチャネルを Kafka トピックにマッピングします。 設定といえば、 src/main/resources/application.properties を開いて、以下を追加します。 mp.messaging.connector.smallrye-kafka.apicurio.registry.url=http://localhost:8081/api mp.messaging.outgoing.movies.connector=smallrye-kafka mp.messaging.outgoing.movies.topic=movies mp.messaging.outgoing.movies.value.serializer=io.apicurio.registry.utils.serde.AvroKafkaSerializer mp.messaging.outgoing.movies.apicurio.registry.artifact-id=io.apicurio.registry.utils.serde.strategy.SimpleTopicIdStrategy mp.messaging.outgoing.movies.apicurio.registry.global-id=io.apicurio.registry.utils.serde.strategy.GetOrCreateIdStrategy mp.messaging.outgoing.movies.apicurio.registry.avro-datum-provider=io.apicurio.registry.utils.serde.avro.ReflectAvroDatumProvider この設定は少し説明が必要です。まず、 mp.messaging.connector.smallrye-kafka.apicurio.registry.url でスキーマレジストリの URL を設定します。Apicurio の代わりに Confluent のシリアライザ/デシリアライザを使用した場合、 mp.messaging.connector.smallrye-kafka.schema.registry.url という名前のプロパティです。 mp.messaging.outgoing.movies は movies チャンネルを設定します。 connector 属性は、SmallRye Kafka コネクタがチャネルを管理していることを示します。 topic 属性はトピックの名前を指定します（これはチャンネル名と一致するので、この場合は省略できます） 。 value.serializer は使用するシリアライザを設定します。ここでは、Apicurio が提供する io.apicurio.registry.utils.serde.AvroKafkaSerializer を使用します。 registry.* プロパティは、レジストリがスキーマをどのように扱うかを設定します。 Movie の使用 後半のアプリはさらにシンプルになっています。受信した映画をログに記録するだけです。 src/main/java/me/escoffier/MovieConsumer.java を以下の内容で作成します。 package me.escoffier; import me.escoffier.quarkus.Movie; import org.eclipse.microprofile.reactive.messaging.Incoming; import org.jboss.logging.Logger; import javax.enterprise.context.ApplicationScoped; @ApplicationScoped public class MovieConsumer { private static final Logger LOGGER = Logger.getLogger( "MovieConsumer" ); @Incoming( "movies-from-kafka" ) public void receive(Movie movie) { LOGGER.infof( "Received movie: %s (%d)" , movie.getTitle(), movie.getYear()); } } @Incoming アノテーションは、 movies-from-kafka チャネル上を遷移する各 Movie オブジェクトに対してメソッドが呼び出されることを示しています。今回はケースでは、単純にログメッセージを書きます。 もうすぐそこまで来ています。Kafka からの受信を設定する必要があります。 application.properties を再度開き、以下を追加します。 mp.messaging.incoming.movies-from-kafka.connector=smallrye-kafka mp.messaging.incoming.movies-from-kafka.topic=movies mp.messaging.incoming.movies-from-kafka.value.deserializer=io.apicurio.registry.utils.serde.AvroKafkaDeserializer mp.messaging.incoming.movies-from-kafka.auto.offset.reset=earliest mp.messaging.incoming.movies-from-kafka.enable.auto.commit=false mp.messaging.incoming.movies-from-kafka.apicurio.registry.avro-datum-provider=io.apicurio.registry.utils.serde.avro.ReflectAvroDatumProvider これらのプロパティは movies-from-kafka を movies Kafka トピックに対応付けます。また、デシリアライザ（ io.apicurio.registry.utils.serde.AvroKafkaDeserializer ）の設定も行います。Kafka の自動コミット（ enable.auto.commit=false ）を無効にしています。これはリアクティブメッセージングがオフセットコミットを処理してくれるためです。 送信者と受信者が同じアプリケーション内に存在しています。そのため、同じチャネル名を使用することはできません。 ちょっとしたインフラ アプリケーションを実行する前に必要なのは以下です。 Kafka のブローカー Apicurio のスキーマレジストリ プロジェクトのルートに以下の内容の docker-compose.yaml ファイルを作成します。 version : '2' services : zookeeper : image : strimzi/kafka:0.11.3-kafka-2.1.0 command : [ "sh" , "-c" , "bin/zookeeper-server-start.sh config/zookeeper.properties" ] ports : - "2181:2181" environment : LOG_DIR : /tmp/logs kafka : image : strimzi/kafka:0.11.3-kafka-2.1.0 command : [ "sh" , "-c" , "bin/kafka-server-start.sh config/server.properties --override listeners=$${KAFKA_LISTENERS} --override advertised.listeners=$${KAFKA_ADVERTISED_LISTENERS} --override zookeeper.connect=$${KAFKA_ZOOKEEPER_CONNECT}" ] depends_on : - zookeeper ports : - "9092:9092" environment : LOG_DIR : "/tmp/logs" KAFKA_ADVERTISED_LISTENERS : PLAINTEXT://localhost:9092 KAFKA_LISTENERS : PLAINTEXT://0.0.0.0:9092 KAFKA_ZOOKEEPER_CONNECT : zookeeper:2181 schema-registry : image : apicurio/apicurio-registry-mem:1.2.2.Final ports : - 8081:8080 depends_on : - kafka environment : QUARKUS_PROFILE : prod KAFKA_BOOTSTRAP_SERVERS : localhost:9092 APPLICATION_ID : registry_id APPLICATION_SERVER : localhost:9000 この docker-compose ファイルは必要なものをすべて起動します。Apicurio のレジストリのプロパティが気になる方もいらっしゃるかもしれません。実は Apicurio のレジストリも Quarkus のアプリです。 実行する時間 では、始めましょう。まずは、インフラの整備を一緒に始めましょう。 docker-compose up -d docker-compose down; docker-compose rm でインフラを停止します。 そして、アプリケーションを起動します。 mvn compile quarkus:dev 一度起動したら、別の端末を開いて映画を投稿します。 curl --header "Content-Type: application/json" \ --request POST \ --data '{"title":"The Shawshank Redemption","year":1994}' \ http://localhost:8080/movies curl --header "Content-Type: application/json" \ --request POST \ --data '{"title":"The Godfather","year":1972}' \ http://localhost:8080/movies curl --header "Content-Type: application/json" \ --request POST \ --data '{"title":"The Dark Knight","year":2008}' \ http://localhost:8080/movies curl --header "Content-Type: application/json" \ --request POST \ --data '{"title":"12 Angry Men","year":1957}' \ http://localhost:8080/movies アプリケーションログでは、以下のように表示されているはずです。 2020-09-11 16:42:22,597 INFO [MovieResource] (executor-thread-1) Sending movie The Shawshank Redemption to Kafka 2020-09-11 16:42:22,619 INFO [MovieResource] (executor-thread-1) Sending movie The Godfather to Kafka 2020-09-11 16:42:22,624 INFO [MovieConsumer] (vert.x-eventloop-thread-0) Received movie: The Shawshank Redemption (1994) 2020-09-11 16:42:22,641 INFO [MovieConsumer] (vert.x-eventloop-thread-0) Received movie: The Godfather (1972) 2020-09-11 16:42:22,644 INFO [MovieResource] (executor-thread-1) Sending movie The Dark Knight to Kafka 2020-09-11 16:42:22,663 INFO [MovieConsumer] (vert.x-eventloop-thread-0) Received movie: The Dark Knight (2008) 2020-09-11 16:42:22,669 INFO [MovieResource] (executor-thread-1) Sending movie 12 Angry Men to Kafka 2020-09-11 16:42:22,688 INFO [MovieConsumer] (vert.x-eventloop-thread-0) Received movie: 12 Angry Men (1957) 結論 やりました！数行のコードと少しの設定で、Kafka、Avro、スキーマレジストリを Quarkus アプリケーションに統合できます。このデモのコードは https://github.com/cescoffier/quarkus-kafka-and-avro にあります。readme ファイルには、それを実行するための手順が記載されています。 Quarkus 1.9 では、メッセージングやリアクティブ全般についての新しい機能がたくさん追加されます。ご期待ください！

こんにちは。Red Hat で、ソリューションアーキテクトをしています花田です。 OpenShift Advanced Cluster Management for Kubernetes (ACM) と AWS 環境への OpenShift の超簡単新規構築！！ で、岡野さんが既にご紹介してくれている ACM (Advanced Cluster Management) という製品の新バージョンが11月にリリースされ、晴れて ACM 2.1となりました。 今回は、この製品が生まれた背景と、製品の概要についてもう少し深掘りしてみたいと思います。 ACM という製品が生まれた背景 一般的には「そろそろキャズムを超えた？」言われている Kubernetes ですが、一方では、 Kubernetes や、 Red Hat 版の Kubernetes である OpenShift を使って複数のクラスターをデプロイして管理するようなヘビーユーザーも現れ始めました。 開発、ステージング、プロダクション毎に Kubernetes クラスターを用意する場合もありますし、本番クラスターを多数運用しているケースもでてきてます。 Kubernetes で言う所の クラスター とは、 Master Node と呼ばれる管理ノードと、それらが管理する Worker Node というユーザーアプリケーション（コンテナ）が稼働する Node 群をひとまとめにした概念です。 さらに、最近では、5Gの普及を見据えて「ユーザーに近い Edgeで何か処理を行う事で、新しいサービスが開始できるのでは？」という期待も生まれてきています。 Edge 環境にアプリケーションを配布するには、フットプリントの小さいコンテナの使用が期待されており、そうなると当然、全国津々浦々の Edge 環境にコンテナを動かすためのインフラである Kubernetes のクラスターを設置したい。という話がでてきます。(リモート環境に、 Kubernetes クラスターを配置するのではなく、コンテナを動かす Worker Node だけを遠隔の Edge に配置するというアイディアもありますが、その話はまたどこかの機会に…) そう言った背景もあり、 Kubernetes のクラスターをたくさん管理しなければいけない時代というのが、一部では始まっている or 始まりつつある状況になっています。 クラスターが数個の場合 このような状況の中で顕在化してきた問題が、多数の Kuberentes クラスターをどのように効率的に管理するか。という問題です。例えば、数個の Kuberentes クラスターであれば、一つ一つの手作業でも運用可能と言えるでしょう。 クラスターが10個の場合 しかし Kuberentes クラスターの数が多ければ、その運用管理に目眩がしてくる事が予想されます。 終電で帰る事を目標にしていたら、いつのまにか始発で帰る事に目標がすり替わって、幾つもの夜を越える事になるかも知れません。 こうした状況の中で生まれてきたのが、今回ご紹介する Red Hat Advanced Cluster Management for Kubernetres 、通称 ACM です。 ACMによるクラスター管理 ACM ができる事は、大まかに4つあります。 1. 管理対象のクラスターの可視化 管理対象のクラスターのモニタリング機能や、管理しているリソースの検索機能等を提供しています。 Kubernetes の世界では Observability(可観測性) という単語がよく出てきますが、ここではシンプルに「可視化」と呼んでも良いでしょう。 2. クラスターのライフサイクル管理 ここで言うライフルサイクルは、クラスタの作成・削除・アップグレードを指します。 OpenShift クラスターをパブリック・クラウド・プロバイダーなどの環境に簡単にデプロイする事が可能です。 3. クラスターをまたがったアプリケーションのデプロイ 指定したクラスター、 namespace 等にアプリケーションを配布する事が可能です。 4. クラスターに対する統一したポリシーの適用 これは各クラスターに管理用の namespace を必ず作成したい、セキュリティの ポリシー があってそれを適用したい。等の要件があった時に、ポリシーを作成して対象としたい クラスター や namespace にデプロイして ポリシー 違反を検知・修正する事ができるようになります。 どんな環境をサポートするか？ ACM は、 Hub クラスター と呼ばれるクラスターから管理対象となる Kubernetes クラスターを管理します。管理対象のクラスターを Managed クラスター と呼びます。管理 される クラスターなので、受動態になって Manag ed クラスターです。 ACM Hub Cluster と Managed Cluster ACM の Hub クラスター (管理対象をまとめる「親」)のインストール先として、サポートされるのは、 Red Hat OpenShift だけになります。 ACM 自身は、 Pod の集合体ですので、他のユーザー・アプリケーションとも同居できますが、それなりにリソースを要求するため、運用も考えて、基本的には、 ACM 専用の Hub クラスター を作成する事をおすすめしています。 一方で管理対象の Managed クラスター としては、 OpenShift の他に、 AKS 、 EKS 、 GKE 等の Kubernetes もサポートしています。 これは、 ACM Hub クラスター から見ると、管理は Kubernetes の APIサーバー を通したものになるものになるため、Certify された Kubernetes であれば、共通のプロトコルで話す事ができるからです。 原理的には、 Kuberntes であれば、管理対象に追加できるはずですが、 ACM は商用サポートを提供する製品ですので、テストが行われた正確なサポート対象というものが定義されています。 また、クラスターの作成・削除等の Kubernetes より下のインフラーレイヤーが関わる作業は、インフラを部分を提供するベンダー(パブリック・クラウド・プロバイダー/仮想化環境ベンダー/物理環境のベンダー) のAPIやサービス依存の部分があったり、クラスターの更新は Kuberntes を提供するベンダーのサービスによって独自のコンポーネントを含むものとなるため、環境によって必要な作業は異なってきます。 ACM のサポート範囲は、環境に異なる部分があるため、詳細をお知りになりたい方は、以下のリンクをご参照ください。 Red Hat Advanced Cluster Management for Kubernetes 2.1 Support Matrix 管理対象クラスターの可視化 ACM から作成されたクラスター、 ACM にインポートされたクラスターはダッシュボードから一元的に確認する事ができます。 管理対象クラスターの可視化 このダッシュボードでは、環境内でデプロイされているクラスターの接続状態や、Nodeの数、Pod の数、コンプライアンスの状態 etc…等が表示されています。 また、 Kuberntes は、 リソース というオブジェクトの集合体です。 namespace や、 ConfigMap 、 Pod 、 Node 、 Role …と様々な リソース から構成されています。 ACM では、環境で起きた問題や現在の設定を確認するために、これらの リソース を検索して見つけ出す Dynamic Search 機能を提供しています。 例えば、多数のクラスターがある環境でも、特定の cluster のある namespace に所属する Pod の一覧を検索条件で指定して表示するような事が Dynamic Search 機能で可能になっています。 クラスターのライフサイクル管理 2つめの大きな柱の機能として「クラスターのライフサイクル管理」があります。 これは、 ACM の Hub クラスター から、 OpenShift クラスターを「作成」「削除」「更新」する事のできる機能です。 クラスターの作成画面 (デプロイ先を選択して Nodeのスペックなどを指定していきます) 各クラウド・プロバイダーや仮想化環境等を操作するためのクレデンシャル情報等を事前に作成しておく必要はありますが、それができていれば、コンソール画面から Worker Node 等の本数やスペックを選択して、新規の OpenShift クラスターを簡単にデプロイする事ができます。 また、 ACM 2.1 からは、 vSphere 環境、 Baremetal 環境への OpenShift クラスターのデプロイもサポート対象に加わりました。 これらの機能は、内部的には、 OpeShift 4.6 からサポートされた vSphere 環境、 Baremetal 環境への IPI(Installer-Provisioned Infrastructuer) を使用しています。 IPI とはある一定の条件が整っている環境 ( DNS に事前に必要なベースドメインが登録されている等。対象とする環境によって条件が異なる) であれば、 OpenShift の Node OSのインストールから、その上の OpenShift ソフトウェアのインストールまでを自動化してくれるインストール方式です。 ただし、 AKS 、 EKS 、 GKS と言ったクラウド・プロバイダー独自の Kubernetes サービスについては、クラスターの作成等の機能はサポートされていません。これらのクラウド・プロバイダー独自の Kubernetes サービスについては、既に作成されているクラスターを インポート して、管理対象に加える事が可能です。 インポート する事で「 アプリケーショ のデプロイ」や「 ポリシー のデプロイ」を使用した管理を行う事ができるようになります。 アプリケーションのデプロイ 3つ目の大きな柱の機能として「 アプリケーション のデプロイ」があります。 これは アプリケーション を定義しておき、 ラベル を使用して、 ラベル の条件が一致するクラスターに対して アプリケーション をデプロイする機能です。 「 アプリケーション のデプロイ」では、 ラベル を使用する事で、特定の namespace にだけ アプリケーション をデプロイすることや、 dev ラベルが付いている環境にだけ アプリケーション をデプロイする。等のように細かく アプリケーション のデプロイ先を指定する事ができます。 アプリケーションのデプロイ (デプロイされたリソース等が表示されている) これらの アプリケーション は、YAMLで定義されます。 アプリケーション のパッケージングの具体的な情報( deplyment 、 PVC 、 Service 等のリソース定義)は、 GitHub 等のレポジトリに置かれているものを アプリケーション の定義から参照する形になります。 尚、 ACM 2.0を触った事がある方、向けの話になりますが、 ACM 2.0では、一つの アプリケーション を作成するのに、それに紐付く「チャネル」「サブスクリプション」「デプロイメント」などの カスタム・リソース をそれぞれ作成しないといけませんでしたが、 ACM 2.1ではそれらの カスタム・リソース を意識しなくても GUIの設定のみで アプリケーション を作成できるように改善されました。 ACM は、アプリケーションの チャネル (YouTube のチャネルと同じイメージです。デプロイ対象のアプリケーションのレポジトリを表します。) を常に監視しており、変更があった場合、自動的に更新された アプリケーション のデプロイを開始します。 例えば、 GitHub 上で開発用の development ブランチと、本番用の production ブランチを作成していたとします。 ACM を使用すると、 devlopment ブランチに更新があった場合、 development ブランチのアプリケーションを devクラスター にデプロイさせるように構成する事ができます。また、 GitHub 上で、そのコードが production ブランチにマージされたタイミングで、 prodクラスター に production ブランチのアプリケーションをデプロイするという事も可能です。 ACMを使ったGitOps その他にも アプリケーション をデプロイしたくない時間帯を指定したり、反対に アプリケーション をデプロイしたい時間帯を指定する事が可能になっています。 ポリシーによるガバナンスとリスク管理 4つ目の大きな柱は、 ポリシー による環境のコンプライアンス管理です。 管理者がポリシーを YAML で作成して、クラスターに配布して、 ポリシー に適合している設定が行われているか確認する事ができます。 ポリシー 違反や現在の ポリシー の遵守情報は、 ACM のダッシュボード画面に表示されます。 ポリシー管理コンソール (ポリシーへの適合 / 違反状況などが表示されている) この ポリシー の配布も、アプリケーションの配布と同じように、 ラベル によってポリシーの配布対象を特定のクラスターだったり、特定の namespace に限定する事が可能です。 また ポリシー の内容にもよりますが、修正できる内容であれば、 ポリシー 違反があった場合に自動で ポリシー に適合するように修正を行うように指定する事も可能です。 ポリシー はある程度 GUIで書くことが可能ですが、現実的には YAML でゴリゴリと ポリシー を作成して行く事になると思います。 とは言え、そう言った作業を楽にするためのサンプルの ポリシー が提供されており、 GitHub で公開されています。これらの ポリシー の一部のワードを自分の環境用に書き替える事で、簡単に ポリシー の作り方を学ぶ事ができます。 標準で提供されるサンプルポリシー ポリシー については、製品としてバンドルされているものと、コミニティ版が存在していて、どちらも GitHub で公開されています。 実際に ポリシー を使用してどのような事ができるかは、これらのサンプルを見るのが一番わかりやすいと思います。 製品にバンドルされているポリシー github.com コミニティ作成のポリシー github.com ACM の今後 ACM は、現状では OpenShift と同じで、3ヶ月毎のリリースが予定されています。 今回は、 ACM の基本的な機能部分の概略だけを解説しましたが、 ACM 2.1 では、 Red Hat の自動化ツールである Ansible との連携の Tech Preview が開始されたり、統合モニタリング機能として Prometheus で収集したデータを Hubクラスター で見るためのダッシュボード、 ポリシー 管理の方法として Gatekeeper への対応などが盛り込まれました。 これらについては追々解説して行きたいと思います。

この記事は Rookと仲間たち、クラウドネイティブなストレージの Advent Calendar 2020 18日目の記事です。 こんにちは。レッドハットでストレージを中心にクラウドインフラを生業にしている宇都宮です。 今日はOpenShiftにおけるバックアップについてお話ししたいと思います。 OpenShiftのバックアップ 言うまでもなくOpenShiftはImmutableなプラットフォームです。 ですから従来のいわゆるシステムバックアップに相当することはあまり行わないと思います。 Master etcdのバックアップや各種Cluster ResourceのYAMLファイルを別のところに取っておいてもまあ損はないですよ、くらいでしょう。 しかしStatefulアプリケーションで使われるデータは、ガシガシ上書きされますし失くなったらそれっきりです。つまりPersistent Volumeのバックアップはした方がいいです。 PVのバックアップはどうすればよいのでしょうか。 docs.openshift.com には etcd のバックアップ/リストアについては書かれていますが、PVのバックアップについては全く記載がありません。だから何かしらユーザー側で取る方法を考えなくてはなりません。 PVはとどのつまりブロックデバイスなりファイルシステムなりなので、ストレージシステムのSnapshotを使ったり、横から覗いて吸い上げれば簡単にできそうに思えます。しかし、人手と時間をかけず、Consistentなデータをバックアップ/リストアする、これが意外と難しかったりします。 それを手助けするのが、OADPです。 OADP: OpenShift API for Data Protection OADPはOpenShiftにおけるData ProtectionのためのAPIです。(そのまんま) APIもありますが、中では Velero が含まれている、というかVeleroをインストールして設定します。Veleroについてはこちらの坂下さんのblogがわかりやすいかと思います。 Kubernetesのリソース・PersistentVolumeをバックアップするVeleroの検証 - Qiita ちなみにOADPのupstreamは Konveyor の中で開発されています。Konveyorではcraneやforkliftなど他にも面白いソフトウェアが開発されているので一見の価値ありです。 github.com OADPのアーキテクチャ OADPはOpenShiftクラスターやNamespace単位でCluster ResorceとPVのバックアップをしてくれます。それだけでなくInternalなcontainer imageもバックアップします。 OADPは単にVeleroが入っているだけでなく、YAMLやimageを引っこ抜くためのPluginが含まれていたりします。 またOADPの特徴の一つは、OpenShiftクラスターの外部にバックアップするために、3rd partyのバックアップソフトウェアと連携する用意があることです。 具体的に言えば"Data Mover"というコンポーネントが、Veleroで取ったVolume Snapshotを見ながら外部バックアップできるようにしてくれます。 OADPで用意するのはData MoverのControllerだけで、実際にやるにはバックアップソフトウェアのData Mover pluginが必要となります。 pluginはバックアップソフトウェアベンダーさんが開発・提供しますので、どのバックアップソフトウェアが対応するかの情報は別途公開されると思います。 OADPを使ったOCSのCSI Snapshot 昨日リリースされた最新のOCS(OpenShift Container Storage) 4.6において、Red HatはCSI Snapshotをサポートするようになりました。 OADP FAQ - Red Hat Customer Portal OADPは初期リリースがVelero 1.4以上なので、最初からCSI Snapshotに対応しています。 そのためOADPでOCSのCSI Snapshotを取ることができます。下の動画でAnnetteがデモをしてくれているのでご覧下さい。(デモは25:00あたりから) https://www.youtube.com/watch?v=OcIZ3SfHyFY&feature=emb_logo OpenShift API Data Protection OADP with Ceph CSI Annette Clewett Red Hat OpenShift Commons Briefing まとめ 今回はOADPについて話しました。 Veleroがバックアップ先のオブジェクトストレージとしてMinIOが使われてちゃったりすのですが、OADPはNooBaaを設定することができます。 OCSはNooBaaを含んでいるので、OCSで本番のPVとバックアップ(Snapshotとオブジェクトストレージ)を持つことができます。 とは言えやはりバックアップは本番と違う場所に取りたいという方も多いと思います。これはOADP対応したバックアップソフトウェアが対応しているかがポイントになるので、また情報が入りましたら連絡したいと思います。 というわけで、今回はここまで。