ご利用いただいても良いかと思いますが、導入するサービス数に対して、運用・管理、さらに学習コストの方が高くつくのではないかと想定します。メモリのリソースを消費しますか?」についてですが、こちらも選択する際の重要な要素と考えています。クラスタのノード上で動いています。割り当てた場合を考えます。メモリーのリソースは下記の通りです。超えてスケール・アウト(増やす)事は出来ません。分までを自身のサービスを利用することも出来ません。作れないことになります。オーバヘッドもなく、パフォーマンスも発揮するかと想定します。提供するサービスは、簡単にスケール・アウトしやすいサービスのデプロイには向いていますが、パフォーマンスを上げるためにスケール・アップが必要なサービスには向かないと考えています。違う選択肢を考えた方が良いかと思います。銀の弾丸ではないため、どうぞ適材・適所で稼働に向くサービスを稼働させるようにしてください。いう新しい技術が発表されました。こちらを実際に試して見ましたが、想定通りというか、まさにこれを待っていた!!という技術でした。今後、私の中で注目の技術の一つになりそうです。アプリを動かす方は、こちらの方法をご覧いただき、ぜひ試しください。アプリの課題であった起動時間を大幅に短縮することができる技術です。ある阪田さんがまとめてくださっていますので、ここではその詳細説明を割愛させていただきます。GRAALVM_HOMEそれでは、実際に試して見ましょう。-Dpath="/hello"プロジェクトを作成すると下記のようなファイルが作成されます。上で実行するバイナリを生成する事を明示するオプションです。)用のバイナリが生成されます。ディレクトリ配下に成果物ができあがります。自動的に作成されていますので、こちらをそのまま利用してビルドを行います。バイナリを追加しています。コンテナ・イメージをビルドしてください。作成したコンテナ・イメージを利用してコンテナを起動します。アプリが起動できました。コマンド、もしくはブラウザを利用して起動したアプリケーションにアクセスします。Mode)も用意されており、開発時にホット・デプロイもできるようになっています。ホット・デプロイを行うためには、下記のコマンドを実行します。quarkus:devこちらで起動したのち、ソースコードを修正しコンテンツを再読み込みします。すると、再起動は不要で修正されたコードの内容を確認することができます。仕様に完全準拠しているのではなく、一部の仕様を実装したサブ・セットの実装になっています。おけるサポート、未サポートの機能についての機能一覧が説明されていますので、こちらをどうぞご確認ください。アプリケーションに対して、追加のエクステンションを追加できます。追加可能なエクステンションのリストは下記から参照できます。指定し追加ができます。利用して非常に書きやすくなっており、全体的にとても良くできた技術だと感じています。分でご紹介する内容を発表させていただきました。発表について時間の関係上、セッション中でも詳しくお伝えできなかった所もあるので、ここで真意も含めて共有したいと思います。部分を詳しくご紹介します。急速な勢いでエコシステムを拡大しています。関連のツールや機能ができていると言っても過言ではありません。コンセプトが素晴らしく、多くの可能性が秘められているため、多くの方が賛同しこの状況が生まれていると思います。拡大に危惧している点もあります。出来る事が多くなればなる程、教育コストや運用・管理コストは大きくなっていきます。時と同じような目で見ています。肥大化していき、結果として複雑で扱いづらくなりました。辛いとか言ってらっしゃるのをお見かけします。必須で一番の核となる機能です。中心で考えるのではなく、こうした事を考えるのはとても重要です。収集したりする際には設定が必要ですが、マイクロサービスを開発する多くの場合においては、多くの開発者にとっては必要無いでしょう。した考えを持つ事で、優先的にどの技術から検証をして行けば良いのか優先づけを行う事ができるようになります。エコシステム)って色々な点で良く似ているなと思います。Programming)をコンテナの世界に持ってきたような物です。やってきた事がコンテナに置き換わったんだなと思える部分は多々あると思います。(Springの作者)になり、もしかしたらそこに新しい別のビジネスチャンスがあるのでは?と思う位です。便利な機能を私たちが選んで使うんだ!と言う気持ちや感覚が大切なのです。無理して全部使わなくても良いし別の手段があるならば別を使っても良いと思っています。複雑な構成を組むこともできます。クラスタでマルチテナントとか、開発、テスト、本番環境を構築することも「できます」。利用できる為、各ユーザ毎に細かい認証・認可の設定も「できます」。やります?できるのと、実際やるかどうかは別の話で、少なくとも本番環境と他は分けるべきと私は思っています。動作するのは気持ち悪いです。上で走らせる事で影響を少なくできるでしょう。確かにできるのですが、やればやるほど設定は増えて行くし、設定ミスを誘発しやすくなります。設定をミスした時の影響はより大きくなります。そこで、設定にしても構成にしても難しい構成にしないように留めておくべきと私は考えます。人間は必ずミスをするからです。私ならば、本番環境と開発・テスト環境などを分けて構築します。一生懸命頑張って設定するよりも簡単ですし、確実に守れるからです。このように構成を変える事で簡単にそしてより安全にできるならば、そちらを選んだ方が私は良いのではないかと思っています。するとベンダーロックインがなくなり移行しやすいと言われる事があるのですが、これは正しくもあり間違いもあります。一部の設定に限って言うと同じ設定を他の環境で動かすこともできます。種類やカーネルバージョン、さらにはコンテナ・ランタイム(Docker)のバージョンも各環境で違います。バージョンでも利用できる機能、できない機能を使い分ける事ができます。環境によっては使える機能、使えない機能があると言う事を示しています。書き方や、場合によってはコマンドの引数が変わることまであります。バージョンも時期によってメジャーバージョンやマイナーバージョンで差異が大きくありますので、全く同時期に同じバージョンのクラスタを構築するのは難しいかもしれません。Volumeが違うことを例にあげましたが、それだけではない差がある事を、ここでお分かりいただけるかと思います。事をお勧めされる方のお話にはご注意くださいと、お客様には申し上げています。バージョンの差異における課題について申し上げましたが、上記のような理由からどのバージョンを利用しているのかを強く意識する必要があります。ノード数を増やす事が「できます」。ニーズに応じて大規模クラスタを構築して1つのクラスタ内で全てを完結したいと思われる方もいらっしゃるでしょう。それほど大規模なクラスタを構築するのが果たして本当に必要なのかどうなのか十分に考えてお作りください。メンテナンス性を考えて構築することを強くお勧めします。仮に1度クラスタを作ってしまえば、クラスタのメンテナンスが一切不要と言うことでしたら、大規模クラスタを構築するのもありでしょう。メンテナンスが必要です。パッチを適用する必要もありますしバージョン・アップが必要になる場合もあります。各ノードをローリング・アップグレードで更新し完了するまでどれ程の時間を要するでしょうか。サーバ(管理サーバ)にトラブルが発生した場合どのような事態が発生するかを考えてみていただけないでしょうか。クラスタが壊れてまったく操作できなくなる事もありえます。クラスタを構築するのにどれくらい時間がかかるでしょうか。再構築する間は一切のサービスが受けられなくなる程の大影響を及ぼしてしまいます。側がメンテナンスしやすいように作られていなければ、結局モノリシックに構築しているのと全く変わらなくなってしまいます。1つのクラスタに対するトラブルで全サービスに影響が出てしまいます。クラスタレベルでも適度なサイズ(もちろんマイクロやミニのレベルではなくてよく)、ミドルサイズくらい、もっと言うならば何か不足な事態が発生してもすぐに対応がしやすいようなサイズで構築することをお勧めします。限界にチャレンジしてもあまり良いことはないように思います。バージョン・アップはとても危険を伴います。ベンダーが提供するバージョン・アップ・ツールやコマンドを利用すると簡単にバージョン・アップが「できる」でしょう。その恩恵が得られるのは、コマンドやツールが正常に完了した場合のみです。コマンドやツールが失敗する事もありますし、その場合、最悪クラスタが壊れる事もありえます。設定ファイルが、新しいバージョンの環境で必ず動くと言う保証はどこにもありません。レベルでは本番に影響しないように頑張っても、クラスタ・レベルでも同様の事を考えていなければ意味がありません。比ではないほど甚大です。試しながら安全にバージョン・アップしていくでしょう。利用して外部ストレージをマウントする事ができます。扱いボリュームをマウントさせた際に、今まで様々な問題に遭遇してきました。記事のような問題です。EBS簡単に説明します。ボリュームを1つづつマウントさせる場合を考えます。してくれない場合があります。マウントするボリュームがないため再起動に失敗する場合があります。いつ不意に停止するかは想定できません。それ以外にもボリュームのメンテナンスはそれなりに大変です。(実装に応じて異なる)。までは、使用中のボリューム・サイズを拡張する事は出来ませんでしたので、マウントしているボリュームがいっぱいになると別のボリュームを再作成しマウントし直すなどの必要もありました。関する問題が報告されています。クオリティも向上し、利用する場面におけるベストプラクティスなどが出て安心して使用できるようになる時がくる事が期待されますが、現時点では、私ならば極力本番環境には適用したくないと言うのが本心です。違う方法で回避ができるならばそちらの方法をお勧めしています。実装する方法をお勧めしています。気にする事もありません。積極的に採用しない理由があります。マウントする場合は、ボリュームのメンテも必要になります。まではボリューム・サイズを固定で設定しなければならずボリュームの拡張もできません。結果として管理項目も増えます。アプリケーションのスケールの観点でもスケールがし辛くなります。外部ストレージに書き出した方が、アプリケーションのスケールもしやすいと考えますし、ディスク管理や制限に対する考え方も容易になります。プログラムやサービス側からは、インメモリ・グリッドのような横にスケール・アウトさせる事ができるようなサービスを利用する方が、アプリケーションをスケールさせ易いので、私ならば、こうした違う方法を模索します。—それでも、もちろんボリュームをマウントして使いたいと言うニーズもあると思います。上がっているような問題を認識した上でお使いいただく事で問題が発生した時に迅速に対応ができるようになるかと思います。お気をつけてお使いください。「ボリュームを極力使わないでください」の延長線上で、ボリュームを扱うサービスは極力外に出したいです。中ではなく、極力外で管理をしたいです。方が自分で管理をするよりも簡単に安全にご使用できる場合がありますので、仮想ネットワーク経由で安全な接続を利用した上で外部サービスに接続する方法をお勧めしたいと思います。今、エンタープライズ・システムの構築に必要な機能やサービスを、どんどんと追加しています。上に実装しなくても良いのでは?という考えを持つ事が重要なのではないかと思います。それにより簡単に運用管理ができるような場面もあると思いますし、思い切ってここは使うけど、ここは使わないと言うご検討をいただくのがより有効にご活用いただけるようになるのではないかと思います。品質も向上しさらなる機能追加も行われていくと思います。最新動向をウォッチしながら、できる事と、試す事、実際に本番に適用する事を分けて考えて考えて行かなければならないと思います。ご自身にとって最適な構成をご検討・構築いただければ誠に幸いです。私も完璧な人間ではありませんので、もし、ここは違うよなどがあれば、この記事をもとに議論したりさらなるご検討をいただければ誠に幸いです。分でご紹介する内容を発表させていただきました。トピックについては当日はデモをしながら説明をしたのですが、参加してくださった方のお一人が具体的に私がどのようなデモをしたのかをまとめてくださっていました。(誠にありがとうございます。本番環境に対して適用する際の注意ポイントをまとめた内容です。担当エンジニアでもございません。良さを理解しつつ、正しい所で正しく使っていただきたいと思っているエンジニアです。あっていなければ、違う方法を選択したほうが良いですよと私のお客様には言っています。それによって扱うエンジニアが幸せになり、企業もより良いサービスを素早く提供していただきたいと考えています。余談ですが、実話としてあるお客様から以前こんなご相談を受けました。最初に話を伺った際に、マジかこの営業?お客様を地獄の底に連れて行きたいのか?と思ったくらいでした。確かに素晴らしいので、上手く使いこなせばとても大きな効果を得られます。扱い方を間違えると効果が得られないばかりでなく、余計管理コストは高くつき大変な思いをすることにもなるでしょう。今回のイベント会場の懇親会会場でも別の方から、下記のようなご質問をいただきました。化に期待しており、会社としてやらなければならないのだが、上司から今までと作り方もやり方は変えられない。寺田:「いえ、それコンテナ化してもメリット無いですよ!」このようなやりとりは、今の日本に少なからずあると思うのです。導入したらそれだけで幸せになれると思っているのでしょうか?まず、その場合に私が最初にお伺いするのは下記のような内容です。検討し始めても良いですし、そうでなければ違う道を模索して良いと思います。扱うまでの三部作シリーズの3本目のコンテンツになります。関西】に発表内容がまとめられていますので、こちらをご参考にいただければと思います。扱うその前に、心構えであるとかバックグラウンドを説明したのがこちらです。使うのか?」を考える事がとても重要だと言う事です。扱うにしても、出来る事は数多くあります、その際、この機能は必要?別のほうが簡単じゃない?管理が楽になるんじゃ無い?と思うならば、率先して違う手段も考えるのも良いと思います。扱う土俵に立てるのだと思います。した背景を踏まえて、三部作の3つ目として作成したのが今回のコンテンツでした。項目は、おそらく今まで誰も表立って触れてこなかった内容だと思いますので、あえてこの場を借りて発表しました。時間の関係上、セッション中でも詳しい点をお伝えできなかった所もあるので、ここで真意も含めて共有したいと思いますが、長くなるので別エントリに分けます。数分待ってページを再読み込みしてください。使用に同意したとみなされます。