#infoq

View On WordPress

原文(投稿日：2022/05/18)へのリンク New Relicは最近、Javaエコシステムの状況に関する新しいレポートを公開した。数百万の匿名化されたアプリケーションからパフォーマンスデータが提供されており、こののレポートでは2022年1月に収集したデータが用いられている。 レポートによると、Java 11は本番環境に対する新しい標準である。その採用は2020年の11％から2022年には48％に上昇している。Java 8を超えており、Java 8は46％で僅差で2番目である。Javaの他のLTSバージョンは非常にかけ離れており、それらが使われるケースはごくわずかである。 以下の画像は、Javaリリースの利用状況を示している。 非LTSバージョンを見ると、最も人気があるのはJava 14であり、次にJava15とJava12が続く。しかし、それらの利用は1％未満である。Java 9以降、6か月周期で新しいリリースが利用できるが、これらのリリースは次のイテレーションまでサポートされる。多くのベンダーは、サポートの終了後に非LTSバージョンのサポートを提供していない。おそらくこれが、非LTSバージョンの利用割合が低い理由であろう。 興味深いのは、JavaエコシステムでのさまざまなJDKディストリビューションの採用を示し表である。Oracleは歴史的に最も人気のあるベンダーであったが、その採用は2020年の75％から2022年には34％に減少した。2022年には22％であったAmazon Correttoは、2020年の約3％から目覚ましい成長を遂げた。AdoptOpenJDKは2020年に7％で2番目であったが、2021年にEclipse Adoptium Projectに移行した後、2022年に11％でより高いパーセンテージを獲得したが、3番目に下がった。Azul Systemsは、2020年の3％から8％にその採用が増えた。 以下の画像は、JDKディストリビューションの利用を示している。 Containerは、コンテナから実行されているアプリケーションの70％を占めており非常に人気がある。このレポートでは、コンテナで実行されているアプリケーションの60％が2つ以下のコアを使っていることが示されている。コンテナはマイクロサービスアーキテクチャーに関連付けられることが多いため、これは理にかなっている。しかし、デフォルトのG1ガベージコレクタは2つ以上のコアで最適に機能するため、弊害をもたらす場合がある。 G1ガベージコレクタはJava 11以降のデフォルトであるため、その使用率は11以降のJavaバージョンで68％である。シリアルGCの利用はJava 11以降のバージョンで、ほぼ23％である。一方でZGCやShenandoahなどの他の最近のガベージコレクタは、最近本番環境で使えるようになったばかりなので、その採用率はまだ非常に低い。 以下の画像は、さまざまなガベージコレクタの使用率を示している。 New Relicは、他をリードする可観測性プラットフォームの1つを開発する企業である。開発者にメトリック、イベント、ログ、トレースを提供する。 2022レポートの完全版は、New RelicのWebサイトから入手できる。 2020年に実施・公開された前回のNew Relic調査の詳細は、このInfoQニュース記事に記載されている。

原文(投稿日：2022/05/16)へのリンク 新たなプラットフォームの出現によってクラウドネイティブというステージを失ったJavaは今、ルネッサンスの時を迎えているようだ。Javaエコシステムには数多くのプロジェクトがあって、Javaをよりクラウドフレンドリな存在にすべく、言語レベルのサポートの提供やランタイムの改善に取り組んでおり、イノベーションに向かう急行路線のような様相を呈している。Red Hatエンジニアリング担当副社長のMark Little氏は、Devoxx UKで行った講演の中で、これらの活動をクローズアップした。 Tiobe Indexの順位と、GitHubで使用されているプログラミング言語という観点の2面においてJavaは、長い年月を経た今も表彰台の上に留まるのみならず、エンタープライズソフトウェアではいまだデファクト言語の地位に君臨する。リリースケイデンスの速さが、変更の取り入れを容易にするとともに、開発者の生産性向上を可能にしているのだ。ソフトウェア業界の大手企業(Amazon、Google、IBM、Microsoft、Netflix、Oracle、Pivotal、Red Hatなど)と、大規模なオープンソフトウェア財団(Eclipse FoundationやApache Software Foundation)からの支援を受ける中、JVMエコシステムの変革は3つの主要領域に集中している。 クラウドネイティブに対応するJVM技術 サーバレス領域でのJavaはわずか6.1パーセントを占めるに過ぎない(チャンピオンは62.9パーセントのnode.jsが獲得している)存在だが、Kubernetesネイティブな領域においては、Quarkusなどのアプリケーションに対する400ミリ秒以内のスタートアップ時間や、メモリとディスク上のフットプリントの削減が望まれている。意図に応じて、OpenJDKのホットスポットあるいはGraalVMでの実行を選択する。特に後者は、Javaだけでなく、GraalVMがサポートする他のプログラミング言語においても、偉大なイノベーションの触媒という役割を果たしている。Project Leydenには、Native Java標準の定義に加えて、Native Image Generatorのリファレンス実装やNative Javaのコンフォーマンステストスイートの実現が期待される。 Mark Little: Javaの将来を考える時、Project Leydenがその意義を維持できるタイミングに間に合わないのではないか、という懸念があります。 Kruize Autotune — KubernetesのコンフィギュレーションをJava用に自動調整する。JVMのみでなく、スタック全体が最適化される。 Javaエコシステムのサポート Adoptium — "神に祝福された(blessed)"イメージのリポジトリ — には、これまでに3億を越えるダウンロードアクセスがあった。目標は利用可能なすべてのプラットフォーム用のバイナリをダウンロード可能にすることだが、現時点ではLinux、Windows、macOS、ARM、Intel、AIXなどが対象である。すべてのコミュニティビルドが十分に高い品質基準を達成するために、Adoptium AQAvitの傘下において、クラウド内の100台を超えるビルドマシンとテストマシンによる250,000件の自動テストが実行されている。それらのテストでは、セキュリティ(既知のセキュリティ脆弱性テストをパスすること)、機能的な正確性、パフォーマンスに加えて、拡張性や堅牢性が重視されている。 Holly Cummins: "Node.jsに浮気していた"時期も確かにありましたが、現在はJavaのコード記述に戻っています。これまで数多くの開発をしてきましたし、JSで開発することのメリットの多くはJavaにもあるからです。 より効率的なランタイム すべてがKubernetesで動作する訳ではなく、Java全体を改善するための取り組みが行われている。メモリフットプリントの削減(コンパクトな文字列など)、効率のよいメモリ管理とガベージコレクション(Shenandoah、G1)、アプリケーションのリンクと適切なサイジング(jlink)、IOの最適化(HTTP2、WebSocket)などが具体的な内容だ。 Javaはプログラミング言語界のベテランだが、コミュニティはあらゆる環境に対応できるようにすべく、さまざまな取り組みを行っている。Javaの新バージョンが6か月周期でリリースされるようになった以降の5年間は、Oracleがこの速いペースで言語を変革できることを証明すると同時に、従来は関与のなかったMicrosoftのようなアクタさえも関与するようになった期間でもあった。クラウドネイティブ機能に関する大きな懸念は、Leydenや他の活動が、関連性を維持する期間内に成果を上げることができるのか、という点である。

原文(投稿日：2022/05/06)へのリンク Slackは、パフォーマンスに焦点を当てているエンジニアだけでなく、すべてのエンジニアにとって負荷テストが注力すべき関心事になるよう取り組んできた。そして、パフォーマンスに対するリアクティブなアプローチから、より統合された取り組みに移行していると、SlackのエンジニアShreya Ramesh氏とMelissa Khuat氏は述べている。 負荷テストは、パフォーマンスの低下がリリースに入り込んでいないかを確認するための重要なプラクティスである。残念ながら、負荷テストは、特に複雑なテスト環境をセットアップする必要があるため、非常に時間がかかる。そのため、エンジニアのやる気がそがれる可能性があるとRamesh氏とKhuat氏は述べている。 この問題に取り組むために、Slackは非常に抜本的なスタンスを取った。アドホックな負荷テストに依存せずに、そのテストを開発プロセスの標準機能にした。これにより、負荷テストを継続的に実行することで、パフォーマンスの問題を早期に段階的に特定することができるようになった。 クライアントを常に起動して実行することで、エンジニアがクライアントを起動してカスタム環境をセットアップするために必要な労力を除くことができます。ビルドを本番環境にデプロイすると、アクティブユーザー数が多い大規模な[テスト]組織に対してすぐにテストを実行して、パフォーマンスの低下が発生していないことを確認できます。 負荷テストを継続的に実行することは、技術的な課題があるだけでない。テストにより適切なプラットフォームの動作が損なわれることを避け、効率的な運用を保証し、組織全体がそれを理解するように注意する必要がある。したがって、このアプローチが効果的に機能するためには、Slackチームは、安全性、回復力、コミュニケーションという3つの重要な側面に取り組む必要があった。 安全性を向上させるために、Slackのエンジニアは2つのメカニズムを提供した。APIの成功率が5分間95％を下回ったときにトリガーされる自動シャットダウンサービスと、エンジニアが手動でトリガーできる緊急停止サービスである。 回復力は、テストサービスがその状態をデータベースに保存することで実現される。これにより、たとえば、新しいリリースが展開された場合や、サービス自体がセキュリティパッチを受信する必要がある場合に、自動再起動ができるようになった。回復力のもう1つの重要な側面は、テストに必要なすべてのステップ（例えば、トークンの生成）の自動化である。これは、エンジニアリングの介入を減らすためのものである。 最後に、コミュニケーションは、組織がテストツールへの信頼を維持するためのキーポイントであった。これには、関係者へのサプライズを最小限に抑えるための段階的な立ち上げプロセスが含まれている。同じように、発生する可能性のあるインシデントに対応し、チームが高可用性を維持できるように、慎重なローテーション戦略が必要であった。 Ramesh氏とKhuat氏によると、継続的な負荷テストにより多くのメリットが得られた。例えば、大口顧客が期待するパフォーマンスをよりよく理解すること、問題の再現を試みるために、本番環境のインシデントに迅速に対応できること、本番環境に移行する前にパフォーマンスの低下を検出することである。 継続的な負荷テストをパイプラインに統合するために実行されるSlack戦略には、ここで説明できるものよりもはるかに多くのものがある。そのため、全ての詳細を見たい場合には、元の記事を見逃さないようにしてください。

原文(投稿日：2022/05/04)へのリンク Webサイトまたはソフトウェアをデプロイしているほとんどの企業は、最近の変更がユーザに表示される前にテストできるようにするため、事前のプロダクション環境を使用している。これは、問題やバグを見つけるための防御線を追加するという点で多くの利点をもたらすが、コストと複雑さを増大させ、逆効果をもたらすこともある。ソフトウェアが常にデプロイ可能であることを確認するためにチームを奨励する継続的デリバリー (Continuous Delivery) などの手法により、複雑なブランチ構造やテスト環境から離れ、よりシンプルなセットアップに勢いがある。Squeakyは、プライバシーを侵害することなく訪問者がWebサイトやWebアプリを使用できるかを企業が理解できるよう支援する会社だ。同社は、異なるアプローチを採用し、ステージング環境を使用しない理由を概説している。彼らは、これによってより速く出荷でき、プロダクトで見つかる問題の数を減らすのに役立つと考えている。 彼らのアプローチを説明するブログ投稿で、SqueakyのLewis Monteith氏は、ステージング環境にあるいくつかの問題について詳しく説明している: 事前環境がプロダクションと同等になることは決してありません: スケーラブルなクラウドネイティブアプリは、多くの場合、負荷を処理するためにプロダクションでより多くのリソースを必要としますが、事前にまったく同じセットアップを構築するコストは法外です。これにより、事前環境の構成のドリフトとスケールダウンアーキテクチャが発生し、これらの事前環境でのテストで問題を見つけることができなくなる可能性があります。 常に大きくなったリリースの待ちがあり、オーナーシップが減少します: 複数の開発者またはチームが同時にコードをリリースしたい場合、事前環境がボトルネックになります。事前環境を待たなければならないことは、特にテストが失敗し、全員がそれらの修正を待たなければならない場合、テストの遅延と妥協を引き起こします。リリースの待ちがあるとブランチが分けられ、後で多数の変更をマージしなければならなくなり、開発者に苦痛を与えます。 そして、待ちを減らすために、リリースに、バグが発生する可能性を高めることを意味するこれらがバンドルされることになる。誰のどの変更で問題が発生したかを正確に追跡することが困難になる。問題は分離されていて、開発者はプロダクションに行った変更を認識できない。 責務を置き換えるプロセス: 事前環境は、運用にフォーカスしたチームによって実行される傾向があるため、事前環境へのデプロイには、開発者から運用チームに責任の暗黙の引き継ぎが伴う可能性があります。 Squeakyの代替アプローチは、これらの問題を解決または回避することを目的としている。これを機能させるための4つの重要な信条がある。 稼働する準備ができたコードのみのマージ: このアプローチは、適切なテストがあり、変更が開発で検証されていることを確認することでバックアップされます。 フラットブランチ戦略: すべてのブランチはメインブランチからフォークされ、変更はメインブランチにのみマージされます。スモークテストは、開発者のコンピュータでローカルに行われます。 高リスクな変更のためのフィーチャーフラグ: Squeakyは、全体的に負荷がかかった状態のパフォーマンスや変更にユーザがどのような反応をするかについて懸念がある場合、フィーチャーフラグの背後で大幅な変更を加えることがあります。これらはユーザごとに実行できます。 デプロイメントのハンズオン: 監視、ロギングやアラームは、問題がないことを確認するために包括的に使用されます。また、Squeakyでは、ブルー/グリーンデプロイメントを使用して、すべてが問題ないことを確認するまで、ユーザのサブセットに変更をデプロイします。 Squeakyがステージング環境を廃止し、多くの継続的デリバリーの原則を支持することで、ソフトウェアの出荷に対するマインドセットが変わった。変更を公開する前にあるバッファの削除は、変更のプロダクションへの適合の信頼レベルを上げる必要がある。これにより、コストと複雑さが軽減され、開発ライフサイクルのスピードアップに役立った。  

原文(投稿日：2022/04/28)へのリンク ゲームをビジネスオーナの観点で"面白い"ものにするためには、ビジネスニーズとの整合性を確保することが必要になる。そのようなゲームの立案は、"コンテキストを探る"、"ターゲットグループを知る"、"フォーカスを定義する"、"ファシリテーションの方法を決定する"という4つのステップで行えばよい。 Anne Hoffmann氏はOOP 2022で、アジャイルゲームによるビジネスインパクトの創出について講演した。 ゲームと"遊び"との違いについて、Hoffmann氏は次のように説明する。 "遊び"とは、意図を持たない行為です — ただ単に遊んだり、遊ぶこと自体を意図して行うのが"遊び"です。これに対してゲームは、ゴールのような何かを達成する、ということを意図して行う行為です。ビジネスは設定されたビジネス目標を達成する行為ですから、私たちのビジネス環境に相応しいのはゲームの方です。 ワークショップにおいて、ゲームはアイスブレーカ(icebreaker)や啓発者(enlighter)、あるいは学習シーケンスの一環として機能する可能性がある、とHoffmann氏は述べた上で、ゲームの準備段階において、指針となるトピックと回答すべき質問とを提供する"4ステップのモデル"を紹介した。 コンテキスト — 全体的なコンテキストは何か？スポンサなどとの間で、どのような目標が合意されているのか？ ターゲットグループ — ターゲットグループには誰がいるのか？参加者は何を期待し、何を望み、何を必要としているのか？ フォーカス — ゲームに設定したいフォーカスは何か？エクスペリエンスはどうあるべきか？ ファシリテーション — このゲームのファシリテータとして、前項で定義したエクスペリエンスを創造するために何が必要か？ゲームを公開してその感想を聞くのであれば、どのような質問をしたいか？ この4ステップモデルは、ゲームの効率的な立案作業をサポートすると同時に、ゲームをワークショップ全体とその目標に適したものにする。これこそがビジネスインパクトを創造するということだ、とHoffmann氏は結論付ける。 アジャイルビジネスゲームの立案に関して、Anne Hoffmann氏に聞いた。 InfoQ: アジャイルゲームをどのように定義しますか？ Anne Hoffmann: アジャイルゲームとは、アジャイル指向ビジネスの範疇にあるゲームです。例で説明しましょう。例えば、あなたがコミュニケーションに関するワークショップの責任者であるとします。あなたは、ワークショップのスポンサと協力して、対処すべき事項のリストを書き上げたのですが、スポンサはさらに、ワークショップに革新的な部分や何らかのインタラクションが欲しい、と言っています。アジャイルゲームを導入して、いくつかのトピックを進めることができれば、その解決策になりそうです。そのためには、ワークショップのコンテキストの中にゲームを取り込む上で、ベストな方法を見付けなくてはなりません。 InfoQ: 4ステップモデルをゲームの立案にどうやって使うのか、例を挙げて頂けますか？ Hoffmann: そうですね。コミュニケーションを改善したいグループを対象とした"Yes andゲーム"をセットアップする、という例にしましょう。立案段階において4ステップモデルを使用すれば、次のようになります。 1 コンテキスト — コミュニケーションに関するトレーニングワークショップ。個人のコミュニケーションとその改善がそのトピックになる。 2 トレーニンググループ — 自己の成長に対して強いニーズを持つ、若手プロジェクトマネージャのグループ。 3 フォーカス — (所与のコンテキストにおける)個人のコミュニケーションと自己の成長のための領域発見に焦点を置く。 4. ファシリテーション — "自己と他者のコミュニケーションスタイルについて何を観察したか"、"自身のコミュニケーションスタイルについて何を学んだか"、"個人的なハイライトは何か"というように、自己の成長を省察するための質問集を用意する。これらが出発点として機能する。 InfoQ: ゲームはどうやってやるのでしょうか？ Hoffmann: "Yes and"はとても簡単な即興劇のゲームです。 プレイ方法を説明しましょう。3～5人のグループで、まずグループとしてのストーリを作ります。各人が文をひとつずつ語るのです。これを2ラウンド行います。 第1ラウンドでは、すべての文を"Yes, but"で始めます。 第2ラウンドでは、すべての文を"Yes, and"で始めます。 この方法で、いくつかのストーリを作ります。各セッションの終わりに感想を求めて、その結果について話し合ってください。 両方のラウンドをプレイした後には、何が違ったのかを比較したくなるでしょう。そうなればもう一度、感想と結果の議論を行うのです。

原文(投稿日：2022/03/03)へのリンク 企業がクラウドに移行したとき、最初から利害関係者を参加させたり、セキュリティを関与させたりすることが困難であったため、セキュリティの問題が発生した。継続的なクラウドDevOpsプロセスの一部としてセキュリティ評価を組み込み、プロジェクトのライフサイクル全体を通じてセキュリティリスク管理にアジャイル戦略を採用することで、移行中のセキュリティのガバナンスを強化することができた。 Archana Puri氏は、The Diana Initiative 2021でクラウドに移行する際のセキュリティのジレンマについて話した。 Puri氏は、Gartnerの6Rアプローチからの移行アプローチを評価した後、組織のクラウド移行ロードマップの一部として3つの移行アプローチを採用したと述べた。 焦点は、「リフトアンドシフト」移行アプローチを使って、重要な顧客サービスをサポートするレガシーシステムを最初に移行することでした。レガシーアプリケーションをサポートするために、他の依存するアプリケーションは、クラウドネイティブ機能（オンプレミスのオラクルデータベース向けのRDSなど）を使って「再プラットフォーム化」される計画でした。また、移行対象のアプリケーションを時間の経過とともに置き換え、クラウドの処理とワークフローをロードマップの一部として自動化することで「リファクタリング」される予定でした。 クラウド移行の主な課題は、適切な利害関係者と関わり、移行プロセスのガバナンスを確立することであったとPuri氏は述べている。クラウド移行は技術的な問題と見なされていたため、移行の影響を受ける顧客サービスやアプリケーションチームなどの他の利害関係者を関与させることなく、プロジェクトはITチームに委任されたと彼女は述べている。 Puri氏によると、セキュリティチームは、プロジェクトの終了時に、ポイントインタイムのセキュリティレビューを実行し、プロジェクトチームに保証を提供するために頻繁に関与していた。最後にセキュリティを適用することがプロジェクトの致命的問題になっていた。それは、セキュリティ評価のアプローチと結果がビジネス目標と一致せず、その結果、クラウド移行による効果的なアウトプットを達成する上でビジネス、プロジェクト、セキュリティチーム間の分断に至ったためである。 プロジェクトから得られた最も重要な学習は、組織全体の関連する利害関係者を関与させることであった。プロジェクトとソリューションのライフサイクル全体でセキュリティを確保するには、継続的なリスクベースのセキュリティ回復力のあるインフラストラクチャを構築するために、DevOpsと他の関連チームの間で適切なセキュリティトレーニングと認識が必要である。 InfoQは、クラウド移行におけるセキュリティの処理についてArchana Puri氏にインタビューした。 InfoQ: クラウドに移行した理由は何でしたか？会社はどのような期待をしましたか？ Archana Puri: クラウド移行の主な理由は次のとおりです。 技術改善イニシアチブの一環としてアプリケーションプラットフォームを最新化する 組織における増大する顧客の需要とサービスポートフォリオに対応するためにパフォーマンスを拡張および強化するために、レガシーインフラストラクチャをアップグレードする コストを最適化し、IT予算を効果的に活用して、より機敏で自動化された機能を採用する InfoQ: クラウドに移行する際の主なセキュリティ上の課題は何でしたか？ Puri: セキュリティエンゲージメント内では、リスクを評価するための特定の時点でのアクティビティとして、セキュリティリスク評価を実行する従来の方法に依存していました。ただし、クラウドの移行は継続的なプロセスであるため、セキュリティはアジャイルな作業方法に適応し、クラウドDevOpsプロセスの一部としてセキュリティ評価を組み込む必要がありました。 クラウドテクノロジー、脅威プロファイル、リスクエクスポージャー、制御に関するITとセキュリティのリソース内の十分な理解と技術的能力の欠如も、致命的問題になりました。 InfoQ: これらの課題にどのように対処しましたか？ Puri: セキュリティ・バイ・デザインとアジャイルプロジェクト手法の一部としてのセキュリティの組み込みは、プロジェクトのライフサイクル全体にわたるセキュリティリスク管理の戦略として、また継続的な開発と運用のメカニズムとして採用されました。これには、移行の概念化の段階からセキュリティチームを関与させ、認識を合わせることが含まれます。これにより、明確なコミュニケーションと目的と意図に関する理解ができるようになり、それによって、企業は移行の決定を下すことができました。 重要なのは、移行を推進する理由と目的を明確に理解し、クラウドのセキュリティ戦略とポリシーを、組織全体のセキュリティ戦略とポリシーと整合させることです。