2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
AWSのログをGCPに出力してみた話(全1記事)
リンクをコピー
記事をブックマーク
小林賢司氏:私のほうからは、『AWSのログをGCPに出力してみた話』ということを20分程度話させてもらえればと思っています。
まず自己紹介します。私、小林賢司と申します。ログ分析勉強会の運営をやっています。フォージビジョン株式会社のクラウドインテグレーション事業部というところで、カスタマーエンジニアという役職で仕事をしています。主にAWSを触ったりとか、たまにログ系を触ったりとかしています。
弊社としてAWSのProの資格をもっていますので、今回はGCPのお話にはなるんですけれども、AWSとGCPというところでお話できたらなと考えています。
好きなものと苦手なものは以下のとおりです。ログ分析してる人で正規表現苦手というのは、ちょっとなんとも言いづらいんですけど、あんまり得意ではないというのは、ここでお伝えしておこうかなと思います。
初めてのオンライン開催なんですけれども、#logbenでたくさんツイートいただけると助かります。
前回のオフライン勉強会では、入門のところで『これからはじめるログ分析』として、そもそもなんでログ分析するの? という感じのお話をしています。スライドシェアで公開しているので、これから始めようと思っている方とか、そもそもどんな分析をすればいいのか? そもそも何をすればいいの? みたいなところから迷っている方がいれば、ぜひ見ていただければと思っています。
今日お話することは、スライドのとおりです。なぜAWSのログをGCPに? というところ。今回なにも考えずに試してみて、こういう構成だったらいけるんじゃねぇの? というところをちょっと思ってみた構成。そしてAWSのログを収集するときはどうすればいいのか?というところを紹介していきたいと思います。
私GCPって、ほとんどというか、触ったことなかったんですけれども、GCPのCloud Loggingというサービスだったり、BigQueryというサービスがあるので、そちらの紹介。最後にまとめさせてもらえればなと思っています。
ではさっそく始めたいと思います。なぜAWSのログをGCPに? というところからです。もともと私、ログ分析を5、6年やってきてまして、その中でもともとオンプレのログをずっとやってきました。
やはりログ分析をするうえで、私自身が、ログ分析のツールというのをよく使っていたんですね。よく使っていたものとしては、SplunkであったりElasticsearchであったり。最近ですと、Sumo Logicみたいなものを使っていたりします。
そうした中で、前回私は「ログ分析はクラウドで!」というふうに言いました。そこでやはりAWSだけではなくて、そのほかのクラウドサービスのログ分析のツールであったりサービスというものを知らないといけないなというふうに感じました。その一環として今回、AWSのログをGCPに取り込んでみました。
世の中のシステムというのは、単一のクラウド構成とは限らないのかなと思っています。やはりマルチクラウドの環境でのログ分析というのは、通常1つのプラットフォームからするとやっぱり難しいと思います。
なぜかと言いますと、各クラウド間のデータの連携が本当にできるのか? 連携のために実装が必要なのか? 実は別の仕組みを使わないとデータが取り込めないのか? とか。サービスが分かれてしまうと、こうした課題があるかと思います。今回はAWSとGCPの一例というところなので、ぜひご興味ある方は見ていただければと思っています。
今回は時間の関係もあるんですけれども、ログを収集するためだけに、例えばAWSで言うとLambdaを使ってS3のログを転送したりとかというのは、一切考えていません。あくまで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みたいなサービスなのかなと思っています。
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に関しては、データの集計だったりもできたと思います。ちょっと私の調べた限りだとCloud Loggingのサービスに関しては、データの集計というのがあまり得意じゃなさそうだなというふうに感じました。
ただしGCP以外のログも取り込めるという点では、統合ログ管理ツールとして使う価値はあるのかなというふうに感じました。なので、集計はできないので障害発生時に調査する場合に利用できるのかなと思いました。
Cloud Loggingサービスを使うと、データのアウトプットもできます。JSON形式やCSV形式で出力できます。
それからBigQuery、たぶん今回聞いてる方はみなさん知ってると思うんですけれども……。実は私、初めて使うものなんですが、BigQueryへも連携ができるということになっています。
あともう1つ、Cloud Monitoringもすごいなというふうに感じました。今回GCP上にAWSのインスタンスの情報を送っていたんですけれども、本当にCloudWatchと一緒な感じでEC2上のメトリクス情報を取得できます。パブリッククラウドで利用するケースでも、GCPのCloud Monitoringというのは使えるのかなというふうに感じました。
もちろんアラートとかも作成できるので、閾値設定して条件設定して通知させたりとかというのもできるようになっています。
BigQueryで分析してみようというところです。ロギングの部分は先ほどロギングとモニタリングというところでご説明したので、ログ情報をもとにBigQueryを使って分析したらどうなるのかというところをご紹介していきたいと思います。
最初にBigQueryとは? というところです。フルマネージドなビッグデータ分析サービスっていう、すごくざっくりしすぎちゃってるので何言ってるかよくわからないんですけれども……。
もともとはデータウェアハウス向けに作られたようなサービスだそうです。もともとGoogleの中で使われていたサービスを一般公開しているようなサービスだとお聞きしました。
いろいろ使ってみて感じたんですけれども、データウェアハウスというわりにはけっこうニアリアルタイム。EC2のログもすぐリアルタイムで取り込まれているように感じましたので、トランザクションがあったりとかアクセスがあるサイトであったりとか、たくさんログが出力されるサイトとかでも、ニアリアルタイムで使えるのであれば分析する用途としても十分使えるのかなと思いました。
AWSではどういうサービスと対抗するかと言うと、Amazon Redshiftが一番よく言われますが、ちょっと僕の使ってみた感じだと、似ている部分はあるけどちょっと違うなっていうのはありましたね。
どちらかというとRedshiftってバッチ処理のイメージが高いんですけれども、BigQueryに関しては、バッチ処理以外にもニアリアルタイムで検索するというのがイメージとしてあるなと感じました。
ではCloud LoggingからBigQueryへどうやって移行するか。データを転送するかというところです。こちらもすごく簡単でして、シンクを作成する。Cloud Loggingの画面にはシンクの作成というものがありまして、どのデータサービスに対してシンクをするかというものになっています。
BigQueryを選んでシンクのエクスポート先……データセットですね。データセットを任意の名前で設定すると、簡単にBigQuery側にCloud Loggingで取得したログデータを反映できるようになっています。
この画面がBigQueryの画面です。赤いところに先ほど作ったデータセットが表示されて、Cloud Loggingから取得したログがBigQueryに反映されるようになっています。
最初これやってみたときにデータ連携まで10分くらいかかって、一向にうまくいかないなというふうに思って。あれ、この手順で失敗しちゃったのかなとちょっと思ったんですけど、無事データがCloud LoggingからBigQuery側に転送されました。連携されましたね。
ではBigQueryを使ってCloud Loggingでできなかった集計をやってみようというところです。BigQueryはSQLが使えます。例えばapacheのログに対してステータスコードの集計というものを実行してみると、左下ですね。
わかりにくいんですけれども、ステータスコード……これちょっとクエリがおかしいですね。カウントを取っているのになぜカウントのasがステータスコードになっているのか……ちょっと私のSQLのレベルが下がっているような感じがしますね。お恥ずかしい限りです。これは。ちょっと恥ずかしいですね。
ちょっと違うんですけどもこういったかたちで簡単に集計ができますので。BigQueryすげぇ簡単だな……簡単だなっていうか、SQL書ける自分としてはまだやりやすいのかなと。間違っているのでなんとも言えないんですけども。
この結果をグラフィカルなグラフとかに表示させたいという場合には、また別のサービスがあります。データポータルというものがあってですね、これを可視化することができます。
画面上BigQueryのデータ探索で可視化すると簡単に可視化することができます。もともと旧名はDataStudioと言うらしく、サイトのコンソール上のサブドメインもdatastudioになっています。最初DataStudioで検索したときにあんまり資料が見当たらなくて、一体これは何のサービスなんだっていうふうにちょっと悩みました。
AWS的に言うと、Amazon QuickSightみたいなサービスなのかなという感じでした。けっこうGoogleっぽくて、結果をスプレッドシートに出力とかもできたりします。そのあたりはGoogleさんっぽいものなんだなというふうには感じました。
というわけで、AWSのログを使ってGCPで可視化、分析をしてみたという簡単なお話でした。これは第1回目なので、(今後)どんどん深掘りしていこうかなというふうに考えています。
ではお時間もあれなので、まとめに入ります。今回AWSのログをGoogleに取り込んでみましたが、Cloud Loggingサービスでログ管理……集中管理ですね。GCPとAWSが使えるので、ログ管理というのはできるのではないかと思っています。
ただAzureさんは対応していないので、ちょっとそのあたりはどうなのかなというところです。BindPlaneがどこまで対応しているのかは、ちょっと私が調べきれていないのですが、SaaSのサービスとしては、いろんなサービスと連携できるそうです。
それからモニタリングのほうも、こちらも同じようにAWS、GCP、オンプレ、それからBindPlaneで対応しているサービスというのが対応可能なので、GCP側のサービスでモニタリングとロギングというところは集中管理できるんじゃないかなぁというふうに感じました。
そして集計。これ間違ってたらぜひ教えてほしいです。BigQueryでは集計できてLoggingだと集計できないのかなと思っているので、(スライドに)こういうふうに書かせてもらっています。
BigQueryではニアリアルタイムでログ分析ができそうです。というのはSQL文で集計とかができるので、単なるログの検索だけではなくてログに対しての集計であったり、集計した結果それを反映するデータポータルを活用してグラフィカルな可視化が可能というところもあるからです。この2つを使えばデータ分析かつデータの付加価値、そのデータを見やすいかたちで提供することが簡単にできるのかなと思いました。
そしてログ統合であったり分析のために不必要な実装はやめようというところで、今回AWSのログをGCPに。GCP側のチュートリアルにあるような内容を今回ご紹介しています(笑)。
開発コストや運用コストによって変わってくると思うんですけれども、基本的になるべく用意されたものを使って分析していく。そうすると分析のためだけになにかを作るということがないので、それに対する運用だったり、そこに対するコストというのがかかってこなくなる。なるべくそういったものを使っていったほうがいいのではないかなというふうに思っています。
やはりクラウドなので、そういったサービス、連携というのがどんどん進化して蜜になってくるところはある。蜜というか、対応されていくと思いますので……。そういったところを待てない場合は仕方ないんですけども、クラウドサービスなのでそういったところは柔軟に対応してくれるのではないかという期待をもっていければいいのかなと思っています。
あとこれ毎回言ってるんですけども、僕はログ分析ツール、ログを分析するための機材、ツールというのは、基本的にクラウドおよびSaaSを使っていこうというふうに考えています。
いきなりここで言うのもあれなんですけども、最後にもまた言います。登壇者と運営チームを随時募集していますので、運営チームもしくは小林まで連絡ください。ありがとうございました!
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略