Digital Stacksは、4月6日～8日まで東京ビッグサイトで 開催された「Japan IT Week 春 2022」の「AI・業務自動化展」に、分散システムのログ収集・分析を自動化しSIEM対応する「Sumo Logic」をはじめ、20点を超えるSaaS製品を出展しました。また弊社のテクノロジー導入・運用コンサルティングサービス「Implement Digital」についてもご紹介しました。 Japan IT Week 春 2022は、3日間で4万人近いお客様が来場される盛況となりました。ハイブリッドクラウドやマルチクラウドといった環境でのDXへの関心が高まる中で、エージェントレスでそうした環境でのログ管理と分析が可能なSumo Logicにも注目していただきました。高度な可視性を備えた Sumo Logic Cloud SIEM Enterprise を使えば、オンプレミス、ハイブリッド、マルチクラウドの各インフラをシームレスに監視して、攻撃の影響と状況を完全に理解できます。ぜひお問い合わせください。 ご来場いただいた皆様には、弊社のSaaS総合カタログ「TechCatalog」のJapan IT Week版をお配りしました。全製品についての詳しい情報はこちらのサイトでご覧になれます。https://www.techcatalog.net/ また、弊社Facebookページで当日の写真をごらんいただけます。https://www.facebook.com/DigitalStacksCorporation

４月６日～８日まで東京ビッグサイトで 開催される「第31回 Japan IT Week 春」の「AI・業務自動化展」にSumo Logicをはじめ、多数のSaasを出展します。来場者限定で、Digital Stacksがお勧めするSaasツールを紹介するパンフレット「TechCatalog」 と、スタートガイドブックサンプル版を無料で贈呈いたします。是非ご来場ください。 入場には招待券が必要です。（招待券をお持ちでない場合、入場料￥5,000/人）弊社から無料の招待券をお配りしていますので、下記URLよりダウンロードしてご利用ください。e招待券URL： https://www.japan-it-spring.jp/ja-jp/visit/e-ticket-ex/ai.html?=coitharu2022?co=ml_ai-s-69zyvz ■展示会情報名称：第31回 Japan IT Week 春会期：2022年４月６日（水）～８日（金）時間：10:00～18:00（最終日のみ17:00終了）会場：東京ビッグサイト 東ホール主催：RX Japan株式会社 (旧社名: リード エグジビション ジャパン) 公式HP：https://www.japan-it-spring.jp/ja-jp.html

Digital Stacks（本社東京都品川区）は、10月27日～29日まで幕張メッセで 開催された「Japan IT Week 秋」（主催：RX Japan）の「システム運用自動化展」に、マルチクラウドやハイブリッドに対応したログ収集・分析ツールである「Sumo Logic」を出展しました。 Sumo Logicはあらゆるプラットフォームから収集したログのリアルタイム分析・管理、セキュリティ監視を実現するプラットフォームです。当日の弊社ブースには、DXに備えたマルチクラウド・ハイブリッド環境でのセキュリティに強い危機感をお持ちの、金融や公共機関を含むたくさんのお客様が、多数来訪されました。短いお時間でしたが、弊社からはSumo Logicのコンセプトと同時に出展していたPagerDutyやRundeckといったインシデント対応ツールとの連携についてご説明させていただきました。さらなるご説明を要望されたお客様には個別にコンタクトさせていただき詳細をお伝えいたします。 （弊社Facebookページで当日の写真をごらんいただけます。）https://www.facebook.com/DigitalStacksCorporation なお、Digital StacksではSumo Logicの導入の操作を解説した「Sumo Logic スタートガイドブック」を無料プレゼント中です。ご興味のある方はぜひご覧ください。Sumo Logic スタートガイドブックhttps://sumologic.dxable.com/readme-japan-it-week-autumn-2021 ■Sumo Logic:総合ログ管理の自動化オンプレミス＆マルチクラウド対応で各拠点からのログ収集を自動化し、イベントとログの相関分析の結果をダッシュボードに表示します。面倒な収集と分析を自動化することでデータ駆動型の意思決定が可能になり、セキュリティへの脅威や障害を迅速にとらえることができます。既にSIEM（Security information and event management）の要として国内外で2100社を超える企業が採用しています。 Digital Stacksでは、このほかにも企業の方のデジタルトランスフォームを支援する製品・サービスを取り扱っておりますので、ぜひこの機会に海外の新しいテクノロジーにご興味をお持ちの方は弊社までお問い合わせください。 ■展示会情報名称：第12回 Japan IT Week 秋会期：2021年10月27日（水）～29日（金）会場：幕張メッセ主催：RX Japan株式会社 (旧社名: リード エグジビション ジャパン)公式HP：https://www.japan-it-autumn.jp/ja-jp.html ■株式会社Digital Stacksについて株式会社Digital Stacksは、欧米を中心とした世界の最新クラウドテクノロジー製品をいち早く発掘して日本国内の法人のお客様に提供しています。全ての企業と企業人のデジタルトランスフォーメーションの加速をサポートし続けます。 本社所在地: 〒141-0001　東京都品川区北品川5-5-15 大崎ブライトコア4階SHIP 414号室代表取締役CEO: 島田憲治事業開始: 1995年3月URL： https://www.digitalstacks.net/ 本リリースに関するお問い合わせは広報担当：内海彩加 info@digitalstacks.netまでご連絡ください。

Digital Stacks（本社東京都品川区）は、10月27日～29日まで幕張メッセで 開催される「Japan IT Week 秋」の「システム運用自動化展」において、分散システムのログ収集・分析を自動化する Sumo Logicなどを出展します。 当社のブースにお立ち寄りいただくだけで、新世代のソフトウェア開発・運用監視・障害対応・各種業務の自動化ツールとプラットフォームについての情報を得られます。また、来場者限定で、各製品のスタートガイドブックなどを無料でプレゼントいたします。是非ご来場ください。 Sumo Logic:総合ログ管理の自動化オンプレミス＆マルチクラウド対応で各拠点からのログ収集を自動化し、イベントとログの相関分析結果をダッシュボードに表示します。面倒な収集と分析を自動化することでセキュリティへの脅威や障害を迅速にとらえることができます。SIEMの要として国内外の企業に広く使われています。 ■展示会情報『Japan IT Week 秋』（10月27日～29日、幕張メッセ） は日本最大のIT展示会です。今回も400社が出展する予定であり、ITの各分野を幅広く網羅して開催することで、ビジネス拡大を求める出展社、来場者にとって欠かせない展示会となっています。出展ブースでは製品・サービスの販売・受注、課題についての相談、見積り・導入時期の打合せなどが行われ、“実質的な商談の場”となっています。 名称：第12回 Japan IT Week 秋会期：2021年10月27日（水）～29日（金）時間：10:00～17:00会場：幕張メッセ主催：RX Japan株式会社 (旧社名: リード エグジビション ジャパン) 公式HP：https://www.japan-it-autumn.jp/ja-jp.html 入場には招待券が必要です。（招待券をお持ちでない場合、入場料￥5,000/人）弊社から無料の招待券をお配りしていますので、下記URLよりダウンロードしてご利用ください。 e招待券URLhttps://www.japan-it-autumn.jp/ja-jp/exhibit/ex_e_inv/aso.html?co=ml_aso-a-56spqg ■株式会社Digital Stacksについて株式会社Digital Stacksは、欧米を中心とした世界の最新クラウドテクノロジー製品をいち早く発掘して日本国内の法人のお客様に提供しています。全ての企業と企業人のデジタルトランスフォーメーションの加速をサポートし続けます。 本社所在地: 〒141-0001　東京都品川区北品川5-5-15 大崎ブライトコア4階SHIP 414号室代表取締役CEO: 島田憲治事業開始: 1995年3月URL： https://www.digitalstacks.net/ 本リリースに関するお問い合わせは広報担当：内海彩加 info@digitalstacks.netまでご連絡ください。

Dockerとは Dockerは、ソフトウェアコンテナのコンテナ化プラットフォームとして知られているオープンソースの仮想化テクノロジーです。コンテナは、独自のファイルシステムを含むアプリケーションを単一の複製可能なパッケージに含める手段を提供します。 2013年にソロモン・ハイクスによって開始されたDockerプラットフォームは、Linuxオペレーティングシステム用に特別に構築され、それ以来、コンテナの作成とデプロイを簡素化、自動化できることから、開発者とクラウドサービスプロバイダーの間で広く普及しています。 コンテナテクノロジーを使用すると、アプリケーションとそのすべての依存関係を標準化されたユニットにパッケージ化できるため、コンテナはすぐに仮想化の推奨アプローチになりつつあります。Dockerによる自動化は、その成功に不可欠です。 Dockerコンテナ コンテナは新しいテクノロジーではありません。仮想マシン（VM）と同様に、これらは何年も前から存在している仮想化の形式です。ただし、VMとは異なる点は、フットプリントのサイズです。 VMは仮想オペレーティングシステム全体を作成しますが、コンテナはアプリの実行に必要で、まだホストコンピュータで実行されていないファイルのみを持ち込みます。実行しているシステムのカーネルを共有することで無駄を省き、可能な場合はアプリ間の依存関係も共有します。つまり、パフォーマンスがよりスムーズになり、アプリケーションのサイズが小さくなり、デプロイメントがより速くなります。 Docker Engine Dockerコンテナは効率を提供するコンポーネントであり、Docker Engineはそれを可能にするものです。Dockerコンテナはイメージファイルから実行されます。これは基本的に、特定のオペレーティングシステムで特定のアプリケーションを実行するために作成されるファイルです。Docker Engineはそのイメージファイルを使用してコンテナを構築し、実行します。 軽量のDockerエンジンとそれが提供する簡単な自動化こそが、Dockerを成功したツールにした真の革新的ツールです。コンテナのデプロイを自動化する機能は、Dockerが一躍脚光を浴びるようになった理由です。仮想化環境におけるスケーラビリティの向上という利点を提供し、ビルドとテストの高速化を可能にします。 DockerはDevOps環境にどのように貢献するか DevOpsチームは、Dockerを使用することで多くの利点を得ます。OSリソースの即時起動と信頼性の向上により、このプラットフォームはアジャイル開発の高速な反復に最適です。開発環境は、同じバイナリと言語ランタイムを使用して、チーム全体で一貫しています。 コンテナ化されたアプリケーションはシステム全体でリソースの使用と環境が一貫しているため、DevOpsエンジニアは本番環境でも自分のマシンと同じようにアプリが動作することを確信することができます。また、Dockerコンテナはコンパイルの問題を解決し、開発プロセスにおける複数の言語バージョンの使用を簡素化するのにも役立ちます。 本記事は米国Sumo Logic社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

Dockerは、ソフトウェアコンテナのコンテナ化プラットフォームとして知られているオープンソースの仮想化テクノロジーです。コンテナは、独自のファイルシステムを含むアプリケーションを単一の複製可能なパッケージに含める手段を提供します。 2013年にソロモン・ハイクスによって開始されたDockerプラットフォームは、Linuxオペレーティングシステム用に特別に構築され、それ以来、コンテナの作成とデプロイを簡素化、自動化できることから、開発者とクラウドサービスプロバイダーの間で広く普及しています。 コンテナテクノロジーを使用すると、アプリケーションとそのすべての依存関係を標準化されたユニットにパッケージ化できるため、コンテナはすぐに仮想化の推奨アプローチになりつつあります。Dockerによる自動化は、その成功に不可欠です。 Dockerコンテナ コンテナは新しいテクノロジーではありません。仮想マシン（VM）と同様に、これらは何年も前から存在している仮想化の形式です。ただし、VMとは異なる点は、フットプリントのサイズです。 VMは仮想オペレーティングシステム全体を作成しますが、コンテナはアプリの実行に必要で、まだホストコンピュータで実行されていないファイルのみを持ち込みます。実行しているシステムのカーネルを共有することで無駄を省き、可能な場合はアプリ間の依存関係も共有します。つまり、パフォーマンスがよりスムーズになり、アプリケーションのサイズが小さくなり、デプロイメントがより速くなります。 Docker Engine Dockerコンテナは効率を提供するコンポーネントであり、Docker Engineはそれを可能にするものです。Dockerコンテナはイメージファイルから実行されます。これは基本的に、特定のオペレーティングシステムで特定のアプリケーションを実行するために作成されるファイルです。Docker Engineはそのイメージファイルを使用してコンテナを構築し、実行します。 軽量のDockerエンジンとそれが提供する簡単な自動化こそが、Dockerを成功したツールにした真の革新的ツールです。コンテナのデプロイを自動化する機能は、Dockerが一躍脚光を浴びるようになった理由です。仮想化環境におけるスケーラビリティの向上という利点を提供し、ビルドとテストの高速化を可能にします。 DockerはDevOps環境にどのように貢献するか DevOpsチームは、Dockerを使用することで多くの利点を得ます。OSリソースの即時起動と信頼性の向上により、このプラットフォームはアジャイル開発の高速な反復に最適です。開発環境は、同じバイナリと言語ランタイムを使用して、チーム全体で一貫しています。 コンテナ化されたアプリケーションはシステム全体でリソースの使用と環境が一貫しているため、DevOpsエンジニアは本番環境でも自分のマシンと同じようにアプリが動作することを確信することができます。また、Dockerコンテナはコンパイルの問題を解決し、開発プロセスにおける複数の言語バージョンの使用を簡素化するのにも役立ちます。 本記事は米国Sumo Logic社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

By Sumo Logic クラウドを利用して仕事をする組織はますます増えています。どのようなクラウドモデルを採用するかは、企業のビジネスモデルによって異なります。クラウドサービスの最も一般的な導入モデルは、SaaS（Software-as-a-Service）、PaaS（Platform-as-a-Service）、IaaS（Infrastructure-as-a-Service）の3つです。 ここでは、これらのクラウドモデルの違いと、組織に適したモデルを選択する際に考慮すべき点について説明します。また、これらの導入モデルを管理する際に、Sumo Logic がどのように役立つかをご紹介します。 SaaS SaaSとは​ SaaS（Software as a Service）とは、インターネットを利用して、サードパーティのベンダーが管理するアプリケーションをユーザーに提供することです。 提供方法​ SaaSは、サードパーティによりインターネットを介して、すべてのクライアントに直接に機能が提供されます。ソフトウェアのメンテナンスはサードパーティがリモートで行います。 SaaSのメリット ベンダーがリモートでインストール、設定、メンテナンスを行うため、クライアントのIT部門は、事業に関わるより重要な問題に時間を割くことができます。これは時間の節約だけでなく、コストの節約にもつながります。 SaaSの特徴 SaaSアプリケーションは、インターネットを介してアクセスすることができます。これらのアプリケーションは集中管理され、リモートサーバにホストされています。必要なハードウェアとソフトウェアの設定は、ユーザーではなくベンダーが責任を持って行います。 SaaSを利用する理由 第一に、SaaSはソフトウェアを管理する時間がない企業、例えばスタートアップ企業にはメリットがあります。 第二に、SaaSの導入方法は、Webやモバイルからアクセスできるアプリケーションが必要な場合に非常に適しています。また、日常的に使用しないアプリケーションにもお勧めです。 最後に、SaaSはサブスクリプション型のため、短期間だけ特定のアプリケーションが必要な場合に適しています。 制限事項と懸念事項 SaaSの導入モデルを使用する際には、いくつかの制限や懸念事項があります。まず、ベンダーロックインが発生する可能性があります。SaaSアプリの習得は簡単かもしれませんが、他のSaaSアプリに移行する際には、データのポータビリティに大きなコストがかかることに注意してください。また、すべてのSaaSアプリがインテグレーションのためのオープンスタンダードに準拠しているわけではないため、相互運用性の低さにも注意が必要です。そのため、他のアプリと接続する際に問題が発生する可能性があります。 セキュリティについては、パブリッククラウドベースのSaaSアプリは、機密性の高いビジネスデータを転送する際のセキュリティが低く、セキュリティ、コンプライアンス、プライバシーの問題につながる可能性があります。 最後に、SaaSアプリは専門性の高いアプリであるため、万能なソリューションは存在しません。そのため、カスタマイズはオンプレミスのアプリに比べて困難です。 Sumo LogicとSaaSベンダー Sumo Logicは、クラウド規模でアプリケーションを運用し、セキュリティを確保するためのリアルタイムSaaSプラットフォームです。ここでは機械学習が重要な役割を果たします。Salesforceのような他のSaaSプラットフォームと簡単にインテグレーションすることができます。 Sumo Logic Continuous Intelligenceソリューションを使用すると、Salesforceのパフォーマンスをリアルタイムで監視できるだけでなく、セキュリティ侵害の可能性を迅速に特定して修正することができます。これは他のSaaSアプリにも当てはまります。 SaaSの例 Salesforce Google GSuite PaaS PaaSとは Platform as a Service（PaaS）は、開発者がカスタマイズしたアプリケーションを構築できるフレームワークを提供します。 提供方法 PaaSの提供方法はSaaSとほぼ同じです。インターネットでソフトウェア機能を提供する代わりに、PaaSはソフトウェアを作成するためのプラットフォームを提供します。PaaSでは、企業はミドルウェアと呼ばれるソフトウェアコンポーネントを使って、PaaSに組み込まれたアプリケーションを設計・作成することができます。 PaaSのメリット PaaSを利用すると、アプリの開発、デプロイが簡単で低コストでできます。開発されたアプリは拡張性と可用性が高くなります。開発者はミドルウェアを気にすることなくアプリをカスタマイズすることができるため、開発スピードが速くなります。 PaaSの特徴 仮想化技術により、必要に応じてリソースを簡単にスケールアップ／ダウンすることができます。PaaSは基本的にアプリケーションの開発、テスト、デプロイメントを支援するサービス群です。複数のユーザーが同じ開発プラットフォームを介してアクセスでき、Webサービスやデータベースとのスムーズなインテグレーションが可能です。 PaaSを利用する理由 PaaSを使えば、開発のワークフローを効率化することができます。 PaaSは拡張性のあるカスタマイズされたアプリケーションのための素晴らしいプラットフォームを提供します。 PaaSを利用すれば、限られた予算の中でプラットフォームを持つことができ、コストを削減することができます。また、迅速なアプリ開発とデプロイも可能になります。 制限と懸念事項 SaaSと同様に、PaaSにも制限や懸念事項があります。組織はPaaSソリューション上で独自のアプリを実行することができますが、データはPaaSベンダーによって管理されているサードパーティのサーバ上にあります。このため、データのセキュリティやプライバシーのリスクが懸念されます。 ベンダーロックインの可能性があり、ベンダーがしっかりとした移行ポリシーを持っていない場合、PaaSソリューションを切り替えるのは難しいかもしれません。 PaaSソリューションがあなたの選択したフレームワークや言語と互換性がない場合、ランタイムの問題が発生する可能性があります。PaaSソリューションが動作する言語やフレームワークのバージョンにも注意してください。 また、レガシーシステムをお持ちの場合には、レガシーシステム用にカスタマイズできないPaaSソリューションもありますので、注意が必要です。 PaaSの例 Windows Azure Google App Engine Sumo LogicとPaaSベンダー Microsoft Azure Cloud は、Sumo Logic との連携が可能な PaaS ソリューションの一例です。Azure MonitorやEvent Hubとのインテグレーションは簡単です。Sumo Logicは Azure Audit、Network Inspector、SQL、Active Directory などのコンテンツの可視性を高めることもできます。   IaaS IaaSとは IaaS（Infrastructure as a Service）とは、コンピュータやストレージ、ネットワークなどへのアクセスや監視が可能なコンピューティングリソースのことです。追加でハードウェアを購入する必要はありません。 クライアントはIaaSベンダーからハードウェアをリースします。 IaaSの提供方法 提供は仮想化されたクラウドサーバを介して行われます。ダッシュボードやAPIを利用して、クライアントがインフラ全体を完全にコントロールできるようにします。IaaSはクラウド上の「仮想データセンター」をアウトソースしたものです。 SaaSやPaaSとは異なり、IaaSのクライアントはアプリケーションやオペレーティングシステムなどを管理する責任があります。しかし、サーバやハードドライブなどはIaaSプロバイダーが管理します。 IaaSのメリット IaaSは、ストレージ、ネットワーク、サーバ、処理能力をシンプルに配置した非常に柔軟性の高いクラウドコンピューティングモデルです。 IaaSのコストは様々ですが、基本的にはクライアントの利用量に依存します。クライアントはインフラを完全にコントロールすることができ、高いスケーラビリティから利益を得ることができます。 IaaSの特徴 IaaSの特徴は、リソースをサービスとして提供するハードウェアインフラをリースすることです。前述の通り、利用量に応じてコストが変動します。 複数のユーザーが1つのハードウェアで作業することができます。そのため、非常に柔軟で拡張性の高い導入モデルとなっています。 IaaSを利用する理由 スタートアップや小規模企業にとって、IaaSはハードウェアやソフトウェアを購入せずに開発が行える手段です。これにより、時間とコストを節約することができます。大企業や成長企業にとっては、現在のニーズに応じて特定のハードウェアやソフトウェアに切り替える必要があるため、IaaSはメリットがあります。 制限と懸念事項 SaaSやPaaSと同様に、IaaSにも一定の制限や懸念点があります。 IaaSベンダーとクライアントは仮想マシンを介して接続されており、セキュリティが危うくなる可能性があります。複数企業で環境を共有するマルチテナントの場合、IaaSベンダーはクライアントのみが割り当てられたIaaSソリューションにアクセスでき、他のクライアントはアクセスできないようにしなければなりません。 PaaSと同様に、IaaSにもレガシーシステム用にカスタマイズできない可能性があります。 顧客はデータのセキュリティ、バックアップ、事業継続の責任を負うことになります。これには十分なトレーニングが必要であり、費用と時間がかかります。 IaaSの例 Amazon Web […]

ログは貴重です。クライアントに重要なデータへのアクセスを提供するバックエンドのリソースによって生成されるログは、単に価値があるだけではありません。ログがどこにあるかを知り、その情報を管理・理解できるかどうかで、スムーズで安全な操作ができるかどうか、パフォーマンスが低下するかどうか、あるいはアプリケーションの致命的な障害が発生するかどうかが決まります。 MySQL サーバは基本的なログを生成します。ここでは、どのログが重要なのか、なぜ重要なのか、どこにあるのか、そしてログを最大限に活用するために何ができるのかを見ていきます。 MySQLのログ 日々のIT運用において最も重要な3つのログは、エラーログ、低速なクエリのログ、（程度は低いですが）一般的なクエリのログです。これらのログのデフォルトフォーマットはテキストで、機能的な問題やセキュリティの問題の検出や診断、パフォーマンスの向上、サーバ操作やサーバへのアクセス履歴を追跡するのに役立ちます。 バイナリログ、リレーログ、DDLログはすべてバイナリ形式で、主にMySQL自身が使用するように設計されており、特にサーバのレプリケーションやデータリカバリなどのタスク用に設計されています。 どこで、どのように まず、様々なMySQLディストリビューションがどのように、どのような状況下でデフォルトのログファイルの場所を設定しているのかを簡単に見てみましょう。 MySQLディストリビューションには、基本的に3つのタイプがあります。Windows、特定のプラットフォーム固有のUNIX/Linux、一般的なUNIX/Linuxです。一般的に、プラットフォーム固有のディストリビューションでは、ログの配置と有効化のためのデフォルト設定がありますが、一般的なUNIX/Linuxディストリビューションでは、手動設定でログを管理することを前提としています。 Windows 公式の MySQL Windows ディストリビューションでは、インストールの各段階でユーザーが選択可能なオプションを備えた MSI インストーラを使用しています。ロギングオプションのページでは、ログの有効化と場所のデフォルトが表示され、必要に応じて調整を行うことができます。 エラー、低速クエリ、バイナリログは、デフォルトで有効になっていますが、一般的なクエリログは有効になっていません。各ログのデフォルトの場所は、MySQL Data ディレクトリ（C:¥ProgramData¥MySQL Server [バージョン]¥Data）で、デフォルトのログ名はコンピュータのデバイス名に基づいています。 一般的なクエリ、低速クエリ、バイナリログはインストーラの GUI を通じて手動で有効／無効にできますが、エラーログはできません。また、各ログの名前とパスを手動で設定することもできます。 インストール後、ログの設定はユーザーが編集可能な C:¥ProgramData¥MySQL¥MySQL Server [バージョン]¥my.ini で管理されます。このファイルでログ名やパス、有効／無効を設定できます。 プラットフォーム固有のUNIX/Linux 特定の UNIX/Linux プラットフォーム用の公式ディストリビューションは、一般的にスクリプトでインストールされ、対話的な設定はほとんど、あるいは全く行われません。いくつかのインストールパッケージ（Yum や APT を含む）は、エラーログを /var/log/ や /var/log/mysql/ に error.log や mysqld.log のような名前で作成します。データディレクトリは通常 /var/lib/mysql/ またはそれに類似したものになり、代わりのパスがなくてもログのデフォルトの保存先として有効に機能します。 ログの設定は /etc/mysql/my.cnf のようなユーザーが編集可能な設定ファイルで管理します。これらの設定には、ログ名やパス、スイッチの有効化／無効化などが含まれます。起動とシャットダウンは通常 mysqld_safe（あるいは一部のディストリビューションでは systemd）によって管理されており、ログ設定オプションを見つけて適用します。 一般的な UNIX/Linux 一般的なインストールは、主に手動で行います。インストールプロセス中に、コマンドライン、スクリプトの実行、または適切な設定ファイルの編集により、ログの有効化と設定を行うことができます。MySQL オンラインリファレンスマニュアル（https://dev.mysql.com/doc/refman/5.7/en/server-logs.html）で、これらのオプションについて詳しく説明しています。 【訳注】MyQL5.6日本語リファレンスマニュアルは、https://dev.mysql.com/doc/refman/5.6/ja/ にあります。 エラーログ エラーログには、起動時やシャットダウン時だけでなく、サーバ操作中に生成されたエラーメッセージ、警告、注意事項が含まれており、起動時間やシャットダウン時間も記録されます。 基本的なエラーログのフォーマットは以下の通りです。   timestamp thread ID [error type] [error code] [MySQL subsystem] Error message text Error types include System, Warning, Note, and ERROR. Typical log entries might look like this: 2020-05-24T11:55:27.611014Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.20) starting as process 36070 2020-05-24T12:14:51.002836Z 2 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started […]

Apache のアクセスログとは？ 前述したように、Apache のアクセスログは Apache HTTP サーバによって生成されるログファイルの一つです。この特定のログファイルは、Apache サーバによって処理された全てのリクエストのデータが記録されます。ですから、もし誰かがあなたのサイトのWebページを訪問した場合、 アクセスログファイルにはこのイベントに関する詳細が記録されます。 この情報は様々な状況で価値があります。例えば、特定のWebページにアクセスしようとする人が同じリクエストで失敗している場合、リンクはもはや存在しないページを指している可能性があります。サイト上の特定のページの読み込みに時間がかかっている場合、ログエントリはパフォーマンスを改善するためにリファクタリングされたSQLクエリを示している可能性があります。 Apache のアクセスログはどこにある？ Apache アクセスログの場所は Apache HTTP サーバが動作しているシステムに依存します。Apache HTTP サーバのインスタンスの大部分は Linux ディストリビューション上で動作しています。そこで、この記事では、Linux マシン上で Apache のアクセスログがどこにあるのかを詳細に説明します。 例えば、Ubuntu Linux ディストリビューションでは、アクセスログの記録はデフォルトで以下の場所に書き込まれます。 /var/log/apache2/access.log また、CentOSでは以下の場所にあります。 /var/log/httpd/access.log デフォルトの場所は他の Linux ディストリビューションでは多少異なるかもしれませんが、 ほとんどの場合はそれほど遠くを探す必要はありません。最終的には、アクセスログの場所とフォーマット（これについては後述します）は CustomLog ディレクティブで定義されていて、Apache HTTP サーバの設定の中で見たり変更したりすることができます。 Apache のアクセスログの解釈 Apache のアクセスログがどのようなもので、どこにあるのかがわかったところで、開発チームや他の IT 担当者が有効に活用できるように、エントリをどのように解釈するかを説明します。 Apache のアクセスログを読む Apache のアクセスログを理解するには、解析者がアクセスログがどのような形式で記録されているかを理解する必要があります。前述したように、アクセスログのフォーマットは場所と共に CustomLog ディレクティブで定義されています。以下では、Apache のアクセスログでよく利用されている2つの一般的なログフォーマットを見ていきます。 Common Log Format（共通ログフォーマット） Common Log Format は、いろいろなWebサーバがサーバログファイルを生成する際に使用する標準化されたテキストファイル形式です。Apache HTTP サーバでは、Common Log Format を使用して、開発者や管理者が読みやすいアクセスログを生成することができます。さらに、複数のWebサーバで使用されている標準化されたフォーマットなので、Common Log Formatのログファイルは多くのログ解析プラットフォームで簡単に使用することができます。 Common Log Format で書かれたアクセスログレコードは以下のようになります。 127.0.0.1 – Scott [10/Dec/2019:13:55:36 -0700] “GET /server-status HTTP/1.1” 200 2326 上記のサンプルレコードのフィールドは以下を表します。 127.0.0.0.1：要求を行ったクライアントの IP アドレス。 ログファイルの2番目のフィールドを定義するハイフンはクライアントの ID です。このフィールドはハイフンとして返されることが多く、Apache の HTTP サーバのドキュメントでは、制御された内部ネットワークの場合を除いて、この特定のフィールドに頼らないことを推奨しています。 Scott：リソースをリクエストする人の userid です。 [10/Dec/2019:13:55:36 -0700] ：リクエストの日時。 “GET /server-status HTTP/1.1”：リクエストの種類と要求されているリソース。 200：HTTP レスポンスステータスコード。 2326：クライアントに返されるオブジェクトのサイズ。 Combined Log Format（複合ログフォーマット） Apache のアクセスログでよく使われるもう一つのフォーマットは Combined Log Format です。このフォーマットは […]

マルチクラウドアーキテクチャの人気が高まるにつれて、マルチクラウド環境を保護する方法を求める組織がますます増えています。マルチクラウドアーキテクチャにはセキュリティに対する根本的に異なるアプローチが必要であると結論付ける人もいます。 これは、マルチクラウドアーキテクチャのセキュリティに関する神話の一例です。マルチクラウドセキュリティに関する他の一般的な神話とともに、この仮定に欠陥がある理由を見てみましょう。 神話1：マルチクラウドにはセキュリティの見直しが必要 マルチクラウドアーキテクチャにはセキュリティ戦略の完全な見直しが必要であるという最初の神話から始めましょう。 実際には、見直しが必要になることはめったにありません。すでにあるクラウドセキュリティツールとプロセスは、シングルクラウドに対応するだけでなく、マルチクラウドアーキテクチャにも対応できるでしょう。 もちろん、クラウドセキュリティ戦略を微調整する必要はあるかもしれません。たとえば、すべてのクラウドの可視性を最大化するために、各クラウド環境から1つの場所にデータを収集し集約しているかを確認する必要があります。ただし、既存のログ集計ツールでもこれを行うことができます。新しいツールセットを作成する必要はありません。 神話2：マルチクラウドは堅牢なセキュリティを必要としない マルチクラウドのセキュリティに関する間違った想定は、マルチクラウドのセットアップでは、セキュリティについてそれほど心配する必要がないということです。 この考えは、マルチクラウドアーキテクチャが、冗長性のあるインフラを提供するため、可用性が向上するという事実に由来しています。「パブリッククラウドは侵入不可能であるという神話」を読んでみても、あなたは一度に使用するクラウドが多ければ多いほど安全であると信じているのかもしれません。 マルチクラウドの利点の1つは、プロバイダーの1つがダウンしても、データとアプリケーションを使用可能に保つことができるということですが、この機能をセキュリティと混同しないでください。可用性とセキュリティは同じものではありません。 したがって、複数のクラウドを採用すれば、堅牢なクラウドセキュリティポリシーに従う必要性はないというのは誤りです。使用しているクラウドの数に関係なく、クラウドセキュリティは重要です。 神話3：そのクラウド専用のセキュリティツールを使用する必要がある 1つのクラウドのみを使用する場合、そのクラウド専用に設計されたセキュリティツールを使っているかもしれません。たとえば、AWSにはInspectorを、AzureではAzure Security Centerを使用するといった具合です。 これらは、そのクラウドをサポートするために設計された便利なツールであり、シングルクラウドアーキテクチャで使うには何も問題もありません。しかし、効果的で合理化されたマルチクラウドセキュリティアプローチは、全てのクラウドをサポートできる分析と可視性ツールに基づいています。マルチクラウドリソースを監視しようとするときには、複数のセキュリティツールを併用することは望ましくありません。 マルチクラウドアーキテクチャを保護する方法：可視性と統合 マルチクラウドアーキテクチャとセキュリティに関する誤解について説明したので、次はマルチクラウドのセキュリティに対する効果的なアプローチについて考えてみましょう。 簡単に言うと、成功するマルチクラウドセキュリティ戦略は、セキュリティに対するプラットフォームレベルのアプローチに基づいた戦略です。複数のツールを使用して各クラウドを保護しようとしたり、マルチクラウド環境に存在するセキュリティリスクを無視したりするのではなく、すべてのクラウドの可視性と統合を最大化することに重点を置きます。 プラットフォーム全体の可視性と統合を最大化することにより、個々のクラウドを個別に処理する必要がないためワークフローを合理化できるだけでなく、異なるクラウド間でワークロードを簡単に移動したり、クラウドプロバイダーを別のものに置き換えたりすることもできます。変更するたびにセキュリティ戦略を調整する必要はありません。 マルチクラウドアーキテクチャの利点の1つは、ベンダーによるロックインを回避することであるため、これは重要です。マルチクラウドアーキテクチャが進化した時にセキュリティ戦略を調整できず、特定のクラウドベンダーとサービスにロックされるセキュリティ戦略は必要ありません。 DevSecOpsの完全な可視性 ダウンタイムを削減し、事後対応型から予防型の監視に移行します。 カテゴリー AWS Azure GCP SecOpsとセキュリティ スポットライト 継続的インテリジェンスレポート