ログを知る〜IISとApache、NGINXのログ

  • On 2019年10月16日
カテゴリー DevOpsとIT運用 スポットライト DevSecOpsの完全な可視性 IoTボットネットの脅威を軽減するためのセキュリティ戦略 AWS CloudTrailログを読み取り、検索、分析する方法 今日のWebサーバエコシステムには、インターネットインフォメーションサービス（IIS）、Apache、NGINXの3つの大きなプレーヤーがいます。そのうち2つ（Apacheと割合は低いがNGINX）だけがクロスプラットフォームですが、どれもサポートすることを求められる可能性があるので、これらの3つのサーバすべてと連携できることがますます重要になります。 そのため、IIS、Apache、NGINXログの微妙な違いを理解することが重要です。完璧な世界では、これらのサーバはすべて同じログ形式とログデータを持ちますが、実際にはそうではありません。 この記事では、IIS、Apache、NGINXのログの違いと、DevOpsエンジニアが各サーバのログを操作するために知る必要がある重要な情報について説明します。 IIS、Apache、NGINX、の歴史とログ IISとApacheの戦いは20年間続いています。最初は、人々はしっかりと一方の側にいて、それは会社がWindowsのみであるか、UNIX／Linuxシステムが利用可能かによってしばしば決定されました。これらのシステムには、Webサイトにサービスを提供できることを除いて、共通点はありません。ログファイルは、実行されたオペレーティングシステムと同じくらい異なっていました。時が経ち2000年代になると、仮想化とLinuxが主流になってきたため、組織は一般的にApache HTTPとIISの両方のインストールを行いました。 同じ時期に、NGINXはApache HTTPの直接の競争相手になりました。NGINXは、Apache HTTPを凌ぐように設計されましたが、既存のログ管理ソリューションを再利用して、管理者がApacheからNGINXに簡単に移行できるようなログ形式を使用することで、Apache周りに構築されたエコシステムを活用しました。 Apache、NGINX、IISのログはどこに？ IIS IISでWindows 2008とVistaでリリースされたバージョン7でログファイルのデフォルトの場所が変更されました。IIS 6以前はログは％SystemRoot％System32LogFilesの下にありましたが、IIS 7では％SystemDrive％inetpublogs LogFilesに移動しました。 LogFilesディレクトリ内には、IISマネージャー管理コンソールでセットアップされたすべてのWebサイトやアプリケーション用に作成されたフォルダがあります。 デフォルトのサーバログフォルダはW3SVC1です。追加のフォルダは「1」をより長い乱数に置き換えます。デフォルトでは、「formatDDMMYY.log」というファイル名でNCSA、Extended、あるいはIISのフォーマットで新しいアクセスログファイルが毎日作成されます。LogFilesディレクトリ内には、IISマネージャー管理コンソールでセットアップされたすべてのWebサイトまたはアプリケーション用に作成されたフォルダーがあります。 下はWebサイトとログフォルダとファイルの例です。 Apache HTTP Apache HTTPのログはパッケージからインストールされた場合、UNIXやLinuxベースのサーバでは/var/log以下にあります。Windowsでは、ソースからコンパイルする場合、設定ファイルやバイナリと同じディレクトリの下にあります。 *デフォルトのファイル名はaccess_logおよびerror_logですが、例外もあります。 ほとんどのディストリビューションのパッケージ版Apache HTTPを使用する場合、ファイルは/var/log/httpdにあります。デフォルト設定を使用してソースからコンパイルする場合、ログファイルは$PREFIX/logsにあります。$PREFIXはコンパイル中に設定でき、デフォルトの場所は/usr/local/apache2です。 NGINX NGINXはApacheよりも一貫性が高く、すべてのディストリビューションで、/var/log/nginxのベースディレクトリにerror.logとaccess.logのファイル名を使用するパッケージを使用しています。 ソースからコンパイルする場合、またはWindows上で実行する場合、デフォルトの場所はベースインストールディレクトリの下のログディレクトリで、ファイル名はaccess_logとerror_logです。 IISアクセスロギング 前述のように、IISにはログファイルを保存できる複数の形式があります。そのうちの1つは、データベースにも書き込むことができるバイナリ形式ですが、ログのインフラが複雑になるので理想的とはいえません。 テキストベースの形式では、W3C拡張、IIS、NCSAという3つのオプションがあります。 W3C拡張形式は、日付ではなく時刻のみを持つため、デフォルトのDailyのように、実際には時間ベースのファイルローテーションでのみ機能します。 IIS形式は、3つの形式の中で最も情報が多く、時間ベースやサイズベースなど、複数の種類のファイルローテーションをサポートしています。 NCSAはApache HTTP、NGINXや他のいくつかのWebサーバで使用される形式です。他の2つのテキストオプションと比較して、データのバランスが良い構文を持っています。 Apache対NGINXアクセスロギング ApacheとNGINXは両方とも、デフォルトでNCSAフォーマットのアクセスロギングを使用します。 ApacheとNGINXの両方には、アクセスログのデータをカスタマイズして、情報を増やしたり減らしたりする機能があります。一般的に使用されるこの形式は、コンバインドと呼ばれます。 コンバインドは、HTTP_RefererとUser_Agentと呼ばれる2つのデータフィールドが追加されたNCSAフォーマットに基づいています。この2つのフィールドは、ログをWeb分析やキャンペーントラッキングなどのマーケティング活動の基盤として使用する場合に非常に役立ちます。ただし、ほとんどの組織は、マーケティング活動のためにより堅牢なJavaScriptベースの追跡ソリューション（Googleアナリティクスなど）に移行したため、コンバインドは使用しなくなりました。 エラーログ IISとNGINXとApacheのエラーログは、日付、時刻、エラーコード（利用可能な場合）とstderrの出力の形式で、いたって分かりやすくなっています。エラーはファイル内の複数の行にまたがることができるため、ログを正しく理解して処理できる適切なログ収集エンジン（Sumo Logicなど）を用意すると役立ちます。 結論 IIS、Apache、NGINXのログは多くの点で異なります。幸いなことに、Sumo Logicのような最新のログ統合サービスを活用することで、アクティビティの追跡と問題解決の両方について、すべてのプラットフォームで統一されたビューを簡単に取得できます。さらに、アクセスログにNCSAフォーマットを使用するようにIISを構成できることにより、これらの集中ログリポジトリの検索と特定のデータのマイニングが可能になり、ログ統合ツールを使用した日常作業が可能になります。 ヴィンス・パワー Vince Powerはソリューションアーキテクトであり、クラウドの採用とオープンソースベースのテクノロジーの実装にフォーカスしています。彼は、コアコンピューティングとネットワーク（IaaS）、アイデンティティとアクセス管理（IAM）、アプリケーションプラットフォーム（PaaS）、継続的デリバリーなどの幅広い経験を持っています。
Read More
  • カテゴリー

    スポットライト

    今日のWebサーバエコシステムには、インターネットインフォメーションサービス（IIS）、Apache、NGINXの3つの大きなプレーヤーがいます。そのうち2つ（Apacheと割合は低いがNGINX）だけがクロスプラットフォームですが、どれもサポートすることを求められる可能性があるので、これらの3つのサーバすべてと連携できることがますます重要になります。 そのため、IIS、Apache、NGINXログの微妙な違いを理解することが重要です。完璧な世界では、これらのサーバはすべて同じログ形式とログデータを持ちますが、実際にはそうではありません。 この記事では、IIS、Apache、NGINXのログの違いと、DevOpsエンジニアが各サーバのログを操作するために知る必要がある重要な情報について説明します。

    IIS、Apache、NGINX、の歴史とログ

    IISとApacheの戦いは20年間続いています。最初は、人々はしっかりと一方の側にいて、それは会社がWindowsのみであるか、UNIX／Linuxシステムが利用可能かによってしばしば決定されました。これらのシステムには、Webサイトにサービスを提供できることを除いて、共通点はありません。ログファイルは、実行されたオペレーティングシステムと同じくらい異なっていました。時が経ち2000年代になると、仮想化とLinuxが主流になってきたため、組織は一般的にApache HTTPとIISの両方のインストールを行いました。 同じ時期に、NGINXはApache HTTPの直接の競争相手になりました。NGINXは、Apache HTTPを凌ぐように設計されましたが、既存のログ管理ソリューションを再利用して、管理者がApacheからNGINXに簡単に移行できるようなログ形式を使用することで、Apache周りに構築されたエコシステムを活用しました。

    Apache、NGINX、IISのログはどこに？ IIS

    IISでWindows 2008とVistaでリリースされたバージョン7でログファイルのデフォルトの場所が変更されました。IIS 6以前はログは％SystemRoot％System32LogFilesの下にありましたが、IIS 7では％SystemDrive％inetpublogs LogFilesに移動しました。 know-your-logs LogFilesディレクトリ内には、IISマネージャー管理コンソールでセットアップされたすべてのWebサイトやアプリケーション用に作成されたフォルダがあります。 デフォルトのサーバログフォルダはW3SVC1です。追加のフォルダは「1」をより長い乱数に置き換えます。デフォルトでは、「formatDDMMYY.log」というファイル名でNCSA、Extended、あるいはIISのフォーマットで新しいアクセスログファイルが毎日作成されます。LogFilesディレクトリ内には、IISマネージャー管理コンソールでセットアップされたすべてのWebサイトまたはアプリケーション用に作成されたフォルダーがあります。 下はWebサイトとログフォルダとファイルの例です。 Crazy-Cousins

    Apache HTTP

    Apache HTTPのログはパッケージからインストールされた場合、UNIXやLinuxベースのサーバでは/var/log以下にあります。Windowsでは、ソースからコンパイルする場合、設定ファイルやバイナリと同じディレクトリの下にあります。 *デフォルトのファイル名はaccess_logおよびerror_logですが、例外もあります。 know-your-logs know-your-logs ほとんどのディストリビューションのパッケージ版Apache HTTPを使用する場合、ファイルは/var/log/httpdにあります。デフォルト設定を使用してソースからコンパイルする場合、ログファイルは$PREFIX/logsにあります。$PREFIXはコンパイル中に設定でき、デフォルトの場所は/usr/local/apache2です。

    NGINX

    NGINXはApacheよりも一貫性が高く、すべてのディストリビューションで、/var/log/nginxのベースディレクトリにerror.logとaccess.logのファイル名を使用するパッケージを使用しています。 ソースからコンパイルする場合、またはWindows上で実行する場合、デフォルトの場所はベースインストールディレクトリの下のログディレクトリで、ファイル名はaccess_logとerror_logです。

    IISアクセスロギング

    前述のように、IISにはログファイルを保存できる複数の形式があります。そのうちの1つは、データベースにも書き込むことができるバイナリ形式ですが、ログのインフラが複雑になるので理想的とはいえません。 テキストベースの形式では、W3C拡張、IIS、NCSAという3つのオプションがあります。 W3C拡張形式は、日付ではなく時刻のみを持つため、デフォルトのDailyのように、実際には時間ベースのファイルローテーションでのみ機能します。 know-your-logs IIS形式は、3つの形式の中で最も情報が多く、時間ベースやサイズベースなど、複数の種類のファイルローテーションをサポートしています。 know-your-logs NCSAはApache HTTP、NGINXや他のいくつかのWebサーバで使用される形式です。他の2つのテキストオプションと比較して、データのバランスが良い構文を持っています。 know-your-logs

    Apache対NGINXアクセスロギング

    ApacheとNGINXは両方とも、デフォルトでNCSAフォーマットのアクセスロギングを使用します。 ApacheとNGINXの両方には、アクセスログのデータをカスタマイズして、情報を増やしたり減らしたりする機能があります。一般的に使用されるこの形式は、コンバインドと呼ばれます。 コンバインドは、HTTP_RefererとUser_Agentと呼ばれる2つのデータフィールドが追加されたNCSAフォーマットに基づいています。この2つのフィールドは、ログをWeb分析やキャンペーントラッキングなどのマーケティング活動の基盤として使用する場合に非常に役立ちます。ただし、ほとんどの組織は、マーケティング活動のためにより堅牢なJavaScriptベースの追跡ソリューション（Googleアナリティクスなど）に移行したため、コンバインドは使用しなくなりました。

    エラーログ

    IISとNGINXとApacheのエラーログは、日付、時刻、エラーコード（利用可能な場合）とstderrの出力の形式で、いたって分かりやすくなっています。エラーはファイル内の複数の行にまたがることができるため、ログを正しく理解して処理できる適切なログ収集エンジン（Sumo Logicなど）を用意すると役立ちます。

    結論

    IIS、Apache、NGINXのログは多くの点で異なります。幸いなことに、Sumo Logicのような最新のログ統合サービスを活用することで、アクティビティの追跡と問題解決の両方について、すべてのプラットフォームで統一されたビューを簡単に取得できます。さらに、アクセスログにNCSAフォーマットを使用するようにIISを構成できることにより、これらの集中ログリポジトリの検索と特定のデータのマイニングが可能になり、ログ統合ツールを使用した日常作業が可能になります。 vince-power

    ヴィンス・パワー

    Vince Powerはソリューションアーキテクトであり、クラウドの採用とオープンソースベースのテクノロジーの実装にフォーカスしています。彼は、コアコンピューティングとネットワーク（IaaS）、アイデンティティとアクセス管理（IAM）、アプリケーションプラットフォーム（PaaS）、継続的デリバリーなどの幅広い経験を持っています。" target="_blank">

Sumo Logicでsyslogデータを監視する方法

  • On 2019年9月27日
カテゴリー DevOpsとIT運用 スポットライト 継続的インテリジェンスレポート この記事を読んでいる方は、おそらく1980年代から使用されているロギングツールであるsyslogに精通していることでしょう。ほとんどのLinuxベースのオペレーティングシステムに存在するデーモンです。 デフォルトでは、Linuxシステムのsyslog（およびrsyslogなどの派生アプリ）を使用して、ログをsyslogサーバや監視プラットフォームに転送して、さらに分析を行うことができます。これは便利ですが、syslogを最大限に活用するには、ログデータを分析できるようにする必要もあります。 そこで、ここではローカルのシステムログを取得し、Sumo Logicコレクターを使用してSumo Logicに転送するプロセスを説明します。 また、syslogやrsyslogデーモンを使用して、サーバからログを送信する方法も示します。 はじめに ログをSumo Logicにストリーミングできるようにするには、まずパッケージにサインアップする必要があります。有料のオプションもありますが、Sumo Logicのテストとして、ストリーミングするログの量を少なくし、1日最大500Mバイトまでならば無料で使えるオプションがあります。サインアップすると、次のようなページが表示され、ログファイルをアップロードするか、ストリーミングログにすぐにジャンプするかを選択します。ここでは後者のオプションを選択します。 ストリーミングログ 「Set Up Streaming Data」ボタンをクリックすると、Linux、Windows、あるいはMacからAWS環境をすぐに開始できるオプションが表示されます。 コレクターのインストール 今回はLinuxを選択します。これにより、次のような簡単なコマンドでSumo Logicコレクターをデプロイできます。 sudo wget “https://collectors.de.sumologic.com/rest/download/linux/64” -O SumoCollector.sh && sudo chmod + x SumoCollector.sh && sudo ./SumoCollector.sh -q -Vsumo.token_and_url=<unique_token> コマンドを実行すると、コレクターがインストールされ、Sumo Logicに自動的に登録されます。この時点で、「Continue」をクリックできるようになります。 ソースの構成 次に、データのソース情報を設定します。まず、ソースカテゴリーを設定します。これは、収集時に各メトリックの時系列に追加されるメタデータタグです。希望する任意の名前を設定できます。これを使用して、将来このソースからのメトリックを見つけることができます。 プロセスのこの時点で、データを収集するログファイルを設定することもできます。デフォルトでは、/var/log/secure*と/var/log/messages*がスクレイピング用に選択されています。もちろん、収集したい他のログファイルを追加できます。例えば、実行中にアプリが生成するログファイルです。 最後に、ログファイルのタイムゾーンを使用するか、無視して別のタイムゾーンを使用するかを選択できます。これで、「Continue」をクリックする準備ができました。ログのサイズが大きい場合には、Collectorが設定とデータを追加する間にコーヒーが1杯飲めるかもしれません。 完了すると次のように表示されます。 ログを検索する では、楽しい作業に移りましょう。ログを表示して、情報を検索します。「Linux System」という名前のページの上部にあるサンプル検索オプションを使用すると、サーバからストリーミングされたログを表示できます。「sumologic」という名前のログも含めるように検索クエリを修正しました。これがその結果です。 ホスト名、データ取得元のログファイル名、セットアップ中に設定した「linux/system」というカテゴリーが表示されます。 また、ログイン時に一般的な情報を表示できる便利なダッシュボードもあります。もちろん、ログの情報に基づいてこれを変更し、新しいグラフを追加できます。これは、アプリケーションのHTTPエラーの詳細など、さまざまな機能に使用できます。たとえばメールサーバならば、バウンスや拒否されたメールの数を表示できます。 Syslogソースの追加 Syslogソースを追加するには、Sumo Logicコントロールパネルで新しいソースを設定します。これを行うには、「Manage Data」→「Collection」→「Collection」に移動します。次に、「Add」→「Add Source」→「Syslog」をクリックします。ここでは、プロトコル（TCPまたはUDP）とポート番号とともにsyslog名を指定します。この記事では、ポート1514でUDPを選択しました。linux/syslogのソースカテゴリーを使用することにしました。ここで「Save」をクリックします。コレクターがサーバのUDPポート1514をリッスンしているサービスが表示されます。 この時点で、コレクターの新しいリスナーにログを送信するようsyslogを設定する準備が整いました。設定にはsyslogまたはrsyslogの設定ファイルを編集します。この場合、後者は/etc/rsyslog.confです。このログファイルの最後に、コメントアウトされた行があります。 # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @@remote-host:514 # ### end of the forwarding rule ###   この行のコメントを外し、IPアドレスとポートを変更して、rsyslogが保持するすべてのログ（*.*）を新しいリスナーに送信します。 # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional *.* @127.0.0.1:1514 # ### end of the forwarding rule ###   ログ送信にTCPではなくUDPを使用するようにrsyslogに指示する「@」をIPアドレスの先頭に付加してください。 コレクターに対してこのメ​​ソッドを単独で使用する理由 ここで説明したアプローチを採用する理由は次の通りです。 組織内の中央syslogサーバにコレクターをセットアップし、すべてのログをSumo Logicに転送することができます。このアプローチの利点は、すべてのサーバに個別にコレクターをインストールする必要がないため、非常に多くのソースからのトラフィックを許可するために企業のファイアウォールを開ける必要がないことです。 結論 Sumo Logicは、大規模な組織に存在する可能性のある制限を回避するために、リスナーを独自の環境に拡張できる包括的なクラウドソリューションを提供します。これにインターフェイス、合理化されたセットアッププロセス、ダッシュボードを組み合わせることで、非常に競争力のあるソリューションとなり、ログを積極的に監視し、お客様に影響を与える前に問題を発見できます。 キース・ロジャース キース・ロジャースは、10年以上の経験を持つITプロフェッショナルで、現在は英国の大手放送会社で働いています。彼の長年にわたるコンピューティングへの情熱は、いくつもの業務外の活動をうながし、彼の知識を深め関心を高めることにつながりました。 キースは長年Linux上でApache、MySQL、PHPを使用して完全なWebスタックを構築し、高可用性に適したより複雑な負荷分散と冗長ソリューションを作成してきました。過去2、3年、彼はAWSやAzureが提供する新しいクラウドベースのインフラストラクチャを使用して、同様の目標を達成しています。
Read More
  • カテゴリー

    スポットライト

    • 継続的インテリジェンスレポート

    この記事を読んでいる方は、おそらく1980年代から使用されているロギングツールであるsyslogに精通していることでしょう。ほとんどのLinuxベースのオペレーティングシステムに存在するデーモンです。

    デフォルトでは、Linuxシステムのsyslog（およびrsyslogなどの派生アプリ）を使用して、ログをsyslogサーバや監視プラットフォームに転送して、さらに分析を行うことができます。これは便利ですが、syslogを最大限に活用するには、ログデータを分析できるようにする必要もあります。

    そこで、ここではローカルのシステムログを取得し、Sumo Logicコレクターを使用してSumo Logicに転送するプロセスを説明します。

    また、syslogやrsyslogデーモンを使用して、サーバからログを送信する方法も示します。

    はじめに

    ログをSumo Logicにストリーミングできるようにするには、まずパッケージにサインアップする必要があります。有料のオプションもありますが、Sumo Logicのテストとして、ストリーミングするログの量を少なくし、1日最大500Mバイトまでならば無料で使えるオプションがあります。サインアップすると、次のようなページが表示され、ログファイルをアップロードするか、ストリーミングログにすぐにジャンプするかを選択します。ここでは後者のオプションを選択します。

    image1

    ストリーミングログ

    「Set Up Streaming Data」ボタンをクリックすると、Linux、Windows、あるいはMacからAWS環境をすぐに開始できるオプションが表示されます。

    コレクターのインストール

    今回はLinuxを選択します。これにより、次のような簡単なコマンドでSumo Logicコレクターをデプロイできます。

    sudo wget 'https://collectors.de.sumologic.com/rest/download/linux/64' -O SumoCollector.sh && sudo chmod + x SumoCollector.sh && sudo ./SumoCollector.sh -q -Vsumo.token_and_url=<unique_token>

    コマンドを実行すると、コレクターがインストールされ、Sumo Logicに自動的に登録されます。この時点で、「Continue」をクリックできるようになります。

    ソースの構成

    次に、データのソース情報を設定します。まず、ソースカテゴリーを設定します。これは、収集時に各メトリックの時系列に追加されるメタデータタグです。希望する任意の名前を設定できます。これを使用して、将来このソースからのメトリックを見つけることができます。

    プロセスのこの時点で、データを収集するログファイルを設定することもできます。デフォルトでは、/var/log/secure*と/var/log/messages*がスクレイピング用に選択されています。もちろん、収集したい他のログファイルを追加できます。例えば、実行中にアプリが生成するログファイルです。

    最後に、ログファイルのタイムゾーンを使用するか、無視して別のタイムゾーンを使用するかを選択できます。これで、「Continue」をクリックする準備ができました。ログのサイズが大きい場合には、Collectorが設定とデータを追加する間にコーヒーが1杯飲めるかもしれません。

    完了すると次のように表示されます。

    image3

    ログを検索する

    では、楽しい作業に移りましょう。ログを表示して、情報を検索します。「Linux System」という名前のページの上部にあるサンプル検索オプションを使用すると、サーバからストリーミングされたログを表示できます。「sumologic」という名前のログも含めるように検索クエリを修正しました。これがその結果です。

    ホスト名、データ取得元のログファイル名、セットアップ中に設定した「linux/system」というカテゴリーが表示されます。

    また、ログイン時に一般的な情報を表示できる便利なダッシュボードもあります。もちろん、ログの情報に基づいてこれを変更し、新しいグラフを追加できます。これは、アプリケーションのHTTPエラーの詳細など、さまざまな機能に使用できます。たとえばメールサーバならば、バウンスや拒否されたメールの数を表示できます。

    image2

    Syslogソースの追加

    Syslogソースを追加するには、Sumo Logicコントロールパネルで新しいソースを設定します。これを行うには、「Manage Data」→「Collection」→「Collection」に移動します。次に、「Add」→「Add Source」→「Syslog」をクリックします。ここでは、プロトコル（TCPまたはUDP）とポート番号とともにsyslog名を指定します。この記事では、ポート1514でUDPを選択しました。linux/syslogのソースカテゴリーを使用することにしました。ここで「Save」をクリックします。コレクターがサーバのUDPポート1514をリッスンしているサービスが表示されます。

    この時点で、コレクターの新しいリスナーにログを送信するようsyslogを設定する準備が整いました。設定にはsyslogまたはrsyslogの設定ファイルを編集します。この場合、後者は/etc/rsyslog.confです。このログファイルの最後に、コメントアウトされた行があります。

    # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional

    #*.* @@remote-host:514

    # ### end of the forwarding rule ###

     

    この行のコメントを外し、IPアドレスとポートを変更して、rsyslogが保持するすべてのログ（*.*）を新しいリスナーに送信します。

    # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional

    *.* @127.0.0.1:1514

    # ### end of the forwarding rule ###

     

    ログ送信にTCPではなくUDPを使用するようにrsyslogに指示する「@」をIPアドレスの先頭に付加してください。

    コレクターに対してこのメ​​ソッドを単独で使用する理由

    ここで説明したアプローチを採用する理由は次の通りです。

    組織内の中央syslogサーバにコレクターをセットアップし、すべてのログをSumo Logicに転送することができます。このアプローチの利点は、すべてのサーバに個別にコレクターをインストールする必要がないため、非常に多くのソースからのトラフィックを許可するために企業のファイアウォールを開ける必要がないことです。

    結論

    Sumo Logicは、大規模な組織に存在する可能性のある制限を回避するために、リスナーを独自の環境に拡張できる包括的なクラウドソリューションを提供します。これにインターフェイス、合理化されたセットアッププロセス、ダッシュボードを組み合わせることで、非常に競争力のあるソリューションとなり、ログを積極的に監視し、お客様に影響を与える前に問題を発見できます。

    image4

    キース・ロジャース

    キース・ロジャースは、10年以上の経験を持つITプロフェッショナルで、現在は英国の大手放送会社で働いています。彼の長年にわたるコンピューティングへの情熱は、いくつもの業務外の活動をうながし、彼の知識を深め関心を高めることにつながりました。

    キースは長年Linux上でApache、MySQL、PHPを使用して完全なWebスタックを構築し、高可用性に適したより複雑な負荷分散と冗長ソリューションを作成してきました。過去2、3年、彼はAWSやAzureが提供する新しいクラウドベースのインフラストラクチャを使用して、同様の目標を達成しています。

    " target="_blank">

サーバレスとコンテナ：同じところと違うところ

  • On 2019年9月25日
カテゴリー DevOpsとIT運用 スポットライト DevSecOpsの完全な可視性 コンテナとサーバレスコンピューティングは、今日のアプリケーションのデプロイで最もホットなテクノロジーです。正しい方法で使用すると、素早く費用対効果の高いデプロイができるようになります。 コンテナとサーバレスアーキテクチャの機能はいくつかの点で重複していますが、互換できる技術ではありません。コンテナは、ある用途ではより適切に機能しますが、別の用途ではサーバレスのほうが望ましいことがあります。 この記事では、コンテナとサーバレスコンピューティングサービスの類似点と相違点について説明し、DevOpsチームがニーズに応じていずれかのテクノロジーを選択する理由を説明します。 コンテナとは 簡単に言えば、コンテナは軽量の仮想化アーキテクチャです。これを使用すると、個別のアプリケーション（または場合によっては完全なオペレーティングシステム）を、移植可能な隔離された環境内に実装できます。 コンテナは、仮想オペレーティングシステムをエミュレートするのではなく、ホストサーバとシステムリソースを共有するため、仮想マシンよりも効率的です。 さらに、アプリケーションを外部ホスト環境から分離することにより、コンテナは摩擦のないアプリケーション展開を可能にします。ホストサーバがコンテナランタイムをサポートしていれば、コンテナ構成のアプリケーションをデプロイできます。アプリケーションの設定を調整したり、環境変数と格闘したりする必要はありません。同じ理由で、コンテナ化されたアプリケーションをホスト間で簡単に移動できます。 サーバレスとは​​何ですか？ サーバレスコンピューティングは、アプリケーションコードがオンデマンドで実行されるアーキテクチャです。ユーザーの観点から見ると、コードを実行するために必要な作業は、コードをアップロードして、実行したい時にトリガーすることだけです。維持すべきサーバがない、それがサーバレスと呼ばれる理由です。 サーバレスの主な利点は、ホスト環境を継続的に維持することなく、ユーザーが必要なときにいつでもコードを実行できることです。これは、特にリソースを大量に消費するコードを実行する必要がある場合に、料金を節約するのに役立ちます。 コンテナとサーバレスの類似点 コンテナとサーバレスは同一のテクノロジーではありません。ただし似た機能を提供します。 どちらもアプリケーションコードをデプロイできます どちらも仮想マシンよりも効率的です コンテナでもサーバレスでも、そのうえで動作するアプリケーションは、ホスト環境から隔離されています 両方とも効果的にスケールするにはオーケストレーションツールが必要です ​ サーバレスとコンテナの違い 以上の類似点以外では、サーバレスとコンテナは別個のテクノロジーです。 コンテナとサーバレスの主な違いは次のとおりです。 サポートされているホスト環境：コンテナは最新のLinuxサーバと特定のバージョンのWindowsで実行できます。対照的に、サーバレスは特定のホストプラットフォームで実行され、そのほとんどはパブリッククラウド（AWS LambdaやAzure Functionsなど）です セルフサービス能力：上記の理由により、ほとんどの場合、サーバレスを使うにはパブリッククラウドを使用する必要があります。（Fnのようなオンプレミスのサーバレスフレームワークがありますが、まだ広く利用されていません）コンテナでは、独自のオンプレミスホスト環境と、ECSなどのパブリッククラウドサービスの両方を使用できます コスト：サーバレス環境はクラウドにホストされているため、使用するには費用がかかります。対照的に、コンテナはオープンソースを使用して無料で自分でコンテナ環境を設定できます（もちろん管理コストはかかりますが） サポートされている言語：ホストサーバがサポートしていれば、任意の言語で記述されたアプリケーションをコンテナ化できます。サーバレスフレームワークは異なります。サポートする言語は限られています。サポートされるサーバレス言語は、サーバレスプラットフォームごとに異なります ステートフル：ほとんどのサーバレスプラットフォームは、ステートレスワークロードをサポートするように設計されています（一部のサーバレスプロバイダーは、限定的なステートフルサービスを提供しています。AzureのDurable Functionsを参照してください）。サーバレスプラットフォーム内から外部ストレージサービス（AWSのS3など）に接続できますが、機能自体はステートフルにできません。コンテナには永続的なストレージの課題がありますが、ステートフルなコンテナ化されたアプリの作成が可能です 可用性：サーバレス機能は、シャットダウンする前に短時間（通常は数百秒）実行するように設計されています。コンテナは、必要な限り実行できます   サーバレスとコンテナの用途 上記の違いにより、コンテナとサーバレスは異なる用途に向いています。 コンテナは、次のことが必要な状況に最適です。 アプリケーションコードがデリバリーチェーンを下るときに、環境パリティを維持する 異なるホストサーバ間でアプリケーションをすばやく移動する オンプレミスとクラウドの間でワークロードを移動する機能を保持する サービスを継続的に利用可能にする 一方、サーバレスは次の場合に最適です。 リソースを集中的に使用するコードを1回限り迅速に実行する。たとえば、ユーザーが画像をアップロードするたびに画像のサイズを変更するコードを実行するというような場合、サーバレスはそのための優れた方法です 仮想サーバをセットアップしたり、継続的にクラウドリソースに料金を支払うことなく、クラウドで限定的なアプリケーションコードを実行する 結論 コンテナ対サーバレスという観点から考えるよりも、コンテナとサーバレスを互いに補完するテクノロジーと考える方が良いでしょう。ほとんどの組織は、どちらか一方ではなく、コンテナとサーバレスの両方を使用する可能性があります。実際、両方のテクノロジーを使用して同じアプリケーションを提供することもできます。 コンテナ サーバレス ワークロードの分離 ○ ○ ステートフル機能／アプリか？ ○ ほとんどの場合× ホスト環境 クラウドまたはオンプレミス ほとんどクラウド コスト 自分で用意すれば無料 クラウド料金が発生 サポートする言語 実質的に全て 限定的 永続的なサービス ○ × https://www.sumologic.com/blog/serverless-vs-containers/ カリアン・ラマナサン Kalyanはソフトウェアおよびマーケティングで20年以上の経験を持ち、IT運用とマーケット管理について深く理解しています。 Sumo Logicの前は、AppDynamicsの製品マーケティング担当副社長でした。また、CrittercismのCMO、Electric Cloudのマーケティング担当副社長、Opsware／HPの製品マーケティングのシニアディレクターも務めました。 KalyanはIntelでキャリアをスタートし、スタンフォードビジネススクールのMBAを取得しています。
Read More