1 Minute Tips

カテゴリー: tech

  • n日前のファイルを削除する

    n日前のファイルを削除する

    ファイルのローテーションをするために処理を書くことがある、find コマンドの -mtime オプションを使うが、このようなニーズでないと使わないのでメモ。

     find /home/hoge/backup/* -mtime +7 

    7日前のファイルが表示される。

    xargs コマンドと合わせて削除をする。

    find /home/hoge/backup/* -mtime +7 | xargs rm -f

  • ecr get-login を使わずコンテナを ECR に push する

    ecr get-login を使わずコンテナを ECR に push する

    今までは

    aws ecr get-login --no-include-email --region ap-northeast-1

    のコマンドで ECR に login して container を push することができたが、

    近年上記コマンドが実行できなくなってしまった。

    代替コマンドとして get-login-password を使うことでログインができる

    aws --profile stg ecr get-login-password | docker login --username AWS --password-stdin https://123456789.dkr.ecr.ap-northeast-1.amazonaws.com

    Login Successeded となれば成功だ

  • 標準出力と、標準エラー出力をまとめてリダイレクトする

    標準出力と、標準エラー出力をまとめてリダイレクトする

    たまに使うんだけど、順番を毎回ググって確認していた 2>&1 というリダイレクト処理がある

    いままで

    command >> word 2>&1

    という書き方で、標準出力、標準エラー出力をリダイレクトしてきたが、

    実は bash 4.0 から以下のような記載ができるようになったようだ。

    command &>> word

    man コマンドで bash を見ると以下のような記載がある

    The format for appending standard output and standard error is:

    &>>word

    This is semantically equivalent to

    >> word 2> &1

    https://www.gnu.org/software/bash/manual/html_node/Redirections.html

    これは便利なので活用していきたい。

    参考情報

    https://qiita.com/r_plus/items/41fb31285fb64fb4be85
  • Model name must be alphanumeric:

    Model name must be alphanumeric:

    API gateway にinsert する際、エラが発生

    Your API was not imported due to errors in the Swagger file.
Unable to create model for 'user_id': Model name must be alphanumeric: user_id
Unable to create model for 'staff_id': Model name must be alphanumeric: staff_id

    これは正規表現でいうところの

    [a-zA-Z0-9]+

    のみ model name としての利用を許容しており、アンダースコア含めた名前は API gateway に許容されていないため。

    swagger としては アンダースコアが利用可能なので、API gateway も許容してもらいたいところだ。。

    以下のように対処する

    paths:
  /hoge:
    post:
    requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                booking_deadline:
                  $ref: '#/components/schemas/hogeline'


components:
  schemas:
    Event:
      type: object
      properties:
        hoge_line:
          $ref: '#/components/schemas/hogeline'

  • 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

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