忘備録φ(..)

仕事の日記。過去の自分に教えてあげたいこと

ブログのcssにちょこっと手を入れた

今年の目標の一つが、放置しっぱなしだったブログを愛着の持てるブログに育てることが目標です。

それをするにあたってデザインで少し気になっていた部分に手を加えることにしました。

今使っているデザインについて

一つの項目を作って説明するほどのものはないのですが、はてなブログ公式テーマのNeutralを使っています。(昨日まではSmoothを使っていました...w これも公式のやつです)

飽きっぽいのでシンプルなものにしたい、方向性が自分の中で固まっていない、といった理由で上記のテーマを設定しており、なんだかんだで気に入っているので使い続けているのですが、使い続けている内に「ここもう少しこうならないかな」みたいな欲が出てきました。

記事表示部分の横幅をもう少し広くしたい

↓いつも使っている23.8インチのモニターで表示した時

f:id:reiichii:20210117133349p:plain

↓いつも使っているMacBook Pro 13インチで表示した時

f:id:reiichii:20210117134649p:plain

もう少し横幅が欲しいなというところで、以下のように設定しました

#content-inner #main {
    width: 800px;
}

元が620pxで定義されていたので、+180された形になります。

なぜ800pxにしのかというと、PC版ウェブサイトの横幅が標準どのくらい設定されているのか複数のサイトを参考にしたところ1000px前後で設定されていることが多いみたいでした。サイドバーが268pxほどだったのでもう少し広くてもいいはずと思い、この値にした形です。

というか単位pxでいいのか、vw/vhとかに変えたほうがいいんじゃないかとも思ったのですが、このテンプレートの場合他もpx単位になっていたりするので一旦既存のやり方に乗っかることにします...。問題が生じたら対策を考えよう...。

h2に下線を付けたい

f:id:reiichii:20210117140101p:plain

記事のタイトルにh1が使われるので、ブログ本文の中ではh2、h3をよく使います。しかし記事の途中で単体で出ると「これはどちらなんだろう」と分からなくなることが多々あります。記事を読むときは少なからず全体の構成を頭の片隅に入れておきたいのでh2に下線などあると嬉しい人です。(右側にtable contentsを付けておくなど表現方法は他にも色々ありますが)

そんなわけで以下の設定を追加しました。

.entry-content h2 {
  padding-bottom: 10px;
  border-bottom: 5px solid #ddd;
}

インラインコードの背景を黒ではなくグレーにしたい

f:id:reiichii:20210117140332p:plain

コード挿入時の背景が黒なんだから同じ色でいいじゃないという気もするのですが、私のブログは背景白ベースで行く予定なので、インラインコードまで黒だと主張がいささか強過ぎる気もしました。なのでSmoothテーマで使っていた時と同じグレーにします

.entry .entry-inner p code {
  background-color: rgba(0,0,0,.03);
  color: #3d4245;
}

おわりに

cssはもともとあまり得意ではないのですが、Google developper toolを触れるようになってからは調査や調整がすごくやりやすくなって本当に有り難い限りです。

今のデザインも気に入っているのですが、今後はもう少し個人の色とかも出していきたいと思っているので、またアイデアが生まれたらどんどんカスタマイズしていきたいと思います。

CloudFormationでLambdaをデプロイする

AWS認定 DevOpsエンジニア - プロフェッショナルを受験しようかなと考えていて、サンプル問題を解きました。

AWS-Certified-DevOps-Engineer-Professional_Sample-Questions.pdf

成績は3/10問、解説を読みながら「いやこの問題解けたな」と思ったものが2問だったので合格にはそれなりに勉強が必要そうです🙂

そのサンプル問題の(5)を実際に手を動かして確認したいなと思ったので簡単にコードを書きました。

reiichii/sample-lambda-cfn

以下復習した時のメモです。

問題

(5) DevOps エンジニアが、AWS Lambda 関数を記述し、この Lambda 関数を AWS CloudFormation テンプレートスニペット内で指定し (下記参照)、このテンプレートを Amazon S3 バケットに格納しました。

MyLambdaFunctionV1:
  Type:"AWS::Lambda::Function"
  Properties:
    Handler:"index.handler"
    Role:"arn:aws:iam::515290864834:role/AccountScanner"
    Code:
      S3Bucket:"johndoe-com-lambda-source"
      S3Key:"AccountScanner.zip"
    Runtime:"dotnetcore2.1"
    Timeout:60

CloudFormation スタックが作成され、Lambda 関数が想定どおりに動作しています。DevOps エンジニアは、関数コードの新バージョンを入手したので、スタック更新後すぐに新バージョンが実行されるようにしたいと考えています。

この要件を満たすには、どのように展開すればよいですか (3 つ選択してください)。

A) CloudFormation テンプレート内の Lambda 関数の論理名を MyLambdaFunctionV1 か ら MyLambdaFunctionV2 に変更し、CloudFormation スタックを更新する。

B) 既存の S3 バケットにおいてバージョニングを有効化する。新しいコードを既存の S3 バケットにアップ ロードする。CloudFormation テンプレート内の Lambda 関数の S3ObjectVersion プロパティで、S3 オ ブジェクトのバージョン ID を指定し、その後 CloudFormation スタックを更新する。

C) AWS SAM を使用して、sam deploy コマンドを CloudFormation テンプレートに対して発行し、Lambda 関 数のバージョンを更新する。

D) CloudFormation テンプレート内の Lambda 関数の S3 バケットプロパティ値を、別のバケット場所を指すよ う変更する。新しいコードを新しい S3 バケット場所にアップロードする。CloudFormation スタックを更新 する。

E) CloudFormation テンプレート内の Lambda 関数の S3Key プロパティ値を、別の場所および名前の .zip ファイルを指すよう変更する。新しいコードを新しい S3 バケット場所にアップロードする。その際、.zip ファイルの場所と名前を変更したことに留意する。その後、CloudFormation スタックを更新する。

F) サーバーレスフレームワークを使用して、serverless deploy function -f MyLambdaFunctionV1 コマンドを発行し、既存の Lambda 関数を更新する。

復習

正解

正解はB、D、E

B.以下のようにtemplate.ymlを変更します

      Code:
        S3Bucket: "{S3Bucket}"
        S3Key: "SampleLambda.zip"
        S3ObjectVersion: "{S3ObjectVersion}" # 追記

こうすることでソースコードの変更が検知され、該当部分の更新が行われるようになります。(cfnの変更セットのプレビューで以下のように確認できる)

f:id:reiichii:20210113092616p:plain

アクションがModifyになっていて、変更リソースはLambda function、置換がfalseとリソースの削除が伴わない変更なので「スタック更新後すぐに新バージョンが実行される」状態になっています。

D.上記のコードの S3Bucket 値を変更した形になります。このテンプレートに置き換えることによって上記の変更プレビューと同じような結果が得られます。

E.上記のコードの S3Key 値を変更した形になります。この変更でも上記の変更プレビューと同じような結果が得られます。

不正解

A.このやり方でスタックの更新を行うと、MyLambdaFunctionV1が削除されたのちMyLambdaFunctionV2が作成され、リソースの作り直しが行われます。(依存関係にあるリソースが削除されたりなど)

C.AWS SAMとはServerless Application Modelの略です。 AWSが提供しているサーバーレスアプリケーションのテンプレートのようなものだそうです。AWS SAMにはcliが提供されていて、コマンド2つほどでAPI Gateway × Lambdaの構成のアプリケーションがデプロイできるようでした。

私は全然知らなかったのですが、AWS SAMは他の問題文や解凍群の中にもちらほら登場していました。

今回の場合、AWS SAMで作られたものではないので、sam deploy コマンドでデプロイできるようにするためには作り直す必要がでてきます。

F.もCと同じく、serverlessを用いたものに作り直す必要があります。

おわりに

cfnもLambdaも触ったことはあったので、実際にものを作って動かしたらそんなに難しい問題ではなかったですね😅 自分なりに理解は深められたので良しとします。

実際に本番環境をこの組み合わせで管理することになったら、S3のバージョニングで管理するのが良さそうだなと思ったり。ソースコードはGitで管理することになると思うので。

Google アナリティクス初級者向けコースを受けた

Googleアナリティクス触りたいけど分析するWebサイトとかデータ持っていないしどうしたものかなと悩んでいたのですが、Google アナリティクス初級者向けコースという公式が出す学習コンテンツがあったので利用しました。

内容は動画(複数あるけどいずれも3~7分程度の短さ)×チュートリアル(画面に触れる動画研修だった!)×演習問題×テスト(簡単め)で構成されており、デモアカウントの画面とデータを色々触りながら各画面の見方やできることを一通り知れたのがよかったです。4コース合計5時間くらいとライトだけど薄過ぎないちょうど良い濃さでした。

以下は学習メモです。自分が欲しい情報にフォーカスされているので少し偏ってはいますが、Google アナリティクス初級者向けコース気になっている人の参考になればと思います。

1. Googleアナリティクスの紹介

所要時間:1h

Googleアナリティクスの仕組み、アカウント設定、プロパティやビューといった構成要素の説明など。演習ではビューに対してフィルタを適用させて確認することをしました。

## 1.1 デジタル アナリティクスの利点
* 顧客が購入(CV)に至るまでのプロセスをデジタルでなら計測できる
  - どこからサイトに流入して、サイト内でどんな行動をして、購入に至ったのか
* オンライン広告のデータを分析して、もっとも効果的だったものに注力できる
  - 例. 地域別の売り上げデータを分析し、もっとも売り上げが高かった地域に多く広告を出稿するようにする
* サイトの問題を収集して、不具合の改善に活かす

## 2.2 Googleアナリティクスの仕組み
* アナリティクスのアカウントを作成するやり方
* サイトの各ページにJavaScriptのトラッキングコードを追加する
* これによりユーザーがページにアクセスするたびに、匿名情報が収集される
  - 例. コップ類を販売するページと家庭用品を販売するページのアクセス数を比較ができたり
  - 商品を購入したユーザー数を確認したり
  - ブラウザの設定言語、種類といった情報も収集される
  - どこから来たのか 
* トラッキングコードによって情報が収集される期間を`セッション`
  - トラッキングコードを含むページにアクセスすると開始され、活動がなくなってから30min経つと終了する
  - 再びアクセスすると新しいセッションが始まる
* 特定の条件でデータを見れる
  - 社内トラフィックのを除外したり、デバイス単位で集計したり
* 1度データベースに保存したデータは変更削除ができないので、設定には注意する

## 1.3 Google アナリティクスの設定
* プロパティ
  - 1アカウントに対して複数作れる
  - トラッキングコードに含まれるトラッキングidを使用して、それぞれ個別にデータを収集する。
    - ウェブサイト用、モバイルアプリ用、販売地域別にプロパティを作って特定の地域のデータを確認しやすくしたり
    - 複数のプロパティのデータを集計して表示することはできない
* ビュー
  - 1プロパティに対して複数追加できる
  - フィルタを使用して表示するデータを指定できる
    - 地域ごとのデータが必要な場合には、地域ごとのビューを作成する
    - 外部トラフィックのみ表示したい場合は、新しいビューを作って内部トラフィックを除外するフィルタを作成する
  - Googleアナリティクスの目標も設定できる
    - CV(購入や申し込み数、お問い合わせ数など)をトラックする有益な方法
  - 注意
    - ビューには作成した時点からのデータのみが含まれる
    - 削除後、管理者のみが35日までだったら復元できる

## 1.4 フィルタを使用したビューの設定
今までは動画だったが、動画形式で画面に触りながら進めるチュートリアル
* フィルターの適用までには30分ほどかかる
* test用ビューと本番用ビューを作成し、test用で動作確認したフィルタをmasterに適用させるといった使い方をした
* 一つのビューに複数フィルターが適用される場合は、フィルタ一覧に表示される順序で適用される

2. Googleアナリティクス インターフェース

所要時間:1h

デモアカウントの各画面を触りながら、レポート画面の操作方法(データの絞り込みなど)やレポートの共有方法、ダッシュボードで自分が見たいデータを一画面に集めることができることを知れます。

## 2.1 アナリティクスの操作
デモアカウントが作成される
* レポートのリアルタイム
  - 特定のグループのユーザーに関するリアルタイムのコンバージョン数を確認できる
    - 例. 1 日だけのプロモーションを実施している場合、そのプロモーションからクリックしてアクセスしたユーザーがコンバージョンに到達しているかどうか
    - 例. リアルタイムレポートのトラフィックから、ソース: directをクリックすると、直接流入した人たちのものに各レポートのデータをフィルタリングできる。選択した状態でコンテンツに移動すると、その人たちがどんなコンテンツを参照しているかを確認したりできる

## 2.2 サマリーレポートについて
デモアカウントのユーザーレポート画面のガイドを参照した

## 2.3 レポート全体について
* ユーザーレポートを元にできることが紹介されていた
  - セカンダリディメンションを指定できる
    - 国単位で表示しているデータに国-使用しているデバイス単位でデータを表示するようにする
  - グラフの形を変えられる。
    - テーブルから円グラフに。指標も選択できる
  - 表で表示されている各エントリ(流入)が行の平均を上回っているか、下回っているかを色でわけで割合を表示する
  - ピボットテーブルで値を比較できる
* ユーザー指標で計測される対象は、「特定の機関にサイトで1回以上のセッションを記録したユーザーの数」になる

## 2.4 レポートの共有
* レポートにフィルタやビューを設定して内容をカスタマイズできる
* サンプリングレートを速度か精度重視するものに設定できる
* サンプリングに関して、ビューフィルターを適用したり、複雑なセグメントを設定している場合、サンプル数が少なく、データ量が少なくなるケースがある

## 2.5 マイレポート一覧とショートカットの設定方法
* 自分が見やすいレポートをカスタマイズすることができる
  - 複数ページを開かなくても見たいレポートに一目でアクセスできるようにする
  - Datadogのdashboardみたいな
* 作ったレポートは他の人と共有したり、テンプレートをアナリティクスユーザーに共有したりできる
* 他の人が共有したカスタムレポートのテンプレートを引用して、そこからカスタマイズを加えたりもできる

3. ベーシックレポート

所要時間:1h

ユーザーレポート、インタレストレポートの見方と設定方法、集客レポートの活用方法や「参照」「メディア」といった用語の説明、行動レポートの見方といった内容でした。

この辺りから面白くなってきます。

## 3.1 ベーシックレポート
ユーザーレポートに関して
* ユーザーの分布
  - 性別や年齢を確認できる
* インタレストレポート
  - 音楽や旅行などウェブコンテンツの種類別にユーザーの好みを表示できる
* これらはターゲットユーザに適切にリーチしているかを確認するのに使える
* これらのレポートを見るためには以下を設定する必要がある
  - 広告向け機能を有効にする
  - データが表示されるのに1日から2日かかる場合がある
* 地域でアクセスされたipアドレスからユーザーがいる地域を匿名で特定できる
  - 例.アクセス数は多いのに直帰率の高い地域は広告やwebサイトの最適化が必要そうだ
動画の後に演習ページがあったのが良かった

## 3.2 集客レポート
* 集客レポートでは、さまざまなチャネルの成果を比較して、高品質なトラフィックやCV発生源を確認できる
  - これらのデータは戦略を練る際にどこに重点を置くか決めるときの参考になる
* メディア: organic(検索エンジン), cpc(広告のクリックによるもの), 参照(検索エンジン以外のクリック) email, none(ブラウザに直接urlを入力してアクセス)
* 参照元: ユーザーをサイトに導入したウェブサイトのurl
  - 例: media: organic, 参照元: google
* 「参照/メディア」の項目から、ユーザー数が多いものを確認することで、有効なトラフィックを特定できる
* 参照元/メディアごとに直帰率を見れる。サイト平均のものと比較できる
  - 直帰率: トラフィック品質の目安
* チャネルレポート: サイトを利用したユーザーが多いトラフィックを確認するのに使う
  - チャネル: 集客のための経路のこと。アナリティクスではメディア別に参照がorganic,social,directなどトラフィックが自動で分類される
  - 独自のチャネルグループを作成できる
* 参照を使うと自分のサイトにリンクしているWebページを具体的に見れる。
  - どこに広告を出せば効果的かわかるため、新たな広告パートナー契約先の候補になる

## 3.3 行動レポート
* ユーザーがサイトのページをどのように利用したのかがわかるレポート。
  - 改善が必要なページや、今後のコンテンツの方針を考える指針となるコンテンツを見つけられる
* ページがディレクトリごと表示される: `/Office/` `/Kids/` など
  - 特定のセクションにあるコンテンツのパフォーマンスを調べるときに役立つ
* 円グラフに切り替えるとユーザーに人気のあるセクションを簡単に表示できる
  - 40%が`/Wearables/`以下にアクセスしている、など
* ランディングページ にはユーザーが最初に到達したページが表示される
  - ランディングページごとの直帰率なども確認できる
* イベント: ファイルのDLなどユーザーの特定のアクションを追うことができる。(詳しくは上級者コースでと)

4. 基本的なキャンペーンおよびコンバージョントラッキング

所要時間:1h40m

キャンペーンを測定する仕組み、url生成ツールの使い方、CV(ビジネス目標)の設定方法と設定することで見られる情報といった内容でした。

CVの部分だけもともと自分が知りたかった部分というのもあり、動画で紹介されていた内容以上のものも調べたメモが載っています。

## 4.1 カスタムキャンペーンを測定する方法
* キャンペーンタグ: urlにパラメータ形式で設定できる
  - `?utm_content=v1-10dollars-off`
* アナリティクスのトラッキングコードによってリンクから情報が抽出され、ユーザーと行動がキャンペーンと関連づけられる
  - ユーザーがどのマーケティング活動からサイトに到達したのかがわかる
* キャンペーンタグの種類は5つ
  - メディア、参照元、キャンペーン、コンテンツ、キーワード
* コンテンツの使い方
  - ABテストで同じ内容の2種類のニュースレターを配信したとき、どちらがクリック数が多いか検証する時など
* キーワードの使い方
  - 主に有料広告の配信で使われ、設定するときに手動で追加する
* url生成ツールがある

## 4.2 URL 生成ツールを使用したキャンペーンのトラッキング
* キャンペーン名はレポートで表示されたときにわかりやすい名前にする
* スペースは`_`に変換される
* GUIからは一度に1urlずつしか作れないので、たくさん登録したい時はスプレッドシートにまとめてimportする
* キャンペーンタグの検証方法
  - シークレットモードでブラウザを開く
  - 生成したurlをアドレスバーに張り付ける
  - 遷移先のサイトで重要なアクションを行う(申し込みを行ったりなど)
  - リアルタイムレポートでトラフィックが確認できる
  - 集客 > キャンペーン > 全てのキャンペーン からテスト対象のキャンペーンで絞り込みをし、データが適切に収集されているか見れる

## 4.3 目標の設定によるビジネス成果の測定 [一番知りたかった情報だ]
* 2種類の目標の違い
  - ビジネス目標: ユーザーに行ってもらいたいアクション(購入など)
    - ユーザーがビジネス目標を達成することをCVと呼ぶ
  - アナリティクスの目標: CVのトラッキング機能
    - 目標を設定すると、アナリティクスにはいくつかのCV関連の指標が作成される(CVの合計数、至ったユーザーの割合)
    - 目標達成プロセスも合わせて設定できる。ファネル分析などに使う
* アナリティクスで設定できる目標は、ビューごとに20こまで
* 設定例: ECサイトなのでビジネス目標は購入してもらうこと。なので購入確認ページに到達することを目標と設定
* 目標の設定方法: 以下の項目を設定する
  - (Googleアナリティクスではいくつかテンプレートが用意されている)
  - 目標名
  - 目標スロットid: 1~20までの番号があり、目標を整理するのに役立つ
    - ?設定を消したり編集したりすることはできるのか。消したらidはどうなるのか
    - スロットidは別の目標とまとめるときは別のスロットを選ぶことができる ?
  - タイプを選択する:
    - 到達ページ: 手続き完了など特定のページに到達したとき。これを選んだ時しかファネル分析は行われない
    - 滞在時間: セッションの長さを計測する
    - ビュー数: 1回のセッションで表示されたページ数
    - イベント: 特定のアクションを起こしたとき(音楽の再生、など)
  - 注文完了ページのリンク先urlを入力する
    - 正規表現も使える
    - 確認ボタンみたいなものがあって、ちゃんと計測できる設定になっているか確認できるようになっている
  - [option]金額を設定する
    - ?使い方
  - [オプション]ファネル分析で使うページを入力する
* 目標を設定すると、各レポートでCV率を参照することができる
* Googleアナリティクスの目標は削除できない。記録ステータスをオフにする
* 21個目を作りたくなったら不要になった目標を編集する
  - ただし目標idと目標セットは変更できない
* CVに割り当てる金額について(目標値)
  - ユーザーの目標を金額換算し、その合計金額をレポートに表示できる機能
  - 例. ニュースレターの購読登録をしたユーザーの 10% と契約が成立し、平均取引額が 50,000 円の場合は、「ニュースレターの購読登録」の目標に5000円割り当てる。もし、登録したユーザーの 1% しか契約が成立しない場合は、「ニュースレターの購読登録」の目標には 500 円を割り当てる

## 4.4 Google広告キャンペーンの測定方法
* Google広告(Adwards)とアナリティクスレポートをアカウント連携させることで見えるレポートの紹介

## 4.5 コースの復習と次のステップ
アナリティクスレポートを使って成果を改善する方法の紹介
* 例. 新規ユーザーに対して成果の高いページを確認する方法
  - サイトコンテンツ > 全てのページ セカンダリディメンションでユーザータイプ(初回orリピーター)を表示
  - 新規ユーザー獲得のサイトコンテンツとキャンペーン戦略を練る際に役立つ
* あまり効果がないランディングページを特定する
  - サイトコンテンツ > ランディングページ で直帰率を低い順になるようにソートする
* 利用中のキャンペーンのランディングページとマーケティング活動の関係を確認する
  - サイトコンテンツ > ランディングページ でセカンダリディメンションにキャンペーンもしくは参照/メディアを指定する
  - 離脱の原因となっているランディングページを調べて修正を行える
* キャンペーンの反応をデバイス別に把握する
  - 全てのキャンペーン を表示し、セカンダリディメンションにデバイスカテゴリを指定
* 地域データと目標を使ってキャンペーンの最適化を行う
  - 地域レポートを開き、CVメニューから対象CVを選択し、率の高い順に並び替える

おわりに

各レッスンの終わりについているテスト(10問程度の選択式問題)を80%以上クリアするとこんな感じの証明書がもらえます。

f:id:reiichii:20210112213736p:plain

入門編ですが、Googleアナリティクスが怖くなくなるくらいには分かった気になれました。

体型的に学べる仕組みがあるってありがたいなーって大人になってよく思います笑

Datadogの認証情報について調べたこと

Datadogの設定をTerraformで行うにあたって、application keyとapi keyが求められるのですが、そもそもDatadogにおいてのこれらは一体何なのかよくわかっていなかったことに気付かされました。

以下は調べたことのまとめです。

Application Key

  • API Keyと合わせて使うと、datadogプログラムにapi経由でアクセスできる
  • ユーザーアカウントに紐づき、ユーザーアカウントの権限と同じ権限を持つ
  • 自分が作ったものしかkey valueを確認できない
  • ユーザーのアカウントが無効になった場合はキーも削除される

API Key

  • メトリクスとイベントをdatadogに送信するには、datadogエージェントがAPIキーを必要とする
  • 組織に固有で、管理者ユーザーのみが作れる(5つまでしか作れない。引き上げも可能)
  • 作成者以外のユーザーもkey valueを参照できる
  • ユーザーのアカウントが無効にされても引き続き使える

ベストプラクティス

これらのキーはどう運用していくのがベストなのか。

公式docsでは、ユーザー間で使いまわすことは想定せず、紐付くユーザーが退職したら新しく作り直すことを推奨していました。そうすることで退職ユーザーがキーにアクセスできないようにするためです。

とはいえグループのメールアドレスを用いたサービスアカウントのような使い方も一応想定しているようでした。(認証情報を安全に保管して必要最小限のメンバーのみがアクセスできるよう気をつけてねといったことが書かれていた)

API キーとアプリケーションキー

なので例えばTerraformで管理する時なんかは、アプリケーションキーはサービスアカウントで発行したものを用いるようにし、それをリポジトリのCICDの環境変数に設定することで、その設定にアクセスできる権限を持った人しか値が見れないようにできます。そういう形になるのかな、やっぱり🤔

Datadogで外形監視の設定をした

はじめに

Datadog の Synthetic MonitoringAPI Testsを使って、APIサーバに外形監視を設定しました。

要件

今回の監視の目的は「問題があったときに素早く気づけ、エスカレーションできるようにすること」なのでとりわけ社外に公開しているエンドポイントを対象に、DBなど周辺コンポーネントをカバーできるエンドポイントをいくつかピックアップしました。

料金

2020.12.28の時点ではAPI Testsは以下のような料金体系になっています。

料金プラン | Datadog

10000リクエストで $7.20/月。年間請求にすると$5/月

1ヶ月を31日(44640min)として、1min間隔で監視を入れるとしたら年間請求計算で

1エンドポイントで44640/10000 * $5 = $22.5(1ロケーションの場合※)

のようになります。

API Testsではエンドポイントを実行するサーバの場所を指定することができます。例えば1min間隔でSingapore、Sydneyロケーションからエンドポイントチェックを行うとなると、2リクエストになります。このロケーションは書いてあるとおりAWS環境なので、サービスと同じリージョンで動かすとリージョン障害で外形が起動せず障害に気づけないといったことも起こりうるかと思います。グローバルで展開しているシステムでなくても、予算に余裕があれば2つ以上のロケーションで行いたいものです。

設定手順

UX Monitoring > Synthetics Tests でAPI Testsの設定が行えます。

f:id:reiichii:20201228190358p:plain

Define requestではurlとヘッダーやリクエストボディの内容を細かく設定できるようになっています。

{{ }} で囲うことで任意の変数を作成することができます。(他のAPI Testsを設定するときにも使いまわせるのかと思いきやできなそうだった)変数の値は入力した文字列以外にも日付や指定した数の文字列といった関数も用意されていました。

入力内容した内容を「Test URL」ボタンを押下することでテストを行うことができます。またそのレスポンス結果をもとに成功の定義が入力されるのがちょっとした感動ポイントでした笑

f:id:reiichii:20201228191416p:plain

入力フォームの右側にTest URLのレスポンス結果が出て、「2. Define assertions」にresponse timeとstatus codeとcontent-typeの成功値のデフォルトが入ります。条件を変えて再度テストするとDefine assertionsの各項目の右側にpassしたかfailedしたかが表示されるので試しながら調節できます。

f:id:reiichii:20201228192011p:plain

「3. Specify test frequency」 で指定された範囲でリクエストの頻度を指定できます。

「4. Define alert conditions」 でDefine alert conditionsで通知を出すタイミングとリトライの設定ができます。例えば画像のような設定だと、1つのロケーション中1つでfailedが出たらすぐにアラートを飛ばすようになっています。またfailedが起きたら3回リトライを行うようにもなっています。

「5. Notify your team」 では通知の設定を指定できます。Monitorsなどと同じように連携設定をしているSlackやPagerDutyも指定できます。(見た目は同じだけど操作感が若干異なるような)

設定を保存すると、保存された直後からリクエストが行われるようになりました。

f:id:reiichii:20201228192956p:plain

f:id:reiichii:20201228193007p:plain

画像にはありませんが、設定画面の右上でリクエストを一時停止したり、Test URLを意図的に実行させるなどもできました。

Datadogへの通知に関しても、failedしてから0minで届いたのが確認できました。

f:id:reiichii:20201228193827p:plain

f:id:reiichii:20201228193837p:plain

failed時の再通知の設定条件も5. Notify your teamの項目で行わなかったり、10分置きに通知するようにしたりなど設定できます。

また今回はやっていませんが、この辺りの設定もTerraformでコード化できるようでした。

datadog_synthetics_test | Resources | DataDog/datadog | Terraform Registry

おわりに

Mackerelなど他のツールは使ったことないので比較はできませんでしたが、とはいえ使い勝手は良さそうでした。リトライ時のリクエストの感覚も指定できるようになったら嬉しいなー

はじめての要件定義

今回は仕事日記です。

仕事で初めてシステムの1機能の要件定義をやることになりました。しかし私は今まで要件はまとまっていて細部や非機能要件を詰めてシステム設計するフェーズからしかやったことがありませんでした。

そこで今回ははじめて要件定義をするにあたって考えたこととして、PM経験が豊富な上司に聞いてみたことと、今回の要件定義のどう進めることにしたかという事を書きます。絶賛進行中なので良い悪いの話はまた別の機会に。

上司に聞いたことから見出したこと

要件定義のゴール

自分たちは何を作るか、依頼側と合意すること。

最終成果物

合意するためのアウトプットを提示する。

eg. 画面定義所(誰が何のために使うのか、権限、ボタンを押すとどうなるのか)

第3章 画面レイアウト

(IPAのドキュメントがありました。今回はここまで厳密にやるつもりはないのですが、何かの参考になるかもしれないのでメモ)

そしてこのアウトプットを作るために、目的の再確認をしたり、現状を把握したり、やりたいことを整理していく必要がある。そういった考えを詰めるのにUMLが使える。とりわけ上司の場合、ユースケース図でシステムがやるところとやらないところを明確にしたりすることをよく行うとのことだった。

UML入門 - IT専科

注意事項

要件をまとめていざ作ろうとすると割りに合わないくらい工数がかかってしまうこともあるので、システム設計のこともある程度一緒に考えていくのが良い。

今回の要件定義の進め方

前提

登場人物に関しては、関係者は社内の人間のみになります。

  • PDM: システムの企画をする人。カレンダーを見ると想像を絶する多忙さ
  • 先輩エンジニア: 同じチームの先輩。今回は私のサポートしてくれるポジションにある
  • 自分: この機能の開発を主体的に進めていく立場にある。今回触ることになるコンポーネントは携わったことがないので中身のことも調べつつやっていくことになりそう

機能に関しては、以下のような状態でした。

  • 以前からやりたいこととしてマイルストーンにあったもの
  • ざっくりとした要望があり、どう形に落とし込んでいくか(要件定義)はシステム側と相談しないと詰められない状態
  • この企画が作られた背景や、あるとどうユーザーにとってメリットになるのか断片的なドキュメントしかないので、チーム移動で途中参戦した自分の場合そこから把握する必要もあった
    • (余談だが、業界柄人の移り変わりも激しいのでこういった長期目線で何をやっていくべきなのかという思想が失われがち)

立てた計画

方針を立てる

ひとまず「要件定義のたたきを作ってPDMに共有。それを元に要件を固めていけるようにする」という方針を立てました。最初の共有までの期限は1週間です。今の段階ではあまり長くやっても正解にたどり着けるものではないのと、システムや機能を考えるにあたって調査の時間が欲しかったので1週間後に設定しました。そしてPDMに共有する前段階として、前日に先輩に共有して意見をもらいます。

共有用のアウトプットのフォーマットを作る

無限に時間を掛けられてしまう領域なので、とりあえずアウトプットのフォーマットを作ることにしました。今回は以下です。

機能の目的に関しては、mtgが途中参戦だったので丁寧に説明してもらう機会がありませんでした。過去ドキュメントを漁った断片情報からこうなのだろうなと思うものはあったのですが、それが合っているか確認するのも兼ねて冒頭に据えます。

想定ユースケースに関しては、とりわけ私の理解が及んでいない部分でした。実は打ち合わせした時に全然話についていけなくて内心軽くパニクってたのですが、この部分を理解していないからだったんだということにフォーマットを作っていて気づきました。 ユーザーの気持ちを考えることはできても、層が自分から離れていることもあり短い時間では浅い理解しかおそらくできないだろうなと思っています。とはいえ考えるうちに少しずつ近づけるようにもなりたいので、まずは自分で考えてそれから「こんなふうに考えてみたんですが、実際はどうなのでしょう」といった形で聞いてみようと思いました。とりわけこの部分を確認するために3日目に先輩に時間をもらうことにしました。 これも無限に悩めてしまうのでアウトプットベースで、3つのペルソナを作ってそれぞれに対して3パターンユースケースを挙げてみました。

最終成果物(画面)のイメージに関しては、今はたたきの時点なので丁寧には作りません。何かしらベースがあった方が話が進むと思うので、ipadでjamboardに絵を描いてリンクを共有する形にしました。jamboardを使うことで、修正をすぐにブラウザに反映させることができるのが良さそうでした。(実際のmtgではまだ試していない)

Google Jamboard: 共同作業に適したデジタル ホワイトボード | G Suite for Education | Google for Education

こんな感じで進めています。

おわりに

要件定義は大事で、ここをしっかりできなければ後々取り返しのつかないことになることはよく耳にしますが、実際どうやっていくのがいいのか、何に気をつけたらいいのかなど、体系的にまとまっていて初心者の手引きになるドキュメントを知りませんでした。各々の地頭を駆使して行われているようなイメージでした(そして実際そうみたいだった)。我流でやるのもいいけど、せっかく先駆者がいるのであればその人たちの学びを参考にして避けられる失敗は避けて進めたいと思っていました。

今後も要件定義をやる機会はあると思うので、なんとなくでやるよりも自分なりに要件定義との付き合い方を掴められるようになりたいものです。

GCPにて本番作業時の権限の切り替え方法について

業務でIAMの権限周りの管理を見直すことになったのですが、とりわけ掲題についてよくわかりませんでした。

結論だけ言うとGoogleグループの切り替えで行うのが主流のようでした。

ただそれにしても懸念点は残るので、以下の視点で調べたことや知っておいた方が良さそうなことをまとめます。

  • 本番、開発環境など複数環境でGCPを使用している
  • チームやIAMを作成する人数が少なく、最小限の権限を意識しつつもある程度の裁量も与えられることが可能

IAMを割り当てられるものの対象

ドキュメントではmemberと呼ばれています。これは以下の四つになります。

  • 個人のGoogleアカウント
  • Googleグループ
    • GCPとは異なる管轄のサービスになる。グループには複数のGoogleアカウントが属している
  • サービスアカウント
    • システムに割り当てるもの。(※今回は対象外)
  • Cloud Identity
  • Google Workspaceadmin

下二つのサービスは初めて聞きました。 AWSAWSだけで管理できますが、GCPGCP以外のサービスの知識も求められるので学習コストが高くなりますね。 下二つは料金が発生してしまうので一旦対象外としました。

気になるのが、本番環境にて参照時と作業時で権限を切り替える時の運用方法です。 ドキュメントだけだといまいちよくわからなかったのでコミュニティに聞いてみたところ、Googleグループを使った以下のような使われ方が主流みたいでした。

  • プロジェクトにはGoogleグループに対してIAMロールを設定するようにする
  • 開発者は普段は参照のみ権限が割り当てられたグループに所属している
  • 本番作業時、開発者は実行権限のあるGoogleグループに入り直す
  • 作業終了後、開発者は実行権限のあるグループを抜ける

グループの入り抜けに関しては、設定によって許可制にする(「組織内の誰でも参加をリクエストできる」)こともしない(「組織内の誰でも参加できる」)こともできるようでした。自チームの場合人数の関係で、承認を設けてしまうと承認者がボトルネックになって緊急時に対応が行えなくなってしまうようなことがあったらよくないなと危惧していたのですが、誰でも自由に参加退出できるようにすればその心配はなさそうです。

IAMロールには3種類ある

  • 基本ロール
    • オーナー(roles/owner)、編集者(roles/editor)、閲覧者(roles/viewer)
  • 事前定義ロール
    • 他のリソースへの望ましくないアクセスを防ぐGCP管理のrole
  • カスタムロール
    • ユーザーが設定できるもの

使い方としては、権限が大きい基本のロールは本番権限には付与しません。本番環境のメンバーには、事前定義ロールでできることを必要なものだけに制限したロールを付与するようにし、やりたいことが事前定義ロールでできない場合カスタムロールで自作するといった使い方が想定されています。 なるべく事前定義ロールを使うようにするのは、カスタムロールだと必要に応じて自分達でアップデートしていかないといけないので管理コストが多少できてしまうためです。

また閲覧権限に関して、閲覧のみと言いつつBQやGCSのデータにアクセスできてしまうなど権限が大きいものになっています。不要なデータへのアクセスも防ぎたい時はより制限されたrole/browerという参照権限を付与するのが望ましいです。

フォルダ

複数のプロジェクトをフォルダでまとめて管理することができます。フォルダを利用することにより、Googleグループを各プロジェクトではなくそのフォルダに割り当てることができるようになり、ユーザーの管理をより楽にできます。

?必要な時限定に絞るにはどうしたらいいか

Googleグループの切り替えによって必要な時だけ実行権限を持つようにできることはわかりました。ただ作業終了時に自分から抜けるか、誰かに除外してもらうかしないとずっと実行権限が持ったままになってしまいますよね。

一番望ましいやり方が、1時間など指定した時間が経過したらsession outになるようにすることですが、そういったものをどうやって実現させることができるのでしょうか。

?IAM Conditionsを使えばできる

IAM Conditionsとは特定の条件下でのみ権限を得るように設定できる項目のことです。条件は時間やアクセス元のリソース、IPなど色々ありました。

この機能を使えば実現できそうな気もします。がしかし、ドキュメントの例だと営業時間のみなど固定の日時の設定しかできないみたいです。本番作業は深夜メンテナンスや障害など営業時間以外にも起こりうるのでそれだとちょっと合いません。

この部分に関してはもう少し検証できたらと思うので、実現できそうなやり方があれば追記しようと思います。

おわりに

IAM Conditionsでなんとかやれないものだろうか...

参考資料

公式ドキュメント

非公式だけどとても参考になったドキュメント