CLOSE

AWSのログをGCPに出力してみた話(全1記事)

AWSのログ分析をGoogle Cloud Platformで フォージビジョンのエンジニアが教えるマルチクラウドでログを取る方法

ログ分析勉強会では、「ログ分析」に関わるすべての技術、事例、知見を共有し、日々の業務に役立てられる情報交換ができる場所を目的として活動。初のオンライン開催となった今回、フォージビジョンの小林賢司氏が、複数のクラウドを組み合わせて使うマルチクラウドでのログの取り方、また実際にやった感触、GCPがもつログ収集のいいところなどを紹介しました。

前回の発表について

小林賢司氏:私のほうからは、『AWSのログをGCPに出力してみた話』ということを20分程度話させてもらえればと思っています。

まず自己紹介します。私、小林賢司と申します。ログ分析勉強会の運営をやっています。フォージビジョン株式会社のクラウドインテグレーション事業部というところで、カスタマーエンジニアという役職で仕事をしています。主にAWSを触ったりとか、たまにログ系を触ったりとかしています。

弊社としてAWSのProの資格をもっていますので、今回はGCPのお話にはなるんですけれども、AWSとGCPというところでお話できたらなと考えています。

好きなものと苦手なものは以下のとおりです。ログ分析してる人で正規表現苦手というのは、ちょっとなんとも言いづらいんですけど、あんまり得意ではないというのは、ここでお伝えしておこうかなと思います。

初めてのオンライン開催なんですけれども、#logbenでたくさんツイートいただけると助かります。

前回のオフライン勉強会では、入門のところで『これからはじめるログ分析』として、そもそもなんでログ分析するの? という感じのお話をしています。スライドシェアで公開しているので、これから始めようと思っている方とか、そもそもどんな分析をすればいいのか? そもそも何をすればいいの? みたいなところから迷っている方がいれば、ぜひ見ていただければと思っています。

今日の内容

今日お話することは、スライドのとおりです。なぜAWSのログをGCPに? というところ。今回なにも考えずに試してみて、こういう構成だったらいけるんじゃねぇの? というところをちょっと思ってみた構成。そしてAWSのログを収集するときはどうすればいいのか?というところを紹介していきたいと思います。

私GCPって、ほとんどというか、触ったことなかったんですけれども、GCPのCloud Loggingというサービスだったり、BigQueryというサービスがあるので、そちらの紹介。最後にまとめさせてもらえればなと思っています。

AWSのログをGCPにもっていくことになったきっかけ

ではさっそく始めたいと思います。なぜAWSのログをGCPに? というところからです。もともと私、ログ分析を5、6年やってきてまして、その中でもともとオンプレのログをずっとやってきました。

やはりログ分析をするうえで、私自身が、ログ分析のツールというのをよく使っていたんですね。よく使っていたものとしては、SplunkであったりElasticsearchであったり。最近ですと、Sumo Logicみたいなものを使っていたりします。

そうした中で、前回私は「ログ分析はクラウドで!」というふうに言いました。そこでやはりAWSだけではなくて、そのほかのクラウドサービスのログ分析のツールであったりサービスというものを知らないといけないなというふうに感じました。その一環として今回、AWSのログをGCPに取り込んでみました。

マルチクラウドのログ分析は難しい

世の中のシステムというのは、単一のクラウド構成とは限らないのかなと思っています。やはりマルチクラウドの環境でのログ分析というのは、通常1つのプラットフォームからするとやっぱり難しいと思います。

なぜかと言いますと、各クラウド間のデータの連携が本当にできるのか? 連携のために実装が必要なのか? 実は別の仕組みを使わないとデータが取り込めないのか? とか。サービスが分かれてしまうと、こうした課題があるかと思います。今回はAWSとGCPの一例というところなので、ぜひご興味ある方は見ていただければと思っています。

今回は時間の関係もあるんですけれども、ログを収集するためだけに、例えばAWSで言うとLambdaを使ってS3のログを転送したりとかというのは、一切考えていません。あくまでAWS、GCPで提供されているものだけで簡単かつすばやくデータを収集できる方法を選択しています。

ですから今回ご紹介する方法は、AWSからGCPへデータを転送する方法として、この限りではないというところだけご了承いただければと思っています。

AWSのログをGCPに入れる仕組み

今回試してみた構成です。単純にAWSにWebサーバーを立てて、そのログをGCPに投げてみたら簡単にいけるんじゃないかなとちょっと思ってみました。

ただGCPを触ったことがない中でいろいろ調べていくと、実際はこんな感じの構成でした。

AWSとGCPとを連携するところで言うと、AWSコネクタプロジェクトというものが必要でした。それを図に表してみると、こういった構成になります。AWSのほうですとWebサーバーがあって、それからAWSコネクター。これはGCP側で用意されているAWSを連携するための機能と思っていただければと思います。

AWSのログを収集するにはどういった手順でやっていくかと言いますと、別のAWSアカウントを使ってIAMロールを作成します。先ほどGCP上にAWSがあるように見えたかと思うんですけれども、このときなんですが、GCPが用意しているAWSアカウントがありまして、そちらのAWSアカウントを認証して、あくまでもGCPにあるAWSのコネクターを経由してデータを収集するような仕組みになっているそうです。

その設定をしたあと、GCP側のAWSコネクタプロジェクトを作成してAWSとも連携をすると、AWSで言うところのCloudWatch LogsであったりCloudWatchのようなメトリクスの情報というのが簡単に取得できるようになります。

こちらはGCPの画面です。AWSアカウントと連携すると、こちらのようにどのAWSアカウントとリンクしたのかがわかるようになっています。

ロギングの転送

これだけだとどちらかというとモニタリング、メトリクスの情報になってしまいます。ロギングの部分も取得したいなと思いましたので、今回はAWS上のインスタンスにCloud Loggingのエージェントをインストールしてみました。インストールすることによって、EC2上のログを収集できます。

Cloud Loggingとは何かと言いますと、これおもしろいんですけれども、GCP、AWS、2つのクラウドからログデータとイベントを保存して検索して分析、監視、通知というのが簡単にできるサービスです。

そのほかにもBindPlaneというSaaSのサービスを利用することで、150種類以上のアプリケーションからデータ収集できる。なのでGCP、AWSに限らず、そのほかのSaaSのサービスとか、あるいはオンプレからデータの収集ができるというサービスになっています。

ロギング以外にメトリクスの分析には、Cloud Monitoringというサービスがあります。ロギングの中ではデフォルトでsyslogであったりapache、nginx、tomcat、mysql、あとpostgresqlなどですね。基本的なミドルウェアのログデータについては自動的に収集される。

これはCloudWatch LogsでもCloudWatch Agentも同じような仕組みかと思うんですけれども、GCP側のロギングも同じような仕組みになっているのかなと思いました。AWSで言うとCloudWatch Logs InsightとCloudWatch Logsみたいなサービスなのかなと思っています。

GCPのCloud Loggingでログ収集・分析する

Cloud Loggingでログ収集と分析をしているところです。Cloud Loggingというサービスの画面です。今回GCPを触られている方、AWSを触られている方、Azureを触られている方、その他のクラウドを触られている方、どれくらいいるのかが全然わからないんですけれども、私は正直初めてこのサービスを使ってみたんですけれども、AWSのCloudWatch Logs Insightに近しいものなのかなと感じました。

今出しているログはEC2です。AWSのログを今GCP上で表示しています。対象のインスタンスのsyslogであったりapacheのログを出力しているかたちになっています。

これもCloudWatch Logs Insightっぽいんですけども、実行画面の検索フィールドに検索クエリを入れていただくと、簡単に検索できる。例えばステータスコード200を検索すると、ステータスコード200のデータだけが抽出できます。

簡単ですね。AWSとGCPを連携してエージェントを入れただけで、簡単にAWSとGCPとログも分析対象になるというものになっています。

それから検索クエリ。以下のような感じでありますので、そこまで難しくないものになるのかなと思っています。

CloudWatch Logs Insightのメリット・デメリット

使ってみた感じではCloudWatch Logs Insightに似ているという感想ではあったんですけども、CloudWatch Logs Insightに関しては、データの集計だったりもできたと思います。ちょっと私の調べた限りだとCloud Loggingのサービスに関しては、データの集計というのがあまり得意じゃなさそうだなというふうに感じました。

ただしGCP以外のログも取り込めるという点では、統合ログ管理ツールとして使う価値はあるのかなというふうに感じました。なので、集計はできないので障害発生時に調査する場合に利用できるのかなと思いました。

Cloud Loggingサービスを使うと、データのアウトプットもできます。JSON形式やCSV形式で出力できます。

それからBigQuery、たぶん今回聞いてる方はみなさん知ってると思うんですけれども……。実は私、初めて使うものなんですが、BigQueryへも連携ができるということになっています。

Cloud Monitoring

あともう1つ、Cloud Monitoringもすごいなというふうに感じました。今回GCP上にAWSのインスタンスの情報を送っていたんですけれども、本当にCloudWatchと一緒な感じでEC2上のメトリクス情報を取得できます。パブリッククラウドで利用するケースでも、GCPのCloud Monitoringというのは使えるのかなというふうに感じました。

もちろんアラートとかも作成できるので、閾値設定して条件設定して通知させたりとかというのもできるようになっています。

BigQueryならニアリアルタイムで検索できる

BigQueryで分析してみようというところです。ロギングの部分は先ほどロギングとモニタリングというところでご説明したので、ログ情報をもとにBigQueryを使って分析したらどうなるのかというところをご紹介していきたいと思います。

最初にBigQueryとは? というところです。フルマネージドなビッグデータ分析サービスっていう、すごくざっくりしすぎちゃってるので何言ってるかよくわからないんですけれども……。

もともとはデータウェアハウス向けに作られたようなサービスだそうです。もともとGoogleの中で使われていたサービスを一般公開しているようなサービスだとお聞きしました。

いろいろ使ってみて感じたんですけれども、データウェアハウスというわりにはけっこうニアリアルタイム。EC2のログもすぐリアルタイムで取り込まれているように感じましたので、トランザクションがあったりとかアクセスがあるサイトであったりとか、たくさんログが出力されるサイトとかでも、ニアリアルタイムで使えるのであれば分析する用途としても十分使えるのかなと思いました。

AWSではどういうサービスと対抗するかと言うと、Amazon Redshiftが一番よく言われますが、ちょっと僕の使ってみた感じだと、似ている部分はあるけどちょっと違うなっていうのはありましたね。

どちらかというとRedshiftってバッチ処理のイメージが高いんですけれども、BigQueryに関しては、バッチ処理以外にもニアリアルタイムで検索するというのがイメージとしてあるなと感じました。

Cloud LogginからBigQueryへの移行

ではCloud LoggingからBigQueryへどうやって移行するか。データを転送するかというところです。こちらもすごく簡単でして、シンクを作成する。Cloud Loggingの画面にはシンクの作成というものがありまして、どのデータサービスに対してシンクをするかというものになっています。

BigQueryを選んでシンクのエクスポート先……データセットですね。データセットを任意の名前で設定すると、簡単にBigQuery側にCloud Loggingで取得したログデータを反映できるようになっています。

この画面がBigQueryの画面です。赤いところに先ほど作ったデータセットが表示されて、Cloud Loggingから取得したログがBigQueryに反映されるようになっています。

最初これやってみたときにデータ連携まで10分くらいかかって、一向にうまくいかないなというふうに思って。あれ、この手順で失敗しちゃったのかなとちょっと思ったんですけど、無事データがCloud LoggingからBigQuery側に転送されました。連携されましたね。

BigQueryを使った集計

ではBigQueryを使ってCloud Loggingでできなかった集計をやってみようというところです。BigQueryはSQLが使えます。例えばapacheのログに対してステータスコードの集計というものを実行してみると、左下ですね。

わかりにくいんですけれども、ステータスコード……これちょっとクエリがおかしいですね。カウントを取っているのになぜカウントのasがステータスコードになっているのか……ちょっと私のSQLのレベルが下がっているような感じがしますね。お恥ずかしい限りです。これは。ちょっと恥ずかしいですね。

ちょっと違うんですけどもこういったかたちで簡単に集計ができますので。BigQueryすげぇ簡単だな……簡単だなっていうか、SQL書ける自分としてはまだやりやすいのかなと。間違っているのでなんとも言えないんですけども。

データポータルで可視化する

この結果をグラフィカルなグラフとかに表示させたいという場合には、また別のサービスがあります。データポータルというものがあってですね、これを可視化することができます。

画面上BigQueryのデータ探索で可視化すると簡単に可視化することができます。もともと旧名はDataStudioと言うらしく、サイトのコンソール上のサブドメインもdatastudioになっています。最初DataStudioで検索したときにあんまり資料が見当たらなくて、一体これは何のサービスなんだっていうふうにちょっと悩みました。

AWS的に言うと、Amazon QuickSightみたいなサービスなのかなという感じでした。けっこうGoogleっぽくて、結果をスプレッドシートに出力とかもできたりします。そのあたりはGoogleさんっぽいものなんだなというふうには感じました。

というわけで、AWSのログを使ってGCPで可視化、分析をしてみたという簡単なお話でした。これは第1回目なので、(今後)どんどん深掘りしていこうかなというふうに考えています。

Cloud Loggingサービスでログ管理

ではお時間もあれなので、まとめに入ります。今回AWSのログをGoogleに取り込んでみましたが、Cloud Loggingサービスでログ管理……集中管理ですね。GCPとAWSが使えるので、ログ管理というのはできるのではないかと思っています。

ただAzureさんは対応していないので、ちょっとそのあたりはどうなのかなというところです。BindPlaneがどこまで対応しているのかは、ちょっと私が調べきれていないのですが、SaaSのサービスとしては、いろんなサービスと連携できるそうです。

それからモニタリングのほうも、こちらも同じようにAWS、GCP、オンプレ、それからBindPlaneで対応しているサービスというのが対応可能なので、GCP側のサービスでモニタリングとロギングというところは集中管理できるんじゃないかなぁというふうに感じました。

そして集計。これ間違ってたらぜひ教えてほしいです。BigQueryでは集計できてLoggingだと集計できないのかなと思っているので、(スライドに)こういうふうに書かせてもらっています。

BigQueryではニアリアルタイムでログ分析ができそうです。というのはSQL文で集計とかができるので、単なるログの検索だけではなくてログに対しての集計であったり、集計した結果それを反映するデータポータルを活用してグラフィカルな可視化が可能というところもあるからです。この2つを使えばデータ分析かつデータの付加価値、そのデータを見やすいかたちで提供することが簡単にできるのかなと思いました。

そしてログ統合であったり分析のために不必要な実装はやめようというところで、今回AWSのログをGCPに。GCP側のチュートリアルにあるような内容を今回ご紹介しています(笑)。

開発コストや運用コストによって変わってくると思うんですけれども、基本的になるべく用意されたものを使って分析していく。そうすると分析のためだけになにかを作るということがないので、それに対する運用だったり、そこに対するコストというのがかかってこなくなる。なるべくそういったものを使っていったほうがいいのではないかなというふうに思っています。

やはりクラウドなので、そういったサービス、連携というのがどんどん進化して蜜になってくるところはある。蜜というか、対応されていくと思いますので……。そういったところを待てない場合は仕方ないんですけども、クラウドサービスなのでそういったところは柔軟に対応してくれるのではないかという期待をもっていければいいのかなと思っています。

あとこれ毎回言ってるんですけども、僕はログ分析ツール、ログを分析するための機材、ツールというのは、基本的にクラウドおよびSaaSを使っていこうというふうに考えています。

いきなりここで言うのもあれなんですけども、最後にもまた言います。登壇者と運営チームを随時募集していますので、運営チームもしくは小林まで連絡ください。ありがとうございました!

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!