1 Minute Tips

月: 2021年6月

  • 「いちプレーヤー」から「マネージャー」に頭を切り替える思考法 リーダーの仮面 を読んだ

    「いちプレーヤー」から「マネージャー」に頭を切り替える思考法 リーダーの仮面 を読んだ

    さまざまなリーダーシップや組織論についての本があるが、本屋さんの中で平積みされていたので気になっていた本。

    「素顔」のままで疲れ果てるか、「仮面」をかぶり、生まれ変わるか。

    という背表紙の一文にはドキッとさせられる。

    本書に書かれていたことと、私自身の経験も照らし合わせながらまとめていこうと思う。

    リーダーの責務の一つに

    部下を成長させ、チームの成果を最大化させることがある。

    リーダーがチームの成果を最大化させるためにリーダが見るべきポイントはわずか５つだけである。

    この５つのポイントにフォーカスし、それ以外のことは任せる、見守る、スルーするようにする。選択と集中。まさにそのように感じた。

    組織マネジメントには数学や物理のように公式のような決められた型がある。

    トラブルに見舞われ、リーダーとしてどう振る舞えばいいか悩むことに出くわすが、この５個に立ち返るだけで良い。自分の所感も含めて記す。

    1. ルール

    場の空気ではなく、言語化されたルールをつくることが重要だ。

    ルールを作り、それを守らせるのがリーダーのすべきこと。

    ルールを作って、規則正しく動くのであれば精神的に疲れることもない。

    ルールを作る際は、主語を明確にするのがポイント。

    ルールが重要であり、他人に「気遣い」を期待することなどあってはならない。

    他人に期待してしまい、それが期待通りされなかった時は辛い。

    最初から「気遣い」などに期待しないと割り切ることが重要。本当に必要であればそれはルールに盛り込むことだと説いている。

    2. 位置

    対等ではなく、上下の立場でコミュニケーションする

    責任者がハッキリしていないと部下は働きにくい。

    3. 利益

    人間の魅力ではなく、利益の有無で人を動かす

    みんなで利益を目指せば迷子にならない。これはとても重要なことであり、目的が一緒であれば手段は部下に選ぶ裁量渡しても良いのではないかと個人的には思う。

    チーム全員を「組織の利益」に向かせるための仕組みがとても重要。

    「成長」という利益を追い求める限り、会社との利益相反を起こさず永遠に利益を得続けることができる。

    4. 結果

    プロセスを評価するのではなく、結果だけを見る

    5. 成果

    目の前の成果ではなく、未来の成長を選ぶ

    総括として、いかなる時も個人的な感情は決して表に出さない。

    ルールに基づいてチームを動かし、そして結果だけをみて冷静に評価する。

    本書では 1on1 などのコミュニケーションも否定しているし、合う人合わない人が明確に分かれそうだ。しかし中間管理職として疲弊する人にとっては、このような考え方もあるのかと非常に勉強になった。

    そもそもリーダーシップとは？

    またリーダーシップと、マネジメントについては鴨頭さんの動画が非常にわかりやすかった。

    リーダーシップとは

    マネジメントはこちら

    同じ動画（開始位置が違うだけ）なのでサムネが一緒になってしまっているが。

    自分はこの表現がとてもわかりやすかったので紹介。

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

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

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

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

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

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

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

    マイクロサービスの定義

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

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

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

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

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

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

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

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

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

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

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

    モノリスについて

    モノリスの定義

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

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

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

    モノリスのメリット

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

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

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

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

    モノリスが作り出す問題

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

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

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

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

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

    この辺が重要になる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    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');

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