Programming Self-Study Notebook

勉強したことを忘れないように! 思い出せるように!!

Programming Self-Study Notebook:目次

目次

言語系


- 「Python関連のノート」のまとめ(作成中)

ミドルウェア

開発支援ツール

OS系

クラウドインフラ系

開発手法について

その他

システムログを活用をするためのシステムとは?

f:id:overworker:20210505101442p:plain:h200

ログ活用のための仕組みに関して調べた時のノートです。
(きっかけは 稼働ログをもっと活用するには に記載させていただきました。)

ETLツールDWHBIツールという単語をこの調査で初めて知った程度のレベルです。
1日しか調べていないので、根本的に間違っているかもしれません。
お気づきの点がございましたらコメント等でご指摘いただけると幸いです。

課題

f:id:overworker:20210505112959p:plain:w500

現状

  • 様々な場所に蓄積されている
  • データが格納されている場所ごとにデータフォーマットが異なる
  • それぞれの場所に格納されているデータの種類が不明確
  • データの可視化がされていない
  • 用途に合わせたデータの加工が十分にできていない

アンチパターン

f:id:overworker:20210505113443p:plain:w500

『全てのデータに対応するモニターツール(Viewer)を開発する』のは現実的ではないと判断されている。

問題点

  • 対象データが全く同じになるシステムは存在しないため、専用ツールとなってしまう
  • 大量のデータを扱うため、Viewerが実施しなければならない処理量が非常に大きい
    • 格納されているデータがのフォーマットが、ログ活用に向かない
    • 処理量が多すぎてViewerとして機能しない
  • Viewerの数だけデータソースを直接読み込むプログラムが必要になる。
    • Viewerが動作する際にデータソースを直接読み込むため、データソースへデータ登録を行うシステム側への影響が発生する
  • データソース側の仕様変更が、すべてのViewerに伝搬するため、メンテナンスコストが膨大になる。

課題

  • データ活用処理がメイン処理(データ格納側の処理)に影響を与えてはいけない。つまりメイン処理と疎結合のシステムである必要がある
  • 応答性に優れたシステムである必要がある。
    • データが要求されてからデータを作成するのではなく、あらかじめ必要になりそうなデータを用意しておく。
  • データ取得に対する学習コストが低い(標準的なフォーマットでデータが格納されている)。

改善提案(一般論)

f:id:overworker:20210505113742p:plain:w500

上記の課題を解決するために、一般的にはデータ解析専用のデータベースを用意することが多い

データ解析専用のデータベースには以下の特徴が必要になる

  • 分析しやすいデータ
  • 検索しやすいデータ

また、蓄積されたデータは時間毎に解析されることが多いので、時系列データとして扱われることが前提

  • 時系列

上記システムで目的を達成するためには、データ解析専用のデータベース以外に、データベースへのデータ格納処理データベースの可視化処理が必要になる。

一般的には、 データソースのことをデータレイクデータ解析専用のデータベースDWH(データウェアハウス)と呼び、データベースへのデータ格納処理ETLツールデータベースの可視化処理BIツールというツールで実施することが多い。

DB (変換処理) DB (変換処理) 可視化
データレイク DWH ブラウザ
ETLツール BIツール

ETLツール

ETLツールとはExtract(抽出)Transform(変換)Load(書き出し)の先頭を集めた言葉で、複数のシステムからデータを取り出し、DWHへ受け渡す機能をもったツール。
場合によってデータレイクへ直接アクセスする必要があるので、メイン処理側への負荷を考慮する必要がある。

DWH(データウェアハウス)

ストレージの低価格化が進み、情報活用を目的としたデータベースを保持することのコストが低下したため、「DWH(データウェアハウス)」生まれた。 DWHは最初から「活用」を意識したデータの巨大倉庫です。目的が一つ(データ活用)なので、目的達成のために有効な仕組みがあらかじめ用意されている。 DWHは目的別にデータが並べられ、明細データをそのまま時系列で蓄積する。 データの削除や更新も行わないため、膨大なデータを保持し続ける。

DWHには以下の特徴が必要になる

  • 分析しやすいデータ
    • 共通フォーマット:複数のデータレイクから集められたデータであるが、共通の方法でアクセスが可能
    • 詳細データ:解析処理の軽微な変更に対して柔軟に対応ができるように加工前の詳細データが残っている
    • 要約データ:あらかじめ目的毎に集計したデータが格納されている
    • 時系列データ:時間変化が解析しやすい形になっている。
  • 検索しやすいデータ

BI(Business Intelligence)ツール

  • DWHとETLによって集約されたデータの分析を分析・可視化を行う
  • 目的に合ったデータの加工を実施する

よくある形

f:id:overworker:20210505115008p:plain:w500

ETLDWHBIはそれぞれ様々な製品が存在するとともに、それぞれのツールの機能範囲が重複しているため、境界をどこに設定するかはデータ活用基盤を作成するユーザー次第

  • ステージング層
    • データレイクに負荷をかけないために、データレイクのレプリカを用意したうえで、レプリカに対してフォーマット変換やデータクレンジングを行う。
    • ストレージの低コスト化により、Extract(抽出)Load(書き出し)Transform(変換)の順番で処理されることも増えてきた。
  • データマート層
    • BIツールがデータ処理を行いやすいように、DWHに格納されているデータのサマリーをあらかじめ作成、管理しておく。

具体的なサービス

AWSを利用する場合

ETLツール(DataGlue)

f:id:overworker:20210505152328p:plain:w500

BIツール(QuickSight)

方法1:QuickSight をオペレーショナルデータベース (Amazon RDS など) のデータに接続する
f:id:overworker:20210505151533p:plain:w500
方法2:QuickSight をデータウェアハウス (Amazon RedShift など) に接続する
f:id:overworker:20210505151713p:plain:w500
方法3:QuickSight をデータレイク (Amazon S3 など) に接続する
f:id:overworker:20210505151821p:plain:w500

GCPを利用する場合

ETLツール DWH BIツール
Dataflow BigQuery Looker

その他のサービスを利用する場合

複数のIaaSを想定した場合、データ活用の基盤を一つのIaaSに限定することは得策ではない。そのような場合に備えてIaaSに依存しないツールを選択することも考えられる。

ETLツール DWH BIツール
Fivetran Snowflake Tableau

「無料版はてなブログ」で【Google AdSense】に合格!

f:id:overworker:20210417082736j:plain:h300

「無料版はてなブログ」でGoogleAdSenseが使えることを知ったので自分のブログにも導入してみました。 導入まで、多少手間がかかりましたが最初だけだと思って頑張りました。

概要

  • はてなブログ内に成功体験がたくさん書かれていますので、それらを参考に以下の「1~4の作業」を行いました。

準備

1.プライバシーポリシーの設置
2.お問い合わせフォームの設置
3.Google searchConsole(サーチコンソール)へ登録
申請

4.実際の申請手続き

準備詳細

1.プライバシーポリシーの設置

プライバシーポリシーってなに?

  • プライバシーポリシーとは、収集した個人情報を、サイト運営者がどのように取り扱うか記載したもの
  • 無くても審査に通った人がいるらしいですが、あるに越したことはないので設置しました。

プライバシーポリシーの必要条件

  • 内容が適切である
  • わかりやすい場所に表示されている(サイドバー)

内容の例

  • 既に審査に合格している人のプライバシーポリシーをお手本に記載(コピペ+自分用に変更)すればOKです。
  • 当サイトのプライバシーポリシーはこちらです。
    • 名前、URL等の部分を変更することを前提に、再利用(コピペ)OKです。

工夫したところ

  • プライバシーポリシーのみが記載された記事を作成しました。
  • どの記事からも確認しやすい、かつ分かりやすい場所にプライバシーポリシーを設置したかったので、サイドバーカテゴリーを追加しておきました。
  • 作成した記事(プライバシーポリシー)に対しカテゴリープライバシーポリシーを付加しました。

2.お問い合わせフォームの設置

お問い合わせフォームってなに?

  • 要は、「サイトや内容に対する問い合わせ」を受けとれるようにしておくことです。

お問い合わせフォームの設置作業の手順

3.Google searchConsole(サーチコンソール)へ登録

Google searchConsoleってなに?

  • 自分のサイトがGoogle検索上で、どのように扱われているか?を可視化するサイトです。
  • 主に『どのような検索ワードで』『どれくらい表示され』『どれくらいクリックされたか』が分かります。

Google searchConsoleの登録作業

Google searchConsole側の作業

f:id:overworker:20210502142420p:plain:w500
  • URLプレフィックスに自分のサイトのURLを入れて続行を選択
f:id:overworker:20210502142842p:plain:w500
  • 後は指示に従って処理を進めてください。

はてなブログ側の作業

  • Headに要素を追加するように指示が出ます。
    • 設定詳細設定head内タグheadに要素を追加に指定された文字列を追加してください。
f:id:overworker:20210502143454p:plain:w400
  • 実際に登録する箇所はこんな感じです。
f:id:overworker:20210502144358p:plain:w400

実際の申請手続き

以下のサイトから申請を行います AdSense へのお申し込み - AdSense ヘルプ

AdSenseに申し込むをクリックします。

f:id:overworker:20210502141244p:plain:w400

自分なりに入力して保存して次へをクリックします。

f:id:overworker:20210502141756p:plain:w400

私の時のメモ

以下私が申請した際の時間経過です。

  • 申請から実際に承認メールが届くまで約36時間です。
    • 申請した直後に「ようこそ!設定を完了して利用を開始しましょう」というメールが届きました。(2021/4/30 24時頃)
    • その後、2日後に「お客様のサイトで AdSense 広告を配信する準備が整いました」というメールが届きました。(2021/5/2 12時頃)
  • 前評判だと2週間程度という話だったので、「GW期間中だしもっとかかるだろうな~」と思っていたのですが、関係なかったようです。

申請後の作業

f:id:overworker:20210502153436p:plain
  • GoogleAdSense側で広告を有効化する必要があります。
    • お客様のサイトで AdSense 広告を配信する準備が整いました というメールの指示に従ってください。

CloudWatch Logs Insightsでログを絞りこむ

f:id:overworker:20210304234231p:plain:h200

CloudWatch logs Insights(インサイト)のクエリの使い方について調べました。

f:id:overworker:20210503164249p:plain

参考文献

基本的なコマンドの概要

コマンド 説明
display クエリ結果に表示するフィールドを指定します。
fields 指定したフィールドをログイベントから取得して表示します。
filter クエリの結果を 1 つ以上の条件に基づいてフィルタリングします。
sort 取得したログイベントをソートします。
stats ログフィールドの値に基づいて集約統計を計算します。
limit クエリから返されるログイベントの数を指定します。
parse ログフィールドからデータを抽出し、1 つ以上のエフェメラルフィールドを作成してクエリでさらに処理できるようにします。

コマンドの詳細(私がよく使う順)

fields

説明

  • 指定したフィールドをログイベントから取得して表示します。
  • fields コマンド内で関数とオペレーションを使用して、表示するフィールド値を変更したり、クエリの残りの部分で使用する新しいフィールドを作成したりできます。

# 基本的な記述
fields @timestamp, @message

# `message`の中の`mesthod`と`path`を`-`でつなぎ、新たに`api`と命名する
fields @timestamp, concat(message.method, '-', message.path) as api

sort

説明

  • 取得したログイベントをソートします。
  • 昇順 (asc) と降順 (desc) の両方がサポートされています。

# 基本的な記述(デフォルトは昇順)
fields @timestamp, @message
| sort @timestamp

# 降順を指定
fields @timestamp, @message
| sort @timestamp desc

limit

説明

  • クエリから返されるログイベントの数を指定します。
  • これを使用して、結果を小さい数値に制限し、関連する結果の小さいセットを表示することができます。
  • さらに、limit で 1000 ~ 10,000 の数値を使用し、コンソールに表示されるクエリ結果の行数を、デフォルトの 1000 行より大きい数に増やすこともできます。
  • 制限を指定しない場合、クエリにはデフォルトで最大 1000 行表示されます。

# 最新の25件を表示する
fields @timestamp, @message
| sort @timestamp desc
| limit 25

filter

説明

  • クエリの結果を 1 つ以上の条件に基づいてフィルタリングします。
  • filter コマンドでは、さまざまな演算子や式を使用できます。
使用できる演算子・表現
  • 正規表現
  • 比較演算子 (=!=<<=>>=)
  • ブール演算子 (andornot)
  • 文字列一致
    • 完全一致:in (not in)
    • 部分文字列:lile(または、=~

# `message.duration`が`2000`より大きいもの、かつ`message.method`が`POST`
fields @timestamp, @message
| sort @timestamp desc
| limit 25
| filter (message.duration > 2000) and (message.method = 'POST')

# message.durationが2000より大きいもの
fields @timestamp, @message
| sort @timestamp desc
| limit 25
| filter @message like /("status":"5\d{2}")/

# statusCodeが配列要素のいずれかと完全一致する
fields @timestamp, @message
| sort @timestamp desc
| limit 25
| filter statusCode in [300,400,500]

stats

説明

  • ログフィールドの値に基づいて集約統計を計算します。
  • statsby を併用すると、統計の計算時にデータをグループ化するための 1 つ以上の条件を指定できます。
  • 統計演算子として、avg()sum()count()min()max() などがサポートされています。

# f2 の一意の値ごとに f1 の平均値を計算します。
stats avg (f1) by f2

display

説明

  • クエリ結果に表示するフィールドを指定します。
  • このコマンドをクエリで複数回指定すると、最後に指定したフィールドのみが使用されます。

# timestampのみを表示する
display @timestamp

parse

説明

  • ログフィールドからデータを抽出し、1 つ以上のエフェメラルフィールドを作成してクエリでさらに処理できるようにする。
  • parse は、glob 表現と正規表現のいずれも承認します。

その他

クエリのコメントアウト

  • # 文字を使用して、クエリの行をコメントアウトすることができます。
  • # 文字で始まる行は無視されます。

演算子・関数

  • 比較演算子 (=!=<<=>>=)
  • ブール演算子 (andornot)
  • 算術演算子(+(加算),-(減算),*(乗算),/(除算),^(指数),%(剰余))
  • 数値処理(abs(絶対値),ceil(上限に切り上げられる),floor(下限に切り下げられる),greatest(最大値を返す),least(最小値を返す),log(自然対数),sqrt(平方根))
  • 一般関数:省略
  • 文字列関数:省略
  • 日時関数:省略
  • IPアドレス関数:省略
  • 統計集計関数:一部

    関数 説明
    count() ログイベントをカウントする
    count(fieldName: LogField) 指定されたフィールド名を含むすべてのレコードをカウントする
    sum(fieldName: LogField) 指定したフィールドの値の合計
    pct(fieldName: LogFieldValue, percent: number) 指定されたフィールドの値の標準偏差
    stddev(fieldName: NumericLogField) 指定したフィールドの値の合計

稼働ログをもっと活用するには?

f:id:overworker:20210505101442p:plain:h200

はじめに

問題提起

私はスマホアプリを通してユーザーに価値を提供するシステムの、サーバー(バックエンド側)の開発を行っています。 スマホアプリにはWebAPI経由で機能を提供しています。

f:id:overworker:20210505101649p:plain:h200

サーバーの稼働ログは日々蓄積されているのですが、エラー発生時程度しかログを参照していない現状に対し、以下のような疑問を抱くようになりました。

  • WebAPIの利用履歴を解析することでWebAPIの内部設計の改善ができるかもしれない
  • WebAPIの利用履歴を解析することでサーバーの負荷軽減(可用性向上+コスト削減)ができるかもしれない
  • WebAPIの利用履歴を解析することでWebAPIの仕様改善ができるかもしれない
  • WebAPIの利用履歴を解析することでアプリ機能を見直すきっかけになるかもしれない
  • ユーザーがアップロードする個々のデータを匿名化したうえで集計することで、ユーザーをより具体的にイメージすることができるかもしれない

原因究明

f:id:overworker:20210505102336p:plain:h200

サーバーの稼働ログが、エラー解析に活用されているのはなぜか?

  • エラー解析実施しなけらばならないタスクであると認知されているから
  • エラー解析を実施するうえで、サーバーの稼働ログ内に有効な情報が存在することが認知されているから

サーバーの稼働ログが、エラー解析以外の用途で活用されていないのはなぜか?

  • 目的に合わせてログを加工する必要があるからから。
  • 現状として問題が発生していないように見えるから。

目指す姿

f:id:overworker:20210505103456p:plain:h200

どのような条件が整えば稼働ログが様々な用途に活用されるか?

  • 蓄積されている項目が明確である
  • 蓄積されている項目が共有されている
  • 各種項目の状態や変化が容易に確認できる

さらに欲を言うと

  • データを活用する人が必要とする項目を追加することができる。

行動

f:id:overworker:20210505103538p:plain:h150

上記状況を改善するために、まずは一般的なデータ活用のフローやシステムを調査からスタートしてみたいと思います。

懐かしの『3D Pinball』がWindows10でもできました!

f:id:overworker:20210430170921p:plain

昔やっていたゲームが無性にやりたくなることってありませんか?
私は『3D Pinball』というWindowsPCに付属していたゲームが急にやりたくなったので調べてみました。

無償提供されているらしい!

オリジナルの配布サイトはなくなっていますが、インターネットアーカイブという財団がインストーラーを無償提供しているようです。

導入手順

手順1.インストーラーのDownload

DLサイトへアクセス

インストーラーをDownloadする

f:id:overworker:20210430170821p:plain:w500
  • サイトにアクセスしたら、画面最上部にあるDownloadをクリックします。
f:id:overworker:20210430171437p:plain:w500
  • 次にMSI Installer For Windows Vista & 7 (32 & 64 Bit)の下にあるDowmload Fileをクリックします。
    • MSI Installer For Windows Vista & 7 (32 & 64 Bit)が二つ存在します。
    • 私には同じタイトルに見えましたので、試しに両方のリンクからDLをしてみました。

      タイトル 実際にDLできたファイル名
      MSI Installer For Windows Vista & 7 (32 & 64 Bit) [1.33 MB] 3d_pinball_for_windows-space_cadet.exe
      MSI Installer For Windows Vista & 7 (32 & 64 Bit) [1.86 MB] 3d_pinball.msi

  ※ 1.33MBの方がMSIインストーラーではなくEXEインストーラーのようです。

  • クリックするとDownloadが始まります。 ※ 今後の処理はMSIインストーラーを使用するようにします。

手順2.インストーラーの実行

  • 3d_pinball.msiをダブルクリックします。
f:id:overworker:20210430173008p:plain
  • Nextをクリックします。
f:id:overworker:20210430173214p:plain:w500
  • Installをクリックします。
f:id:overworker:20210430173342p:plain:w500
  • ~変更を加えることを許可しますか?と聞かれるので、はいを選択する

  • Finishをクリックします。

f:id:overworker:20210430173603p:plain

手順3.『3D Pinball』を起動する

  • スタートメニューから『3D Pinball』を起動します。
f:id:overworker:20210430174204p:plain

JMeterでcsvファイルからパラメータを読み込む方法

f:id:overworker:20200422002101p:plain

久しぶりにJMeterのノートを書きたくなりましたので、前々からまとめておきたかったcsvファイルからパラメータを読み込む方法をまとめてみました。

テスト計画への追加

概要

  • 自作した変数に対し読み込んだ値を割り当て、テスト内で使用することができます。
  • テスト計画で読み込むこともできますし、サンプラーで読み込むこともできます。
f:id:overworker:20210430111333p:plain

追加方法

  • 読み込みたい所での右クリックからスタートです。
    • 追加->設定エレメント->CSV Data Set Config
f:id:overworker:20210430111123p:plain:w500

CSV Data Set Configの設定内容

f:id:overworker:20210430122505p:plain:w500

 ①:名前

  • GUI上のテスト計画ツリー(左側)のタイトル表示部分が連動します。

 ②:コメント

  • どこに影響するか不明です。

 ③:Filename

  • 実際に読み込むcsvファイルのPathを指定します。
  • 絶対Path/相対Pathが使用可能です。
    • 相対Pathの場合、基準となるPathは以下の順序で決まるようです。
      • 優先順位①:JMeterの実体がおかれているbinフォルダ(←個人的には非推奨)
      • 優先順位②:実行ファイル(jmxファイル)がおかれたディレクト
    • 絶対Path:(←個人的には非推奨)
  • 階層の区切り文字は/\が混在していても動作するようです。
    • WindowsPCで作成したテスト計画をLinuxマシンからCLI実行しても、問題なく動作しました。

※ テストをgit等で共有する場合、共有するディレクトリ以下で相対Pathで成立する指定方法にしておく必要があります。

 ④:File encoding

  • 以下が最初から用意されています。
    • UTF-8UTF-16ISO-8859-15US-ASCII編集 
      • (私はUTF-8以外を使用したことがありません。)

 ⑤:Variable Names(comma-delimited)

※ この欄が空の場合、csvファイルの1行目を変数名として解釈させることが可能です。

  • 変数名のリスト。
  • 名前は区切り文字で区切る必要があります。
  • 二重引用符を使用して引用できます。
  • JMeterCSVヘッダー行をサポートしています。
  • 変数名フィールドが空の場合、ファイルの最初の行が読み取られ、列名のリストとして解釈されます。

 ⑥:Ignore first line(only use if Variable Names is not empty)

  • Variable Names(comma-delimited)に値がセットされている場合、csvファイルの1行目を無視することができます。

 ⑦:Delimiter(use '\t' for tab)

  • 区切り文字を指定することができます。
    • (私は,を使用しています。)

 ⑧:Allow quoted data?

  • CSVファイルで値を引用できるように指定できます。
    • 有効にすると、値を「-二重引用符-で囲むことができ、値に区切り文字を含めることができます。

 ⑨:Recycle on EOF?

  • 通常は一回のCSV Data Set Config実行でcsvファイルを1行読み込みます。
    • CSV Data Set Config実行回数が、対象ファイルの行数を超えた場合に、先頭行に戻って指定パラメータの値を更新します。

 ⑩:Stop thread on EOF?

  • ⑨がfalseの時のみ、セットした値が有効になります。
    • ファイルの読み込みが最終行に到達した時点で、スレッドを終了します。

 ⑪:Sharing mode

  • 以下の4つから選択することが可能です。
    • All threads:すべてのスレッドでシェアされます
    • Current thread group:スレッドグループごとに管理されます
    • Current thread:スレッドごとに管理されます
    • Identifier:すべて個別に管理されます。スレッド番号を使用して、異なるスレッドグループの同じスレッド番号間でファイルを共有することもできます。

参考資料

Apache JMeter - User's Manual: Component Reference