Japan IT Week 春出展報告

On 2022年4月19日

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

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
" target="_blank">

Sumo LogicをJapan IT Week 春に出展します

On 2022年3月21日

４月６日～８日まで東京ビッグサイトで開催される「第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

入場には招待券が必要です。（招待券をお持ちでない場合、入場料￥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
" target="_blank">

Sumo Logicを出展～Japan IT Week 秋

On 2021年11月10日

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 秋」（主催：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
までご連絡ください。
" target="_blank">

分散システムでのログ収集と分析を自動化するSumo LogicをJapan IT Week秋に出展

On 2021年10月22日

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までご連絡ください。

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招待券URL
https://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
までご連絡ください。
" target="_blank">

Kubernetesとは

On 2020年10月5日

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とは 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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。" target="_blank">

Dockerとは

On 2020年10月5日

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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

コンテナ化プラットフォームとして知られているオープンソースの仮想化テクノロジーです。コンテナは、独自のファイルシステムを含むアプリケーションを単一の複製可能なパッケージに含める手段を提供します。 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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。" target="_blank">

SaaS、PaaS、IaaSのメリット、デメリット

On 2020年7月2日

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 […]

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 Services
- Google Compute Engine
Sumo LogicとIaaSベンダー

前述の通り、サードパーティ製のインフラ（IaaS）をリースする際には、セキュリティが課題となります。そこでSumo Logicは、IT組織に提供するセキュリティ分析ツールを作成しました。
- クラウドネットワークセキュリティの統合ビュー
- クライアントのプライベートクラウド、パブリッククラウド、ハイブリッドクラウドの監視ソリューション
あらゆるクラウドデリバリーシステム（SaaS、PaaS、IaaS）に対応するために、Sumo Logicはクライアント向けのソリューションを用意しています。

本記事は米国Sumo Logic社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
" target="_blank">

MySQLのログファイル

On 2020年6月17日

ログは貴重です。クライアントに重要なデータへのアクセスを提供するバックエンドのリソースによって生成されるログは、単に価値があるだけではありません。ログがどこにあるかを知り、その情報を管理・理解できるかどうかで、スムーズで安全な操作ができるかどうか、パフォーマンスが低下するかどうか、あるいはアプリケーションの致命的な障害が発生するかどうかが決まります。 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 […]

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 with id 2
2020-05-24T12:41:45.059924Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2020-05-24T12:41:45.086628Z    0 [ERROR] [MY-011825] [InnoDB] Failed to delete file ./#innodb_temp/temp_7.ibt
```
エラーログは常に有効で、利用可能なオプションでは、ログ出力先、冗長レベル、タイムゾーンを設定することができます。可能なエラーログの出力先は、ファイルまたはコンソールです。Windows では出力先オプションが指定されていない場合、エラーログはデータディレクトリの host_name.err（host_name はホストシステム名）に書き込まれます。UNIX/Linux システムでは、オプションが指定されていない場合のデフォルトの保存先はコンソールです。 UNIX/Linux と Windows ベースの MySQL の両方のインストールでは、--log-error オプションを指定すると（ファイル名やパスを指定せずに）、エラーログを Data ディレクトリの host_name.err に送信します。 --log-error='G:¥TMP¥mysql_logs¥mysql_error.err' や、 --log-error=/var/log/mysql/error.log のようにファイル名とパスを指定すると、エラーログは指定されたファイルに書き込まれます。Windows のコンソールにエラーログを送信するには --console オプションを使用する必要があります。
一般的なクエリログと低速クエリログ
一般的なクエリと低速クエリのログは、どちらも同様のフォーマットを使用してユーザーのクエリを記録します。Time、ID、Command、Argument（ArgumentにはSQLコマンドとクエリを構成するデータの両方が含まれます）です。一般的なクエリログには、すべてのクライアントのSQL文と接続時間と切断時間が記録され、低速クエリログには、long query-timeシステム変数で指定された時間よりも長い時間がかかるクエリのみが記録されます。低速クエリログには、ログに記録された各クエリの実行時間、ロック時間、送信された行、検査された行を含むフィールドのセットも含まれています。典型的な一般的なクエリログのエントリは以下のようになります。
```
2020-05-26T08:01:39.429740Z   	17 Query    INSERT INTO rental VALUES (1,'2005-05-24 22:53:30…
```
同じイベントの低速クエリログのエントリは、次のようになります。
```
# Time: 2020-05-26T08:01:50.095050Z
# User@Host: root[root] @ localhost [::1]  Id:	17
# Query_time: 10.699002  Lock_time: 0.037315 Rows_sent: 0  Rows_examined: 0
use sakila;
SET timestamp=1590480099;
INSERT INTO rental VALUES (1,'2005-05-24 22:53:30…
```
遅いクエリログでは、実行に異常に長い時間を必要とするクエリを特定することができます。一般的なクエリログでは、すべてのクライアントのSQL文を追跡することができ、エラーの追跡や潜在的なセキュリティ問題の特定に役立ちます。クエリログはデータを急速、大量に蓄積することがあるため、ディスク容量を消費するだけでなく、システムのパフォーマンスにも影響を与える可能性があります。特に一般的なクエリログは非常に速く増える可能性があり、ほとんどのインストールパッケージではデフォルトでクエリログと低速クエリログの両方が無効になっています（ただし、Windows MySQL インストーラは例外で、上述の通りです）。一般クエリログと低速クエリログは、--general-log と --slow-query-log オプションを使用して別々に有効化します。デフォルトの出力先はデータディレクトリで、ファイル名は[ホスト名].log と [ホスト名]-slow.log です。ログ名とパスを設定するには、--general-log-fileと--slow-log-fileオプションを使用します。両方のログの形式は、単一のオプション --log-output で制御され、FILE、TABLE、またはNONEの値をとり、FILEがデフォルト値です。TABLE は両方のログをテーブルとして保存し、SQL クエリで読み込んで管理することができます。FILEとTABLEはカンマで区切って一緒に使用することができます。NONE は、両方のログの出力を無効にします。
バイナリ、リレー、DDLログ
バイナリログとリレーログはサーバのレプリケーションに必要なもので、DDL ログは mysqld 操作中のメタデータを管理するためにシステムによって使用されます。これらのログは診断のための用途は限られていますが、データ復旧プロセスの一部として mysqlbinlog ユーティリティを使用してバイナリログやリレーログにアクセスする必要があるかもしれません。
すべてをまとめる
実は、比較的少ないサーバログから、MySQLは多くのログデータを生成することができます。同時に、そのデータの要素は、エラー追跡、パフォーマンス、セキュリティの観点から重要なものである可能性があります。知りたいことを見つけるために、MySQL サーバログを整理して並べ替えるには、どのような方法があるでしょうか。 Sumo Logic App for MYSQL は、エラーや低速クエリログから重要なメトリクスやデータ項目を自動的に抽出し、読みやすいダッシュボードに表示します。Sumo Logic を使用すると、パフォーマンスの問題、異常な動作やアクティビティのパターン、重要なエラーを簡単に特定できます。システムの健全性、レプリケーションの状態、サーバのパフォーマンスをひと目で確認でき、低速クエリ（ホスト、IP、ユーザー名などの情報）、ログインの失敗（ユーザー、ホスト、ロケーション）、レプリケーションとサーバの問題に関する詳細なリアルタイム情報を掘り下げて確認することができます。ログファイルを調べるのに何時間も費やす必要はありません。Sumo Logic に仕事を任せて、顧客サービスに専念できるようにしましょう。
Michael Churchman
Michael Churchman氏は、ゲーム業界の初期の何でもありの時代に、脚本家、編集者、プロデューサーとしてスタートしました。’90年代の大半を大きなプレッシャーがかかるバンドルソフトウェア業界で過ごしましたが、そこはすでにウォーターフォールから高速リリースへの移行が進んでおり、継続的リリースと自動化されたデプロイメントがすでにデファクトスタンダードとなっていました。この間、彼は15以上の言語でローカリゼーションを管理するための半自動システムを開発しました。過去10年間、彼はソフトウェア開発プロセスと関連するエンジニアリング管理の問題の分析に携わってきました。彼はFixate.ioの定期的なコントリビューターです。本記事は米国Sumo Logic社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。" target="_blank">

Apacheアクセスログを理解する

On 2020年6月5日

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 です。このフォーマットは […]

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 です。このフォーマットは Common Log Format に非常に似ていますが、分析やデバッグに使うためのより多くの情報を提供するためにいくつかの追加フィールドが含まれています。Combined Log Format で記録されるアクセスログレコードは以下のようになります。 127.0.0.1 - Scott [10/Dec/2019:13:55:36 -0700] 'GET /server-status HTTP/1.1' 200 2326 'http://localhost/' 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36' ご覧のように、最初の 7 つのフィールドは Common Log Format のものと同じです。残りのフィールドは、2 つの追加プロパティを表します。
- 'http://localhost/'：HTTP リファラ。リソースへのリクエストが発生したアドレスを表します。
- 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36'：ユーザーエージェント。クライアントがリソースにアクセスするために使用しているブラウザに関する情報を識別します。
CustomLog' ディレクティブ
先ほど、Apache のアクセスログの設定は Apache HTTP サーバ設定ファイルの中の CustomLog ディレクティブで行われることを述べました。CustomLog ディレクティブの柔軟性を示すために、アクセスログの設定のサンプルを見てみましょう。 LogFormat '%h %l %u %t '%r' %>s %O '%{Referer}i' '%{User-Agent}i'' combined CustomLog /var/log/apache2/access.log combined ここでは、LogFormat ディレクティブで結合されたログのフォーマットを定義し、その後、CustomLog ディレクティブでアクセスログの場所と結合されたフォーマットを定義しました。ご覧のように、アクセスログの場所やフォーマットを変更するのは簡単なプロセスです。さらに、CustomLog ディレクティブを使うことで、以下で説明する他のいくつかの機能が得られます。
複数のアクセスログ
Apache HTTP サーバ用に複数のアクセスログを設定できないというルールはありません。 LogFormat '%h %l %u %t '%r' %>s %O '%{Referer}i' '%{User-Agent}i'' combined LogFormat '%{User-agent}i' agent CustomLog /var/log/apache2/access.log combined CustomLog /var/log/apache2/agent_access.log agent
条件付きログ
また、アクセスログに条件付きで書き込むことも可能です。これは、特定のクライアントに関連付けられたレコードを除外するなど便利です。通常、これは環境変数'env'に設定することで実行されます。詳細は CustomLog ディレクティブの公式ドキュメントを参照してください。
ログローテーションとパイプ経由のログ
サーバ上の他のファイルと同様に、ログファイルはスペースを取ります。また、アクセスの多い Apache サーバでは、アクセスログのようなログファイルはすぐに大きくなります。そのため、古いログファイルを定期的に移動したり削除したりするためのプロセスを用意しておくことが重要です。幸いなことに、Apache HTTP サーバには、 graceful restartとパイプ経由のログを使用することでこれを行う機能があります。 Apache サーバのgraceful restartは、クライアント接続を失うことなく再起動することができます。この再起動により、Apache はクライアントを中断することなく新しいログファイルを開いたり書いたりすることができるようになり、スペースを節約するために古いログファイルを圧縮したり削除したりする処理を実行できるようになります。一方、パイプ経由のログ処理では、サーバの再起動なしにログのローテーションを行うことができます。例えば、Apache HTTP サーバには rotatelogs というプログラムが含まれています。rotatelogs プログラムには、時間やサイズに基づいて条件付きでログをローテートさせるオプションが含まれています。
Sumo Logic による Apache アクセスログの分析
ログファイルに大量のデータを収集することは、データを効果的に管理し、簡単に分析できる場合にのみ有用です。適切に行われた場合、Webサーバの設定やアプリケーションの改善の機会を特定するために活用できる貴重な洞察が得られます。Apacheのアクセスログを扱う際には、Sumo Logicと統合してApacheのログファイルを収集するのがベストです。開始のプロセスは比較的簡単です。実際、SumoLogicコレクターとApacheアクセスログ用のローカルファイルソースを設定するだけで、数分で基本的な使い方ができるようになります。Sumo Logic がログ管理とデータ分析のプロセスをどのように改善できるか、今すぐチェックしてみてください。

Scott Fitzpatrick
Scott FitzpatrickはFixate IOのコントリビューターで、8年近いソフトウェア開発経験を持っています。Java、ColdFusion、HTML/CSS、JavaScript、SQLを含む多くの言語やフレームワークの仕事をしてきています。" target="_blank">

マルチクラウドセキュリティの神話 by Sumo Logic

On 2019年11月26日

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

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

Page 1 of 212

Dockerコンテナ

Docker Engine

DockerはDevOps環境にどのように貢献するか

Dockerコンテナ

Docker Engine

DockerはDevOps環境にどのように貢献するか

SaaS

SaaSとは​

提供方法​

SaaSのメリット

SaaSの特徴

SaaSを利用する理由

制限事項と懸念事項

Sumo LogicとSaaSベンダー

SaaSの例

PaaS

PaaSとは

提供方法

PaaSのメリット

PaaSの特徴

PaaSを利用する理由

制限と懸念事項

PaaSの例

Sumo LogicとPaaSベンダー

IaaS

IaaSとは

IaaSの提供方法

IaaSのメリット

IaaSの特徴

IaaSを利用する理由

制限と懸念事項

IaaSの例

Sumo LogicとIaaSベンダー

どこで、どのように

Windows

プラットフォーム固有のUNIX/Linux

一般的な UNIX/Linux

エラーログ

一般的なクエリログと低速クエリログ

バイナリ、リレー、DDLログ

すべてをまとめる

Michael Churchman

Apache のアクセスログはどこにある？

Apache のアクセスログの解釈

Apache のアクセスログを読む

Common Log Format（共通ログフォーマット）

Combined Log Format（複合ログフォーマット）

CustomLog' ディレクティブ

複数のアクセスログ

条件付きログ

ログローテーションとパイプ経由のログ

Sumo Logic による Apache アクセスログの分析

Scott Fitzpatrick

神話2：マルチクラウドは堅牢なセキュリティを必要としない

神話3：そのクラウド専用のセキュリティツールを使用する必要がある

マルチクラウドアーキテクチャを保護する方法：可視性と統合

DevSecOpsの完全な可視性

カテゴリー

スポットライト

SaaSとは

提供方法