1 Minute Tips

カテゴリー: tech

  • DMM.com を支えるデータ駆動戦略 を読んだ

    DMM.com を支えるデータ駆動戦略 を読んだ

    誰も正解を持っていない中プロダクトを開発しなければならない。不確実性との戦いである。

    情熱を科学で支える。データ駆動戦略とは、データを駆動させることで事業の優れた価値を見つけ、組織がデータを中心に意思決定する世界。このゴールのイメージがとても重要になる。

    本書ではデータ駆動する上でスクラムなどの開発手法の話にも言及があるが、その辺はすっ飛ばして、あくまでも”データ基盤” を作る上で必要な情報のみまとめる。

    データ駆動戦略を用いた事業の捉え方と、プロセスは以下の順番を遡ると説いている。

    1. 事業でどうやって収益を得ているか知る。
      何をインプットとするか。
      インプットに対してどのような処理が行われているか
      何をアウトプットとしているか

      時には１ユーザーの売り上げベースでミクロの視点で見る必要もあり、
      合計の売り上げで見るマクロの視点で見る必要がある。

    2. その後、事業構造を KPI で表現して予測可能性を作る。
      KPI を作るにあたり、 KGI (Key Goal Indicator) の理解や、
      CSF (Critical Success Factor) に関する知識が必要。

      KGI – CSF -KPI

      といったツリー構造になる。
      　
    3. KPI から見えた課題に対して施策を実行していく。この際、費用対効果が高い KPI を選定する。

      KPI として訪問者数を目標値として老いたとする。
      キャンペーンなどの施策を行いながら、訪問者数を増やしていく。

      この時重要なのは、施策の優先順位付けに時間をかけるのではなく、
      施策の実行スピードを重要視することである。

    4. 仮説検証のサイクルを回す。必ず成功する施策はない。失敗を許容し多くの施策を回す。

      不確実性の高い事業の中で、全て成功するとは限らない。失敗を許容する仕組みを用意する

    5. KPI サイクルを高速に合理的に回す

      スピードを上げる。


    データ基盤を作る上では、まずはデータを集約することが第一歩にな理、データパイプラインが必要になる。

    データ集約は組織全体で行わないと効果が限定的になり、局所最適化になってしまう。

  • モノリスからマイクロサービスへ　を読んだ

    モノリスからマイクロサービスへ　を読んだ

    マイクロサービス化を促進させたく、また今我々がマイクロサービス化に向けてとっているアプローチが正しいのかを確認する上で本書を読むことにした。

    事前にいくつか言葉の定義をしっかりしておく必要がある。

    代表的な登場人物として、マイクロサービスと、モノリスだ。

    それぞれの定義と、メリット、作り出す問題は以下の通りだ。

    マイクロサービスについて

    マイクロサービスの定義

    ビジネスドメインに基づいてモデル化された独立してデプロイ可能なサービス

    サービス同士が疎結合である必要がある。

    マイクロサービスのメリット

    各サービスの作業を並行して行えるため、多くの開発者がお互いの作業を意識する必要がなく作業を行うことができる。

    マイクロサービスが作り出す問題

    マイクロサービスが作り出すのはメリットだけではない、

    ネットワーク通信によりサービス間の通信が発生することになり、今までの処理以上にレイテンシーはかかってしまう。

    また、サービスをまたいだデータベースのトランザクションも非常に難しい。

    マイクロサービスによるメリットをきちんと享受しないと、デメリットだけ発生する可能性もある。

    この問題に対して以下の問いに対し明確になっている必要がある。

    • 達成したいことは何か
    • マイクロサービスの他に代替案はなかったのか
    • どうすれば移行がうまく行くか分かっているか

    モノリスについて

    モノリスの定義

    マイクロサービスを語るとき、しばしばその対義語として使われることがあるが、この本ではデプロイの単位として捉えている。

    システム内の全ての機能を一緒にデプロイする必要があった時、モノリスとして表現している。

    全てのコードが単一プロセスとしてデプロイされているシステム。

    モノリスのメリット

    マイクロサービスと比べてしまうとモノリスで

    • 監視
    • トラブルシューティング
    • エンドツーエンドテスト

    などを行うのは容易と感じる。とにかく１個に集約されている状態は開発運用するのにメリットも確かにあった。

    これはマイクロサービスを運用していると、このモノリスの当たり前がいかに我々に染み込んでいたかを感じる。

    モノリスが作り出す問題

    そもそもマイクロサービスに舵を切る理由である。

    モノリスはさまざまなサービスが１つに集約されている。そのため長年運用していると機能拡張が難しくなる。

    マイクロサービス化を始める時の大切なポイント

    マイクロサービスに踏み切る際考えるべきポイント

    • 自分たちにはどれくらいの数のマイクロサービスを扱えるか
    • マイクロサービスの境界線をどのように定義するべきか。

    この辺が重要になる。

    マイクロサービスへの移行計画

    茨の道になることもある。ビジョンと戦略を生み出す必要がある。

    ビジョンとは・・・仲間を集めてどのような変化をもたらすことを望んでいるのか

    戦略とは・・・そこに到達する方法

    これらをメンバーと共有する必要がある。一人では到底難しいプロジェクトになる。

    サービスのインターフェースを定義する際に重要になるのが

    サービスがどのように利用されているかというサービス利用者の観点からサービスをデザインしていくところである。それがマイクロサービスへの道のりの一歩になる。イベントストーミングがそれになる。

    イベントストーミングとは

    技術的なステークホルダーと非技術的なステークホルダーが一緒に共有ドメインを定義する共同で行うべき作業。

    イベントストーミングはボトムアップで行う。

    システム内に発生する「ドメインイベント」を定義することから始め、

    イベントを集約にまとめ、集約を境界づけられたコンテキストへまとめていく。

    移行に於けるチェックポイントとして

    時折立ち止まって振り返るための時間を組み込むことが重要

    情報を分析し、軌道修正が必要かどうかを判断する

    マイクロサービスでのトランザクション

    ACID トランザクション（DB の一貫性を保つトランザクション）は全てのデータベースが持っているわけではない。

    解決策が２つある

    ２フェーズコミット

    投票フェーズと、コミットフェーズの２つに分ける。

    • 投票フェーズで状態の変更が可能かを確認し、レコードにロックをかける。
    • コミットフェーズで確定させる。

    サーガ

    複数の状態変更を調整できる。レコードをロックさせない。

    各ステップのビジネスを明確にモデル化させる。

    ロールバックするにはロールバック用の処理を用意する必要がある。（開発コストもリスクも高くない？）

    以上、メモ。良いマイクロサービス移行の旅を。

  • mysql で ストアドプロシージャ を登録・変更・削除する

    mysql で ストアドプロシージャ を登録・変更・削除する

    ストアドプロシージャは サーバーに格納できる一連の SQL です。これが一度登録されると クライアントは個々のステートメントを繰り返し発行す必要はなくなります。

    ユーザー作成

    ユーザーに権限を付与する

    GRANT SELECT, INSERT, UPDATE, DELETE, CREATE ROUTINE, ALTER ROUTINE, EXECUTE ON `database`.* TO 'user'@'10.1.%';

    ひとつひとつ説明する。

    SELECT, INSERT, UPDATE, DELETE これは普通の DML なので省略する。

    CREATE ROUTINE … ストアドプロシージャを作成する権限

    ALTER ROUTINE … ストアドプロシージャを削除・変更する権限

    EXECUTE … ストアドプロシージャを実行する権限

    ストアドプロシージャを登録する

    ストアドプロシージャーを実行する際、 delimiter を一時的に変更すると登録しやすい。

    delimiter // 
create procedure sample()
    -> begin
    -> select count(*) from user;
    -> end
    -> //

delimiter ;

    ストアドプロシージャを確認する

    SHOW PROCEDURE STATUS;

    SHOW PROCEDURE STATUS;
+------------------+---------+-----------+--------------------+---------------------+---------------------+---------------+---------+----------------------+----------------------+--------------------+
| Db               | Name    | Type      | Definer            | Modified            | Created             | Security_type | Comment | character_set_client | collation_connection | Database Collation |
+------------------+---------+-----------+--------------------+---------------------+---------------------+---------------+---------+----------------------+----------------------+--------------------+
| database | sample  | PROCEDURE | root@%             | 2021-06-29 14:47:44 | 2021-06-29 14:47:44 | DEFINER       |         | utf8                 | utf8_general_ci      | utf8mb4_general_ci |
| database | sample1 | PROCEDURE | user@10.1.% | 2021-06-29 14:57:08 | 2021-06-29 14:57:08 | DEFINER       |         | utf8                 | utf8_general_ci      | utf8mb4_general_ci |
+------------------+---------+-----------+--------------------+---------------------+---------------------+---------------+---------+----------------------+----------------------+--------------------+

    ストアドプロシージャを実行する

    call sample1();
+----------+
| count(*) |
+----------+
|   188376 |
+----------+
1 row in set (0.00 sec)
  • コンテナ内の mysql にリクエストされたクエリを確認する

    コンテナ内の mysql にリクエストされたクエリを確認する

    開発している際 コンテナの mysql にどのようなクエリ走ったのか確認したいことがある。

    スロークエリを 0秒に設定することで、DB にリクエストされた 全クエリを確認することができる。

    mysql> show variables like 'slow%';
+---------------------+--------------------------------------+
| Variable_name       | Value                                |
+---------------------+--------------------------------------+
| slow_launch_time    | 2                                    |
| slow_query_log      | OFF                                  |
| slow_query_log_file | /var/lib/mysql/5c364d250748-slow.log |
+---------------------+--------------------------------------+
3 rows in set (0.00 sec)

mysql>

    slow_query_log が OFF になっている場合、出力されない。

    set global slow_query_log_file = '/tmp/mysql-slow.log';
set global long_query_time = 0;
set global slow_query_log = ON;

    上記コマンドを実行し、再度確認すると、スロークエリが出力されるようになってる。

    mysql> show variables like 'slow%';
+---------------------+---------------------+
| Variable_name       | Value               |
+---------------------+---------------------+
| slow_launch_time    | 2                   |
| slow_query_log      | ON                  |
| slow_query_log_file | /tmp/mysql-slow.log |
+---------------------+---------------------+
3 rows in set (0.00 sec)

mysql>

    スロークエリが 0秒に設定されたか確認するのは

    show global variables like 'long_query_time';

    コマンドを実行する

    mysql> show global variables like 'long_query_time';
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| long_query_time | 0.000000 |
+-----------------+----------+
1 row in set (0.00 sec)

mysql>

    結果

    
SET timestamp=1624328575;
INSERT INTO `xxx_transactions` (`id`,`operation`,`request`,`requested_at`,`response`,`responsed_at`,`metadata`,`status`,`failure_code`,`failure_message`,`created_by`,`created_at`) VALUES (105,'request',NULL,NULL,NULL,NULL,NULL,'succeeded',NULL,NULL,'123456789','2021-06-22 02:22:55.1492209');

    無事流れたクエリを確認することができた。

  • 【解決法】go1.16でビルドエラー「no required module provides package github.com」が発生する場合

    【解決法】go1.16でビルドエラー「no required module provides package github.com」が発生する場合

    go1.16 で golang を書いて build すると、タイトル通りのエラーが表示された。

    調べてみると go 1.15 までは go build や go test などのコマンドを実行すると、 go.mod や go.sum の内容をよしなに更新されていたが、go 1.16 からは自動では更新されなくなったようだ。

    これを解決するには

    $ go mod tidy

    とすることで、go のモジュールに書かれている不足分のパッケージを go.mod に書き込んでくれる

    % go build -o hoge.go
main.go:7:2: no required module provides package github.com/hackebrot/turtle; to add it:
        go get github.com/hackebrot/turtle


% go mod tidy
go: finding module for package github.com/hackebrot/turtle
go: downloading github.com/hackebrot/turtle v0.1.0
go: found github.com/hackebrot/turtle in github.com/hackebrot/turtle v0.1.0
go: finding module for package github.com/hackebrot/go-repr/repr
go: finding module for package github.com/google/go-cmp/cmp
go: downloading github.com/google/go-cmp v0.5.5
go: downloading github.com/hackebrot/go-repr v0.1.0
go: found github.com/google/go-cmp/cmp in github.com/google/go-cmp v0.5.5
go: found github.com/hackebrot/go-repr/repr in github.com/hackebrot/go-repr v0.1.0

% go build -o hoge.go

    参考情報

    https://golang.org/ref/mod#go-mod-tidy

  • bashで入力の冗長を減らす

    bashで入力の冗長を減らす

    何かと bash/zsh で作業していると、直近の引数を再度入力したくなることがある。
    たとえば、ディレクトリを作って、その中に移動する場合などだ。

    実は bash や zsh には直前の引数を再度入力する特殊変数が存在する。

    % pwd   
/tmp

    この /tmp ディレクトリから新規ディレクトリを作成し、そこに移動する場合、
    このように表現することで移動することができる。

    % mkdir hoge; cd $_ 
% pwd
/tmp/hoge

    $_ という変数が特殊変数という扱いになり、直前の引数を再度入力することができる。

  • fargate platform 1.4 で service を起動できない

    fargate platform 1.4 で service を起動できない

    今まで fargate で service を動かせていたが、platform 1.4 では動かせないことがあった。その対処法を紹介。

    pseudoTerminal option があるが、falase だと起動した後に停止してしまう。解決策としては、

    pseudoTerminal を false から true にすること。

    そもそも pseudoTerminal とは擬似ターミナル。

    Docker Remote API の コンテナを作成する際、セッションの TTy にマッピングして docker run にマッピングするオプション。

    1.3 まではこの設定が false でも動かすことができたが、1.4 ではこれを true にしないと動かすことができないようだ。

  • ECS(fargate) 起動時間をスケジュール設定する

    ECS(fargate) 起動時間をスケジュール設定する

    はじめに

    fargate でサービスを運用していて、夜間サービスを停止したい時がある。オートスケールの設定を流用することで、夜間停止を行うことができる。

    オートスケール設定

    aws application-autoscaling  \
register-scalable-target  \
--service-namespace ecs  \
--resource-id service/{cluster-name}/{service-name}  \
--scalable-dimension ecs:service:DesiredCount  \
--min-capacity 0  \
--max-capacity 1

    停止スケジュール
    (スケジューリング機能を使い、MinCapacity を 0 にする)

    aws application-autoscaling put-scheduled-action \
--service-namespace ecs \
--resource-id service/{cluster-name}/{service-name} \
--scheduled-action-name poweroff-hogehoge \
--schedule "cron(00 10 ? * * *)" \
--scalable-dimension ecs:service:DesiredCount \
--scalable-target-action MinCapacity=0,MaxCapacity=0

    起動スケジュール

    aws application-autoscaling put-scheduled-action \
--service-namespace ecs \
--resource-id service/{cluster-name}/{service-name} \
--scheduled-action-name poweron-hogehoge \
--schedule "cron(30 0 ? * MON-FRI *)" \
--scalable-dimension ecs:service:DesiredCount \
--scalable-target-action MinCapacity=1,MaxCapacity=1
  • AWS Directory Service について

    AWS Directory Service について

    AWS では Active Directory / LDAP アプリケーションは大きく３つ存在している。全ての説明は Classmethod 社の記事がわかりやすかったので引用する。

  • ALB の設定を aws cli で確認する

    ALB の設定を aws cli で確認する

    １コマンドで確認することができる。

    aws --profile stg elbv2 describe-load-balancers --load-balancer-arns arn:aws:elasticloadbalancing:ap-northeast-1:01234567:loadbalancer/net/tsukadanlb/a1b2c3d4e5

    結果は以下の通り

    {
    "LoadBalancers": [
        {
            "LoadBalancerArn": "arn:aws:elasticloadbalancing:ap-northeast-1:708179590705:loadbalancer/net/tsukadanlb/a1b2c3d4e5",
            "DNSName": "tsukada-nlb-a1b2c3d4e5.elb.ap-northeast-1.amazonaws.com",
            "CanonicalHostedZoneId": "a1b2c3d4e5",
            "CreatedTime": "2019-06-06T11:01:01.615000+00:00",
            "LoadBalancerName": "tsukada-nlb",
            "Scheme": "internal",
            "VpcId": "vpc-a1b2c3d4e5",
            "State": {
                "Code": "active"
            },
            "Type": "network",
            "AvailabilityZones": [
                {
                    "ZoneName": "ap-northeast-1c",
                    "SubnetId": "subnet-a1b2c3d4e5",
                    "LoadBalancerAddresses": []
                },
                {
                    "ZoneName": "ap-northeast-1a",
                    "SubnetId": "subnet-a1b2c3d4e5",
                    "LoadBalancerAddresses": []
                }
            ],
            "IpAddressType": "ipv4"
        }
    ]
}