検索結果

DevOps Tools Introduction #16：まとめ おめでとうございます。ついに「DevOps Tools Introduction」シリーズの最終回までたどり着きました。この数か月にわたり、毎週新しいテーマを一つずつ取り上げてきました。 ここまで紹介してきたリソースに取り組むには、多くの時間と労力が必要だったと思います。その努力の結果として、今ではますます重要性が高まっている技術スタックについて、しっかりとした基礎知識を身につけることができました。 このシリーズでは、モダンなアプリケーション設計、バージョン管理、継続的インテグレーションと継続的デリバリー（CI/CD）、コンテナ仮想化、オーケストレーション、インフラストラクチャ、構成管理の自動化、監視、ログ管理まで、幅広いテーマを取り上げてきました。 これらの新しいツールは、サービスの作り方や提供方法そのものを大きく変えています。今週は（ほとんど）新しい参考資料の紹介はありませんが、その代わりに、これらのツールをどのように活用すれば、日々の仕事をより効率的に、そしてより面白くできるか、少し立ち止まって考えてみてください。 本日ぜひ共有したいリンクがひとつあります。それが Periodic Table of DevOps Tools（DevOpsツールの周期表） です。このページを見ると、DevOpsツールのエコシステムがどれほど多様になっているかがよくわかります。ツールはカテゴリごとに整理されており、このシリーズを通して、その多くのカテゴリの中から少なくとも1つずつツールに触れてきたことが確認できるはずです。 このブログシリーズで紹介してきたツールは、LPI DevOps Tools Engineer試験で扱われるものです。これらはコミュニティでの議論や公開ディスカッションを重ねて選定されたものであり、DevOpsを学び始めるうえで、実践的かつ信頼できる選択肢だと言えます。 これらのツールに関する知識を身につけた今、LPI DevOps Tools Engineer認定資格 の取得を検討してみるのもよいでしょう。この認定資格は、DevOpsツールに関するスキルと知識を証明するものです。 ここまでブログシリーズを読み進めてきた今、改めて試験の出題範囲（Exam Objectives）を確認してみてください。そこには試験で求められる知識の範囲が明確に示されています。印刷して、すでによく理解しているタスクやツールにチェックを入れながら確認していくのもおすすめです。そして、まだ自信のないテーマについては、関連するブログ記事やLearning Materialsをあらためて見直してみてください。 最後の仕上げとして、もう一度コマンドラインに戻り、試験範囲に含まれるタスクを実際にやり直してみましょう。もしうまく動かないものがあれば、そのテーマをもう一度復習するための時間を確保してください。 また、試験に向けて覚えておきたい内容があればメモを取っておくのも効果的です。試験では、原則や概念に関する問題だけでなく、コマンド、ファイル、設定項目に関する問題も出題されることを忘れないでください。 試験日が近づいてきたら、自分のノートを定期的に見返しながら内容を整理し、少しずつ要点を絞り込んでいきましょう。そして準備が整ったら、LPI公式サイトやLPI Marketplaceにアクセスして、試験の予約方法を確認してください。 もしあなたがLinux Professional Institute DevOps Tools Engineerを目指しているなら、ノートを見直し、試験範囲を確認し、試験対象のツールを実際に触りながら学ぶための時間と余裕が持てることを願っています。そしてもちろん、試験での成功を心から祈っています。 最後に、このシリーズを締めくくるにあたり、この連載の中で紹介してきた素晴らしいリソースの制作者の皆さまに感謝を伝えたいと思います。知識や経験を共有してくださったことに深く感謝します。 そして何より、このシリーズを読んでくださったすべての皆さまにも、時間を割いてご覧いただいたことに心から感謝します。私自身がこのシリーズを書くことを楽しんだのと同じように、皆さまにも楽しんでいただけていたら嬉しく思います。 このシリーズはここで終了となりますが、ぜひ今後もLPIブログにご注目ください。これからも魅力的なコンテンツをたくさんお届けしていきます。 << このシリーズの前回の記事を読む | シリーズの最初の記事から読む >>

DevOps Tools Introduction #15：分散トレーシングとOpenTelemetry入門 この数か月にわたり、「DevOps Tools Introduction」シリーズでは、毎週さまざまなテーマを取り上げてきました。今回が最終回となり、DevOpsエンジニアが知っておくべき、もうひとつの重要なトピックをご紹介します。 現代の分散システムは非常に複雑であり、従来の監視手法だけでは十分とは言えません。アプリケーションがマイクロサービスとして分割されると、ひとつのリクエストが複数のサービス、ネットワーク、インフラレイヤーをまたいで処理されることがあります。 このような環境において、分散トレーシング（Distributed Tracing） は、システムの動作を理解し、問題を診断し、パフォーマンスを改善するために欠かせない技術となっています。 本記事では、トレーシングの基本概念を紹介し、OpenTelemetry の基礎を解説します。また、よく利用されるオープンソースのテレメトリー分析ツールの概要と、アプリケーション計測（Instrumentation）の重要な考え方についてもご紹介します。 トレーシングとは？ トレーシングとは、リクエストが分散システム内の複数のコンポーネントを通過していく一連の流れを追跡する仕組みです。 ログが個々のイベントを記録し、メトリクスが集計された数値データを示すのに対し、トレーシングは処理がどのような因果関係で実行されたのかをサービス横断で可視化します。 OpenTelemetryを理解する前に、トレーシングに関する基本用語を押さえておきましょう。 分散トレース（Distributed Trace） とは、ひとつのリクエストがシステム全体を通過する完全な流れを表します。 そのトレースは複数の スパン（Span） で構成されます。スパンは、サービスやコンポーネントが実行するひとつの処理単位を表します。 スパンは階層構造で管理され、ツリーのような形で各処理の関係性を示します。 それぞれのトレースには固有の Trace ID があり、各スパンには個別の Span ID が割り当てられます。 これらの識別子によって、異なるサービス間のイベント同士を関連づけることができます。 通常、スパンには以下の情報が含まれます。 開始時刻と終了時刻などのタイミング情報 処理に関するメタデータ 親スパン・子スパンとの関係性 この構造によって、エンジニアは遅延を可視化し、ボトルネックを特定し、サービス間の依存関係を理解できるようになります。 分散トレースの主要要素 トレーシングシステムを効果的に活用するには、スパンやトレースを構成する主要な要素を理解することが重要です。 Span Attributes（スパン属性） スパン属性はキーと値のペアで構成される情報で、HTTPメソッド、データベースクエリ、ユーザーIDなど、処理に関するコンテキストを表します。 これにより、トレースに詳細な情報が加わり、分析しやすくなります。 Events（イベント） イベントは、スパンの中に記録される時刻付きの注釈です。 リトライ処理やエラー発生など、実行中の重要な出来事を記録するために利用されます。 Links（リンク） リンクは、直接の親子関係ではないものの、因果関係を持つスパン同士を関連づける仕組みです。 非同期処理やバッチ処理などで特に有効です。 Status（ステータス） スパンの実行結果を示します。 成功・失敗といった状態や、エラー内容の説明が含まれることがあります。 Kind（種類） スパンがシステム内でどの役割を担っているかを示します。 たとえば以下のような種類があります。 Client Server Producer Consumer これによって、その処理が全体の中でどの位置づけにあるのかがわかりやすくなります。 コンテキスト伝播（Context Propagation） 分散トレーシングで最も重要な概念のひとつが コンテキスト伝播 です。 リクエストが複数のサービス間を移動する際、トレーシングのコンテキスト情報も引き継がれなければなりません。 このコンテキストには、以下のような情報が含まれます。 Trace ID Span ID その他のメタデータ これが正しく伝播されないと、トレースが途中で分断され、リクエスト全体の流れを再構築できなくなります。 実際には、HTTPヘッダーやメッセージングシステムを通じてコンテキストが伝達されることが一般的です。 これにより、各サービスは自分のスパンを正しいトレースに紐づけることができます。 OpenTelemetry OpenTelemetry は、トレース、メトリクス、ログを統一的に収集するためのオープンソースObservabilityフレームワークです。 Cloud Native Computing Foundation によって管理されており、現代のシステムにおけるテレメトリー計測の事実上の標準となっています。 OpenTelemetryでは以下を定義しています。 テレメトリーデータ生成のためのAPI データ処理・エクスポートのためのSDK 命名や構造を統一するセマンティック規約 OpenTelemetryを採用することで、特定ベンダーへの依存を避けながら、さまざまなObservabilityツールとの相互運用が可能になります。 アプリケーションは特定のバックエンドに直接接続するのではなく、OpenTelemetryを通じて収集したデータを、トレース基盤、メトリクス基盤、ログ集約システムなど複数の環境へ出力できます。 アプリケーション計測（Instrumentation） Instrumentationとは、テレメトリーデータを生成するためにアプリケーションへ計測処理を組み込むことです。 主に次の2つの方法があります。 手動Instrumentation 開発者がコード内で明示的にスパンを生成し、属性を追加します。 細かな制御が可能ですが、実装の手間がかかります。 自動Instrumentation ライブラリやエージェントを利用し、HTTPサーバー、データベースクライアント、メッセージングシステムなどに対して自動でスパンを生成します。 開発工数を減らし、導入を加速できるのがメリットです。 効果的なInstrumentationでは、不要なノイズを増やしすぎず、必要な可視性を確保することが重要です。 オープンソースのテレメトリー分析ツール テレメトリーデータは収集しただけでは意味がありません。 保存・検索・可視化できる仕組みが必要です。 この用途で広く使われているオープンソースツールには以下があります。 Jaeger もともとUberによって開発された分散トレーシングシステムです。 以下のような強力な機能があります。 トレースの可視化 サービス依存関係分析 パフォーマンス監視 Grafana Tempo Grafana Labs のエコシステムと統合しやすい、高スケーラブルなトレーシングバックエンドです。 メタデータのみをインデックス化し、トレース本体はオブジェクトストレージに保存することで、コスト効率の高い運用を実現します。 これらのツールを使うことで、エンジニアはトレースを探索し、レイテンシ問題を見つけ、複雑なシステム内でリクエストがどのように流れているかを把握できます。 なぜトレーシングが重要なのか トレーシングは、ログやメトリクスだけでは得られない分散システム内部の可視性を提供します。 チームは以下を実現できます。 [...]

カナダ・オンタリオ州、2026年4月30日 — Linux Professional Institute（LPI） は、Security Essentials認定向けの無料Learning Materials（学習教材）のベトナム語版を公開したことを発表しました。 Security Essentials認定は、ITセキュリティの主要分野を理解するために必要な基礎知識を学べる資格です。ITセキュリティの入門コースを修了した学生をはじめ、サイバーセキュリティのスキル向上を目指す社会人や、安全な情報技術の活用に関する確かな基礎を身につけたい方に向けて設計されています。 LPI シニアプロダクトマネージャーのMarkus Wirtz 博士は、次のように述べています。 「今回の公開により、LPIのLearning Materialsはすべてベトナム語で利用できるようになりました。翻訳者であるMinh Trang Nguyễn 氏と Thoa Huỳnh 氏の、丁寧で一貫した素晴らしいご協力に心より感謝します。」 また、LPI日本支部コミュニケーションディレクターの伊藤健二 氏は次のようにコメントしています。 「この新しい翻訳が、ベトナムの受験者の皆さんにとってITセキュリティの世界へ踏み出す第一歩となり、さらに高い目標へ挑戦するきっかけになることを願っています。」 Learning Materialsは、講師や学習者のために提供されている無料の学習リソースで、試験対策を支援することを目的に開発されています。説明・演習・解答が明確に分かれた授業向けの構成となっており、内容は常に最新の状態に保たれるよう定期的に更新されています。 Security Essentials Learning Materialsは現在、7言語で全訳または一部翻訳が提供されています。複数の言語で提供することで、LPIは言語の壁を減らし、より多くの人がサイバーセキュリティ教育にアクセスしやすい環境づくりを目指しています。これにより、学習者は母国語で実践的かつ仕事に直結するスキルを身につけることができ、キャリア形成や、日常のデジタル環境におけるセキュリティ意識の向上にもつながります。 Security Essentials Learning Materials ベトナム語版は、こちらから利用できます。 Security Essentials Learning Materials（ベトナム語版） Linux Professional Institute（LPI）について Linux Professional Institute（LPI） は、オープンソースのプロフェッショナルのためのグローバルな認定機関であり、キャリア支援を行う国際的な組織です。35万人を超える認定取得者を擁し、ベンダーニュートラルなLinuxおよびオープンソース認定機関として、世界で最初かつ最大規模を誇ります。 LPIは180か国以上で認定試験を提供しており、多言語での受験に対応しています。また、世界各地に数多くのトレーニングパートナーを有しています。 Linux Professional Instituteについて詳しくは、公式サイトをご覧ください。 メディアお問い合わせ先 Shamiul HossainCommunicationsLinux Professional Institute (LPI)shossain@lpi.org

カナダ・オンタリオ州、2026年4月28日 — Linux Professional Institute（LPI） は、Linux Essentials認定向けの無料Learning Materials（学習教材）のトルコ語版を公開しました。これにより、Linux Essentials Learning Materialsは合計14言語で利用できるようになりました。 トルコ語翻訳チームのMurat Boyar 氏は、次のように述べています。 「この翻訳プロジェクトは、トルコのLinuxコミュニティにおける私たちのミッションの中核を担う取り組みです。質の高いローカライズされた教育コンテンツを提供することで、地域のエコシステムをさらに活性化させることを目指しています。LPIのLearning Materials翻訳を支援することは、トルコのすべての学生やITプロフェッショナルが世界標準のLinux知識へアクセスできる環境を実現するという、私たちのより大きな取り組みにおける重要な節目となりました。」 また、翻訳者のGökhan Gurbetoğlu 氏は次のようにコメントしています。 「LPI Linux EssentialsのLearning Materialsが母国語で利用できることは、大きなチャンスです。そのため私は、トルコ語として自然で、かつ正確な表現になるよう意識して翻訳に取り組みました。より多くの人がオープンソースコミュニティに参加するきっかけづくりに貢献できることを、とてもうれしく思っています。」 Linux Essentials認定は、新しい仕事への応募や昇進の際に、Linuxの基礎スキルを証明する資格として広く知られています。また、Linux管理者向けの上位資格であるLPIC Professional Certificationへ進むための最初のステップとしても最適です。 LPIのLearning Materialsは、講師や学習者のために提供されている無料の学習リソースで、試験対策を目的として作成されています。説明・演習・解答が明確に分かれた授業向けの構成になっており、常に最新の内容に保てるよう定期的に更新されています。教材の内容は、それぞれの試験の最新バージョンの出題範囲（Objectives）に基づいて構成されており、各Objectiveは内容や配点に応じて1つ以上のレッスンに分けられています。 Linux Essentials Learning Materials トルコ語版は、こちらから利用できます。 Linux Essentials Learning Materials（トルコ語版） Linux Professional Institute（LPI）について Linux Professional Institute（LPI） は、オープンソースのプロフェッショナルのためのグローバルな認定機関であり、キャリア支援を行う国際的な組織です。35万人を超える認定取得者を擁し、ベンダーニュートラルなLinuxおよびオープンソース認定機関として、世界で最初かつ最大規模を誇ります。 LPIは180か国以上で認定試験を提供しており、多言語での受験に対応しています。また、世界中に数多くのトレーニングパートナーを有しています。 Linux Professional Instituteについて詳しくは、公式サイトをご覧ください。

シングルボードコンピュータでのAndroid仮想化：Redroid on RK3588 シングルボードコンピュータ（SBC）上でAndroidを仮想化するのは、一見すると非常に複雑な作業に思えるかもしれません。重たいエミュレーターや高価な商用ソリューションに頼らず、組み込みハードウェア上でAndroidアプリケーションを動かすことは、多くの場合大きな課題となります。 そこで登場するのが、RK3588向けのRedroidです。Redroidは、そのような悩みを解決するために設計されたソリューションです。 エッジ環境向けにAndroidアプリケーションのプロトタイプを開発している開発者にも、軽量で再現性の高い構成を求めるシステムインテグレーターにも、RedroidはAndroidの扱い方を大きく変えてくれます。 このオープンソースソリューションは、単にAndroidを仮想化するだけではありません。効率的で柔軟性が高く、そして驚くほど導入しやすい方法でAndroidを動かせるようにしてくれます。 コンテナベースのAndroid：新しいアプローチ Redroidが優れている点は、組み込みハードウェア上でAndroid仮想化を行う際によくある課題を解決していることです。 従来のようなリソース消費の大きいエミュレーターや複雑なセットアップは必要ありません。Redroidは、よりスマートな方法でAndroidを実行します。 コンテナによる高効率な実行 従来のエミュレーションとは異なり、RedroidはAndroidをコンテナ内で実行します。CPUとRAMを静的に割り当てながら、GPUは効率よく共有されます。 このアーキテクチャにより、一般的なエミュレーターのようなオーバーヘッドを避けつつ、SBC上で高いパフォーマンスを実現できます。 複数インスタンスの実行に対応 複数のAndroid構成を同時にテストしたい場合にも、Redroidは便利です。 1台のボード上で複数のAndroidコンテナを並行して実行でき、それぞれ独立した環境として動作します。 最小限のセットアップ 現在、メンテナーによってArmbianネイティブサポートと事前コンパイル済みカーネルが提供されているため、独自にカーネルをビルドする必要はありません。 必要なのは少しの設定変更とDocker Composeコマンドだけです。数時間ではなく、わずか数分で動作するAndroid環境を構築できます。 Redroidを開発環境に加える理由 Redroidの大きな魅力のひとつは、実用性とパフォーマンスの高さです。 従来のAndroidエミュレーターは大量のシステムリソースを消費します。一方でRedroidはコンテナベースのため、RK3588搭載ボードのような比較的コンパクトなハードウェア上でも効率よくAndroidを実行できます。 さらに、Redroidは scrcpy などのツールと連携でき、Android画面をデスクトップにミラーリングできます。 そのため、デバッグやデモ用途にも非常に便利です。 この組み合わせにより、従来のAndroid開発環境に匹敵するだけでなく、それ以上に柔軟で、リソース効率に優れ、カスタマイズしやすい開発・検証環境が実現します。 オープンソースを核としたプロジェクト Redroidはオープンソースプロジェクトとして、革新性とアクセシビリティを体現しています。 RockchipのRK3588やRK3588Sプラットフォームとの相性が良く、RK3588ベースの NanoPC T6 LTS 上でも高い性能が確認されています。 ベンチマーク結果 Rockchip RK3588プロセッサと16GB RAMを搭載したNanoPC T6 LTSでのベンチマークでは、非常に優れた性能が確認されました。 GPU性能 Vulkanスコアは3508。 RK3588に搭載されているMali-G610 GPUを効果的に活用しており、ハードウェアアクセラレーションを必要とするAndroidアプリでも十分な性能を発揮します。 コンテナ上で動作するAndroidでありながら、このスコアは非常に印象的です。 CPU性能 シングルコアスコアは790と控えめですが、マルチコアスコアは2770を記録しました。 これは、RK3588の8コア構成（1.80GHzの効率コア4基 + 2.40GHzの高性能コア4基）による並列処理性能の高さを示しています。 メモリ効率 16GBメモリ環境では、優れたリソース管理が実現されており、複数のAndroidインスタンスを同時実行してもパフォーマンス低下がほとんど見られませんでした。 実践：ターミナルからAndroidへ 最近の実験では、NanoPC T6 LTS上でRedroidを検証しました。 セットアップは非常にシンプルで、Dockerコンテナを取得してから数分で、完全に動作するAndroid 13環境をArmbianホスト上で起動できました。 使用した環境は以下の通りです。 Armbian（vendor kernel v6.1.84ベース） Debian 12 特に印象的だったのは、安定性と互換性の高さです。 アプリケーションは問題なく起動し、Google Play Storeも正常に動作しました。また、GPUパススルーが適切に機能しているため、グラフィック負荷の高いアプリもスムーズに動作しました。 LinuxターミナルとAndroidインターフェースを同時に扱える点は、開発ワークフローやハイブリッドコンピューティングの可能性を大きく広げてくれます。 数ステップでできるDocker設定 Redroidのセットアップは非常に簡単です。 必要なのは docker-compose.yml ファイルだけです。 以下は、1080×1920の画面解像度や入力サポートなどを含む設定例です。 この構成では、コンテナにCPU 8コアと約8GBのRAMを静的に割り当て、GPUは自動共有されます。 services: redroid: image: cnflysky/redroid-rk3588:lineage-20 container_name: redroid restart: unless-stopped [...]

データベース管理の仕事が私をPostgreSQLへ導き、PostgreSQLがオープンソース普及活動へ、そしてこの1年で、そのオープンソース活動が私をLinux Professional Institute（LPI）の理事会へと導きました。この記事では、その歩みを振り返るとともに、LPI理事として活動する意義について紹介します。 私のキャリアは、データベース管理者（DBA）およびデータベース開発者として始まり、その後、データベース部門副ディレクターやデータ分析部門ディレクターなどを歴任してきました。現在は、グローバルなトレーディング企業であるDRW Holdingsで、PostgreSQLを専門とするデータベースアーキテクトを務めています。言ってみれば、通常の200％の労力を必要とする仕事をこなしながら、さらに別の200％をPostgreSQLとオープンソースへの貢献と普及活動に注いでいるようなものです。 私はPostgreSQLの開発にも貢献しており、『PostgreSQL Query Optimization: The Ultimate Guide to Building Efficient Queries』という書籍の共同執筆も行いました。また、私が共同設立・運営しているPrairie Postgresの支援を受けたIllinois Prairie PostgreSQL User Groupで、毎月ミートアップを主催しています。さらに、カンファレンスの運営にも携わっており、特にシカゴで開催予定の「PG Data Conference 2026」がその代表例です。 PG Data Conference 2026 LPIは、私の職業上およびボランティアとしての活動を評価し、理事会への参加を打診してくれました。私は、世界規模で展開する認定団体がどのように運営されているかを学ぶことは、PostgreSQLコミュニティにとっても大きな価値があると考えました。というのも、PostgreSQLコミュニティ自身も、認定制度の提供に向けた取り組みを進めているからです。 長年にわたり、PostgreSQLの開発者たちは、AI向けベクトルデータ型を含む最新のデータベース技術動向に歩調を合わせてきました。その成功により、PostgreSQLは外部からも注目される存在となり、「模範とすべきデータベース」と見なされるようになっています。 その結果、PostgreSQL開発者たちは、他のデータベース製品（多くはクラウドサービスとして提供されているもの）について、「PostgreSQL互換」と認めてほしいという依頼を日常的に受けるようになりました。コミュニティは、ブランド価値の希薄化を防ぎ、ユーザーや開発者の体験を向上させるためにも、「PostgreSQL互換」とは何を意味するのかを標準化する必要があると認識しています。 そのため、PostgreSQLプロジェクトでは、「PostgreSQLとは何か」を厳密に定義し、オープンソースのテストを活用したコミュニティ認定の互換性プログラムを構築する必要があります。LPIは、テストや認定制度について学ぶ場として非常に適した存在です。 私がLPIに関わるもう一つの理由は、人材育成への強い思いです。私は長年にわたり、特にPostgreSQLを中心として、フリー／オープンソースソフトウェアを広めるために教育機関へ働きかけてきました。 コンピュータサイエンスの教育課程では、データベースそのものが軽視されるか、あるいはソフトウェアベンダーが教育向け割引価格で提供する proprietary（独自仕様）のデータベースが教えられることが少なくありません。これに対して、私は『PostgreSQL Query Optimization』の序文で次のように書きました。 「PostgreSQLは学術環境で誕生し、現在もオープンソースプロジェクトとして維持されている。そのため、リレーショナル理論の教育やデータベース内部構造の学習に理想的なデータベースである。」 だからこそ、私はフリーソフトウェアに対する古くからの偏見を乗り越え、PostgreSQLを学校や大学における標準的なデータベースにしたいと考えています。今年のSCALEカンファレンスでは、「PostgreSQL and Academia: Establishing Partnership」というテーマで講演も行いました。LPIがトレーニング機関や大学と幅広いパートナーシップを築いていることは、この目標を推進するうえで非常に有益です。 最後に、私はLPI理事会での活動を、自分が選んだソフトウェアプロジェクトの普及活動をさらに発展させるものだと考えています。LPIは、世界中のパートナーやネットワークを通じて、フリー／オープンソースソフトウェアの利用と普及を広げるためのグローバルな場を、理事会メンバーに提供してくれています。 LPIメンバーで、理事会への応募を希望される方は、こちらをご覧ください。

アプリケーション、コンテナ、仮想マシンは稼働中、さまざまなイベントに関する情報を継続的に生成しています。これらのイベントには、重大なエラーから、サーバーがリクエストに正常に応答したという単純な通知まで、あらゆるものが含まれます。マルチティア構成や動的なマイクロサービス環境では、このログデータを収集・分析することが大きな課題となります。DevOps Tools Engineer試験では、704.3の試験目標としてログ管理と分析が扱われています。 ログは、現代のコンピューティングシステムにおける基盤的な機能であり、システムの動作監視、障害や攻撃の診断、アクティビティ監査、コンプライアンス確保を実現する主要な仕組みです。ログとは本質的に、アプリケーション、オペレーティングシステム、インフラコンポーネントによって生成されるイベントを構造化して記録したものです。これらの記録は一般的に「ログ」と呼ばれ、「何が起きたのか」「いつ起きたのか」、そして多くの場合「なぜ起きたのか」といったコンテキスト情報を含みます。 アプリケーションログは、ソフトウェアシステム内部のロジックで生成されるイベントに焦点を当てています。これには、ユーザー操作、エラー、状態遷移、API呼び出し、パフォーマンスメトリクスなどが含まれます。ログは通常、log4j、logback、あるいは言語標準のフレームワークなど、アプリケーションコードに統合されたロギングライブラリを通じて出力されます。各ログエントリには一般的に、タイムスタンプ、重大度レベル（INFO、WARN、ERRORなど）、メッセージ、コンテキストメタデータといったフィールドが含まれます。 一方、システムログは、オペレーティングシステムやそのコンポーネントによって生成されるイベントを記録します。これには、カーネルメッセージ、サービスのライフサイクルイベント、認証試行、ハードウェア関連の通知などが含まれます。システムログは、ホスト環境の状態や挙動を把握するために不可欠であり、通常はシステムレベルのログサービスによって管理されます。 ログワークフローとライフサイクル ログエントリのライフサイクルは、大きく4つの段階に分けられるパイプラインに沿って進行します。具体的には、「生成」「収集」「処理」「可視化」です。 生成フェーズでは、アプリケーションやシステムコンポーネントがログを出力します。これらのログは、ファイル、標準出力（stdout）、またはシステムログソケットに書き込まれる場合があります。 収集フェーズでは、FilebeatやFluent Bitなどのログエージェントやフォワーダーがログソースを監視し、データを集中管理システムへ転送します。これらのエージェントは軽量であり、分散環境でも効率的に動作するよう設計されています。 処理フェーズでは、ログデータの解析、フィルタリング、変換、エンリッチメント（付加情報の追加）が行われます。LogstashやFluentdなどのツールはパイプラインを適用し、ログフォーマットを正規化し、フィールドを抽出し、インデックス化に適した形へ整形します。 最後に、ログはElasticsearchやOpenSearchのようなシステムに保存・インデックス化され、高速な検索や分析が可能になります。KibanaやGrafanaといった可視化ツールは、ログデータを検索・探索するためのインターフェースを提供します。 このパイプラインにより、組織は未加工で非構造化なログエントリから、実用的なインサイトを得ることが可能になります。 LPI試験では、Logstash、Elasticsearch、Kibanaを組み合わせたElastic Stackがリファレンス実装として使用されています。これらのツールの中でも、特にLogstashは多くの設定を必要とし、この試験目標の中心的な存在となっています。 Elasticsearchは分散型の検索・分析エンジンであり、ログをインデックス化されたドキュメントとして保存し、全文検索や集約クエリを可能にします。ElasticsearchのフォークであるOpenSearchも、オープンなガバナンスモデルのもとで同様の機能を提供しています。 Logstashはデータ処理パイプラインであり、複数のソースからログを取り込み、フィルタを適用し、イベント情報をストレージへ出力します。解析や変換を行うための幅広いプラグインをサポートしています。 幸いにも、Logstashのドキュメントは非常に充実しています。まずは「Logstash Introduction」と「Getting Started with Logstash」から学習を始めるとよいでしょう。「How Logstash Works」では、Logstashパイプラインの主要要素がまとめられています。 これらの知識を身につけたら、最初のElastic Stack環境を構築してみましょう。stack-dockerでは、Elastic Stackの各コンポーネントをはじめ、多数のサービスをセットアップできるDocker Composeファイルが提供されています。このファイルを使うことで、Dockerの理解を深めつつ、Logstash、Elasticsearch、Kibana、さらに後ほど登場するFilebeatも構築できます。あるいは、Sébastien Pujadasによる「elk-docker」ガイドを利用してElastic Stack Docker環境を構築する方法もあります。 環境が整ったら、「Configure Logstash」ガイドを詳しく確認してください。各サブチャプターには、試験目標に関連する重要な内容が含まれています。 Filebeatは、変換よりもログ転送に重点を置いた、シンプルかつ効率的なツールです。ログファイルを1行ずつ読み込み、最小限のオーバーヘッドで転送します。 Filebeatのドキュメントでは、概要説明と推奨されるスタートガイドが提供されています。また、Logstashのドキュメントでは、Filebeatに対応する「Beats input plugin」について説明されています。 別のアーキテクチャとして、Fluentdエコシステムをベースにした構成もあります。Fluentdは統合ログ基盤として機能し、ログの収集、処理、転送を行えます。構造化ログをサポートしており、多数のバックエンドと連携できます。 Fluent BitはFluentdの軽量版であり、エッジ環境やコンテナ化されたワークロード向けに最適化されています。Kubernetesクラスターでコンテナログを収集する用途で広く利用されています。 近年ますます人気を高めているスタックとして、Grafana Labsが開発したLokiがあります。Elasticsearchとは異なり、Lokiはログ本文全体ではなくメタデータ（ラベル）のみをインデックス化する設計になっており、ストレージおよびインデックスコストを大幅に削減できます。 PromtailはLokiと組み合わせて使用されるログ収集エージェントです。ファイルやコンテナからログを収集し、ラベルを付与してからLokiへ送信します。 LPIでは、syslogを使用してLogstashへログデータを転送する方法についても理解が求められます。syslogに不慣れな場合は、Aaron Leskiwによるsyslog入門がよい出発点になります。また、syslog.conf(5)のmanページも確認しておくとよいでしょう。Logstashをsyslogサーバーとして動作させるには、「Syslog input」を設定する必要があります。 BeatsやSyslogのinputプラグインに加えて、Logstashの機能は多数のinput、output、filterプラグインによって拡張可能です。DevOps Tools Engineer試験で扱われる技術に関連するモジュールについて理解を深めるため、これらの一覧を確認してみてください。 Elasticsearchはログデータの保存を担います。一見すると地味に思えるかもしれませんが、ログ分析を効果的に行うためには、Elasticsearch内でインデックスやデータ保持ポリシーを適切に設定する必要があります。Elasticsearchドキュメントの「Getting Started」ガイドでは、Elasticsearchそのものの概要を学べます。その後、インデックス管理やデータ保持についてさらに理解を深めましょう。 データがElasticsearchに保存されると、Kibanaによって、記録された情報へグラフィカルにアクセスし、集約・分析・探索できるようになります。Kibanaのドキュメントでは、データのインタラクティブな探索方法、可視化ツールの利用方法、ダッシュボード作成方法などが解説されています。 Kibanaは、ElasticsearchやOpenSearchに保存されたログを探索するための高機能なインターフェースを提供します。ダッシュボード、可視化機能、KQLなどのクエリ言語をサポートしています。 Grafanaは、Loki、Elasticsearch、Prometheusのような時系列データベースなど、複数のデータソースをサポートする柔軟な可視化プラットフォームです。ログ、メトリクス、トレースを統合したダッシュボードを作成できます。 Graylog2（一般的にはGraylogと呼ばれる）は、収集、処理、可視化を統合した別の集中ログ管理プラットフォームです。バックエンドとしてElasticsearchやOpenSearchを利用し、アラート機能やストリームベースのルーティング機能を備えた、扱いやすいインターフェースを提供します。 アプリケーションログやシステムログの仕組み、そして現代のログ管理スタックのアーキテクチャを理解することは、信頼性と可観測性を備えたシステム運用に不可欠です。従来のsyslogデーモンから、Elastic Stack、Fluentd、Lokiのような高度な分散プラットフォームまで、ログ管理は現代インフラにおける重要な柱へと進化しています。 次回は、LPI DevOps Tools v2.0 Engineer試験の最後の試験目標として、トレーシングとOpenTelemetryについて解説します。 ここまで本当によく学習を進めてきました。これからも構築し、実験し、スキルを磨き続けてください。そして、LPIが提供する無料の公式Learning Materialsを活用することで、さらに学習を深められることも忘れないでください。 << このシリーズの前の記事を読む | このシリーズの次の記事を読む >>

前回の記事では、関数型プログラミングを魅力的にしている特有の特徴について説明しました。本記事では、それらの概念が現代のプログラミングにどのように応用されているかを見ていきます。 関数型プログラミングの重要な影響 関数型言語は、多くのプログラマーから「難解」「学術的」「理解しづらい」と見なされ、長年一定の距離を置かれてきました。しかし、コンピュータ分野全体は、その概念に強く引き寄せられてきました。コンピューティングの歴史を振り返ったり、あるいは手軽にAIチャットボットへ質問したりすれば、もともと関数型言語で生まれた概念が、現在では Python、Java、Rust などの「主流」言語にも数多く取り入れられていることが分かります。 私が特に気に入っている関数型プログラミングの概念は、高階関数（Higher-Order Functions）です。これは、変数の集合や配列に対して関数を適用する仕組みです。この技法によって、ソースコード量を大幅に削減でき、比較的読みやすいコードを書けるだけでなく、非常に洗練されたプログラミング表現も可能になります。『Programming Scala』の著者である Dean Wampler は、高階関数が「ビッグデータ時代」に登場した MapReduce の考え方とも結び付いていると指摘しています。 型クラス（Type Classes）は、多様なオブジェクトに共通の操作（ポリモーフィズム）を適用するうえで重要です。たとえば、図形に対する「サイズ変更」操作や、同じ型のオブジェクト同士をプラス記号で結合するような処理がこれにあたります。 次に挙げたいのがパターンマッチングです。これは複雑に入れ子になった if 文や、繰り返される else 文を置き換える優れた仕組みです。構文的には、パターンマッチングは C 言語の switch/case 文を拡張したようなものです。C の case ブロックでは単一の定数しか扱えませんが、パターンマッチングでは範囲指定、値のグループ化、null のような特別な値まで指定できます。さらに、異なるデータ型のブロックを扱うことも可能です。 クロージャ（Closure）も関数型プログラミングでは極めて重要であり、命令型プログラミングにおいても価値があります。私はこれを、C++ で許可されていたものの後に好ましくない設計と見なされるようになった「多重継承」の利点の一部を提供するものだと考えています。 さらに興味深い仕組みとして、レキシカルスコープ（Lexical Scoping）があります。これは変数の利用範囲を特定のコードブロック内に限定するものです。これによって、本来意味を持たない場面で変数が使われているようなエラーを発見しやすくなります。 ここで各言語の革新をすべて列挙するつもりはありません。中には重要な関数型の概念でありながら、より目立つプログラミング技法を支える裏方として存在するものもあります。また、私個人としては、複雑すぎて見合う価値がないと感じるものもあり、もっと扱いやすい構文に置き換えられるべきだと思うものもあります。 『Erlang Programming』および『Designing for Scalability with Erlang/OTP』の著者である Francesco Cesarini は、関数型言語がマイクロサービスの発展を先取りしていたと指摘しています。マイクロサービスは、命令型プログラミングにおいてモジュール性を実現するための人気手法です。関数型言語は、単一プロセッサ上でも、マルチコアシステム上でも、さらにはネットワーク越しでも効率よく動作するよう、関数を徹底的に分離します。 複数コアを効率的に活用し、データをメモリ上に保持することで、関数型プログラムは単一システム上でも非常に高いスケーラビリティを発揮し、比較的重いネットワーク通信を回避できます。また、現代のインターネット向け負荷に対応する形でスケールアウトすることも可能です。 越えるのが難しい大きな隔たり しかし、関数型プログラミングから広まった巧妙な構文の先には、命令型プログラミングとは大きく異なるパラダイムが存在します。これこそが、関数型言語（定義は難しいにせよ）を依然として特別な存在にしており、多くのプログラマーが敬遠する理由でもあります。 命令型言語では、ループは繰り返し処理を扱う直感的な方法です。これは工場の自動化や、非営利団体が今でも大量郵便の封入作業に使うライン作業と同じように理解できます。関数型言語では、ループの代わりに再帰（特に末尾再帰）を使いますが、これは比較的わかりやすく、教えることも学ぶことも容易です。 私が関数型プログラミングを難しいと感じるのは、「副作用を完全に禁止する」という根本的かつ厳格な原則です。その結果、関数同士は変数（ましてやグローバル変数）を共有して、プログラムや環境の変化を追跡することができません。 これに対処する方法のひとつとして、Francesco Cesarini は状態データをキャッシュメモリで扱う手法を説明してくれました。（ここで、前回の記事で触れた Simon Peyton Jones のトランザクショナルメモリも重要になります。）また、Haskell の IO Monad も状態管理を助けます。別の著者は、「Haskell では、できる限り外側の層に到達するまで純粋性を維持しようとする」と述べています。 このようなグローバル変数の代替手法に加えて、関数型言語では文や関数が互いに複雑に包み込むような構造を取ります。これは、比較的階層構造が明確な命令型言語に比べ、多くの学習者にとって理解が難しいものです。 プログラミングはどこへ向かうのか 関数型プログラミング言語の歩みを説明するために、少し歴史の話をしたいと思います。題材はカードゲームの「コントラクトブリッジ」です。 ブリッジは20世紀初頭に誕生しました。シンプルなゲームであるホイストに、革新的なプレイヤーたちが高度なビッド（宣言）システムを加えたのです。長い間、アメリカでは Charles H. Goren が考案したビッドシステムが広く使われ、彼の本は多くのプレイヤーの本棚に並んでいました。 ビッドには高度な駆け引きがあり、繊細な思考が求められましたが、Goren のシステム自体は直感的でした。高いカードが多く、スペードが長く揃っていれば「1スペード」と宣言します。すると、パートナーが強いカードと長いダイヤを持っていれば、「2ダイヤ」と宣言します（各ビッドは前のビッドより高くなければならないためです）。 もちろん、「弱い2ビッド」や「プリエンプティブビッド」のような特殊ルールもありました。これらは、相手にもっと大きな得点を与えないため、あえて小さな損失を取る戦術です。しかし、基本的にはシステムは理解しやすく、多くの人々が楽しい時間をブリッジテーブルで過ごしていました。 ところが、上級者、特に競技用のデュプリケートブリッジを行うプレイヤーたちは、「1クラブ」という最も弱い宣言があまり役に立たないことに気づきました。そこで考案されたのが「ストロングクラブ」システムです。この方式では、「1クラブ」はクラブのスートとは無関係に、「私は強い手札を持っている」という意味になります。これにより、パートナー同士で最適な最終ビッドを探る余地が広がりました。 「ストロングクラブ」システムは、大半の手札では大きな違いを生みませんでした。しかし、デュプリケートブリッジでは、非常に強い手札のときに他テーブルのプレイヤーより少し有利になる可能性がありました。そのため、この方式は急速に広まりました。 しかし、「1クラブ」が本来の意味を失い純粋な記号になると、他にも記号的なビッドを導入する必要が生じ、ビッドは直感的な意味との結びつきを失っていきました。さらに、ビッドが記号化されると、多数の異なる「ストロングクラブ」システムが乱立するようになりました。そして複雑さに拍車をかけたのが、異なるビッドシステムを使う対戦相手への対応です。 要するに、ブリッジはもはや気軽な娯楽ではなくなったのです。友人同士で楽しむゲームではなく、プロ向けの競技になってしまいました。本格的にプレイするには、複数の非直感的な「ストロングクラブ」システムを暗記しなければなりません。そうでなければ、テーブル上の宣言のたびに相手から「そのビッドはあなたたちのシステムでは何を意味するのですか？」と確認されることになります。 ここで、このゲーム史の話を持ち出した理由を説明します。私は、多くのプログラミング言語――特に関数型言語――が、コンピューティングに対して「ストロングクラブ」がブリッジに与えたのと同じことをしていると考えています。これらの言語は、非常に複雑で多層的な思考を要求します。その結果、専門プログラマーと、シンプルな言語を学んで自分用の小さく便利なプログラムを書くアマチュアとの間に、高い壁が築かれてしまいました。（Basic、そしてその後の [...]

これまで本シリーズでは、アプリケーションのデプロイについて数多く取り上げてきました。しかし、アプリケーションを安定して稼働させ続ける方法についても理解する必要があります。Prometheus は、この課題に対応するために、DevOps Tools Engineer 試験で扱われている監視ツールです。 現代のIT運用は、単にシステムを稼働させ続けるだけではなく、さまざまな状況下でもサービスが継続的にユーザーへ価値を提供できるようにすることへ重点が移っています。運用チームはインフラを維持するだけでなく、信頼性、性能、拡張性といった面でサービスが期待を満たすことを保証する責任を担っています。 Prometheus は、そのシンプルさ、柔軟性、そしてクラウドネイティブアーキテクチャとの高い親和性によって、この分野の基盤ツールとして広く利用されています。Prometheus は時系列データベースおよび監視システムとして動作し、時間の経過とともに数値メトリクスを収集します。各メトリクスにはコンテキスト情報を提供するラベルが付与されており、細かなフィルタリングや集約が可能です。このモデルにより、オペレーターは個々のインスタンス、環境、サービスコンポーネントなど、複数の観点からシステムの挙動を分析できます。 Prometheus のドキュメントでは、Docker イメージを利用した方法を含め、インストール手順が説明されています。Prometheus を起動した後は、「Getting Started」ガイドに従い、Prometheus 自身を監視するよう設定できます。 Prometheus のアーキテクチャはプルモデルを採用しています。このモデルでは、サーバーが設定済みターゲットから定期的にメトリクスを取得します。ターゲットは通常、標準パスの HTTP エンドポイント経由でメトリクスを公開します。収集されたデータはローカルに保存され、時系列分析用に設計された強力なクエリ言語である PromQL を使用して問い合わせできます。 PromQL は、収集したデータから有益な情報を抽出するうえで中心的な役割を果たします。ユーザーはメトリクスを取得し、ラベルでフィルタリングし、複雑な集約処理を実行できます。ラベルによる集約を行うことで、インスタンスやサービス単位で分析し、負荷分散やエラー集中といったパターンを把握できます。また、時間単位での集約により、短期的な変動を平滑化し、長期的な傾向を明らかにできます。これらの機能により、PromQL は単なるクエリ言語ではなく、システム動作を理解するための強力な分析ツールとなっています。 他のシステムやアプリケーションを監視するには、Prometheus 用の exporter が必要です。exporter は Prometheus 向けに監視情報を収集します。たとえば Node exporterは Linux システムの状態情報を提供します。また、常時利用可能ではないメトリクスを収集するために、Prometheus Pushgateway を使用して情報をキャッシュし、後から収集できるようにすることも可能です。このほかにも、さまざまな用途向けの exporter が数多く存在します。Exporters documentationを確認し、自身のインフラに役立つ exporter を探してみてください。 ただし、メトリクスを収集するだけでは、信頼性の高い監視ソリューションを構築するには不十分です。特定のイベントが発生した際には、オペレーターが迅速に対応できるようアラートを生成する必要があります。Prometheus の Alertmanager はアラート管理を担当し、どのような条件で通知を送信するかを柔軟に設定できます。 アラートに加えて、レポートや可視化ツールも監視データへアクセスする重要な方法です。Prometheus は、データ分析および可視化ツールである Grafana と連携できます。ログデータを収集したら、Grafana のドキュメントを参照し、自分自身でダッシュボードを作成してみてください。アイデアが必要な場合は、他のユーザーが作成したダッシュボード画像を検索し、どのように監視データを活用しているか確認してみると良いでしょう。 どのメトリクスを監視対象にするかを決めることは、有効な監視を行ううえで非常に重要です。Anita Buehrle 氏による「RED Method for Prometheus」では、そのようなメトリクスの扱い方について解説されています。また、SmartBear の「Understanding [...]

このシリーズを通じて、「データモザイク」がどのように機能しているのか、つまり、一見すると小さく無害に思える個人情報が組み合わされることで、機微な情報まで明らかになってしまう仕組みを感じ取っていただけたなら幸いです。データ収集の技術は、今後さらに高度化していくでしょう。理論上、人は歩き方だけで識別できるようになっており、Wi-Fi信号によって壁越しに人物を特定することも可能です。次に会議やパーティーで誰かと話をするとき、その会話はCES 2026で大きな注目を集めた超小型デバイスによって録音されているかもしれません。NikeやAdidasは、「人間の思考に影響を与える」ことを目的に、靴へセンサーを搭載し始めています。また、人々は個人情報や機密性の高い法律相談までAIチャットボットに預けていますが、それらのプライバシー保護は脆弱で、情報漏えいのリスクも抱えています。さらに、多くの政府は、インターネット全体に侵襲的な本人確認システムを導入しようとしています。 しかし、こうした技術の進歩は、ますます複雑化する社会の要請に応える形で生まれている側面もあります。80億人を超える人々が暮らし、生活のスピードがコンピューターに追いつきつつある世界で、自律性、個人の選択、人間同士のつながりはどうあるべきなのでしょうか。私たちはもはや、昔ながらの方法だけで買い物をしたり、働いたり、市民生活に参加したりすることはできません。 データ収集は、私たちに「個人の自律性」に関する難しいジレンマを突きつけます。たとえば、自動車に搭載されたデバイスによるデータ収集に同意し、安全運転をしている場合、自動車保険料が大幅に割引されることがあります。 しかしその一方で、顔の見えないコンピュータープログラムが、あなたの手や足の動きを常に監視することになります。そのプログラムは、あなたが急ブレーキを踏んだことだけを見て「危険運転だ」と判断するかもしれません。実際には、その急ブレーキによって、突然自転車で飛び出してきた子どもの命を救ったにもかかわらずです。そして一般論として、既存の行動データに基づくアルゴリズムには、偏見や差別が入り込みやすく、それを避けることは非常に困難です。 このシリーズは、世界規模のサイバーセキュリティおよびデータ保護コンサルティング企業であるWhite Label Consultancyのパートナー兼創設者であり、データ保護責任者でもあるMagdalena Góralczykによるレビューを受けています。彼女は、現代のデータ収集が生み出す問題について、非常に的確な総括をしています。 「私にとって、現代のデータ収集の実態とは、それぞれを個別に見れば必要で有用に思えるものだということです。しかも、その多くは本人にとっても便利です。たとえば、掃除機が部屋の隅をきちんと掃除し、コードを巻き込まないのは素晴らしいことです。心拍数を測定されること、顧客アカウントに年齢情報が紐づけられること、コーヒーメーカーがメーカーと通信して新しい浄水フィルターを送ってくれること――それぞれは小さな代償に見えるでしょう。しかし、そうした積み重ねによって、私たちから少しずつ奪われていくのは、“自由”や“独立性”という感覚なのです。なぜなら、それらが合わさることで、私たちの人生は外部から大きく誘導されるようになり、その情報によって組織が私たちへの支配力を強めていることに、ほとんど気づかなくなってしまうからです。」 紙幅の都合上、このシリーズでは、個人情報の盗難やその他の悪意ある攻撃によって生じる追加リスクについては、ほとんど触れることができませんでした。これらの攻撃では、情報漏えいによって盗まれたデータと、公開されている個人情報が組み合わされて悪用されるケースが多く見られます。 私は、プライバシー侵害が投げかける問い――巨大で顔の見えない組織がさらに巨大化・遠隔化することをどう防ぐのか、誤りや偏見にどう対処するのか、どこに制限を設け、それをどう執行するのか、データ収集を規制すべきなのか、それとも分析やその結果を規制すべきなのか――に答えを出せるわけではありません。 しかし私は、現代のデータ収集がどれほど広範囲に及んでいるのかを示すと同時に、まだ一定の制限は存在していること、そして収集されるデータの中には有用かつ必要なものもあることを伝えようとしてきました。このシリーズが、限られた範囲ではあっても、自分自身の個人データをどう管理するかについて、読者の皆さんが何らかの判断を下す助けになったのであれば、このシリーズは成功だったと言えるでしょう。 << このシリーズの前回の記事を読む | シリーズを最初から読む >>