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.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには