1 Minute Tips

IDEA Note

  • Micro Instance with burstable CPU running in Americas

    個人で利用している GCP で、ある時予算の 50% に達したというメールが届いた。

    調べてみると

    Micro Instance with burstable CPU running in Americas

    という項目で課金が発生していた。

    自分が使っていたサービスは

    Google Cloud の Google Compute Engine にはAlways Freeによる無料枠でサーバ１台たてていた。

    GCE の無料枠として、f1-microというインスタンスタイプのサーバーとしてを無料で利用することができる。

    ただし、運用するには弱小すぎるので実際にはサーバーとしては使えず、私のように勉強用サーバーとして使う人が多いだろう。

    今回の件で掘り下げて調べてみると、原因はfi-micro に備わっている CPU バーストという機能ということがわかった。

    https://cloud.google.com/compute/docs/machine-types#cpu-%E3%83%90%E3%83%BC%E3%82%B9%E3%83%88

    > N1: f1-micro、g1-small 共有コア VM には、短時間のバーストに使用できる 1 個の vCPU があります。

    なんらかのきっかけで CPU が足りなくなると勝手に課金し、バーストしてくれるらしい。

    今回のアラート設定していたので3日目には気付きましたが、この設定してなかったら来月月初の請求書で気づくことになったと思います。

    無料枠とはいえ料金のアラート設定は大事ですね。それでは。

  • curl: (60) SSL: no alternative certificate subject name matches target host name ‘127.0.0.1’

    curl コマンドで https 接続する際

    curl: (60) SSL: no alternative certificate subject name matches target host name '127.0.0.1'

    というエラーになることがある。

    これは証明書の URL と、リクエストURL が一致しないことによる 証明書のエラーになる。

    curl コマンドの場合 -k オプションでエラーを無視することができる

    curl -k

  • M1 mac で Dockerを使ってMySQL 5.7を外部から接続できるように設定する

    M1 mac で Dockerを使ってMySQL 5.7を外部から接続できるように設定する

     

    Dockerを使ってMySQL 5.7を外部から接続できるように設定する

    Dockerを使ってMySQLを簡単に起動する際、外部からの接続設定にちょっとしたコツが必要です。

    この記事では、その手順をシンプルにまとめています。

    1. 概要

    基本的には、MySQLの設定を変更して、どのホストからでも接続を受け入れるようにする必要があります。加えて、Dockerコンテナ内のMySQLユーザー設定も変更する必要があります。

    2. 手順

    以下のコードを実行します:

    git clone https://github.com/GitSumito/CodeArsenal.git
    cd CodeArsenal/mysql-external-access
    sh ./main.sh

     

    3. 詳細な手順の説明

    1. custom_my.cnf という設定ファイルを作成し、MySQLがどのホストからでも接続を受け入れるように bind-address を設定します。
    2. DockerでMySQLを起動します。この際、上で作成した custom_my.cnf をMySQLの設定ディレクトリにマウントします。
    3. MySQLが完全に起動するのを待ちます（この例では30秒待機していますが、環境によっては調整が必要です）。
    4. docker exec を使用してMySQLコンテナ内でユーザー設定を行います。この例では、任意のホストからの接続を受け入れるrootユーザーを作成しています。

    4. 注意点

    この設定は開発やテスト環境での利用を想定しています。セキュリティの観点から、本番環境での利用は推奨しません。特に、パスワードなしのrootユーザーを外部から接続できるようにする設定は、公開環境での利用は避けてください。

  • aws cli コマンドを実行するとamazon/aws-cli コンテナが起動するようにする

    .zshrc に alias を登録するだけ

    alias aws='docker run --rm -i -v ~/.aws:/root/.aws -v $(pwd):/aws --env AWS_PAGER="" amazon/aws-cli'

    当然 docker などがインストールされている必要がある。

  • 「一番伝わる説明の順番」を読んだ

    一番伝わる説明の順番

    読むきっかけ

    「塚田さんの話しは点であって、線になってないからわかりにくい」と言われた事が一番の動機。

    説明の仕方を学んだことがなかった気がするので、改めて勉強することにした。

    よくあること

    • シンプルな話しを複雑に伝えてしまう
    • 言いたいことはあるが、どう伝えたらいいかわからない

    これを改善したい。

    わかりやすい説明の順番

    相手がどういう主張をしているのか、自分と食い違っているのかを察して柔軟に説明方法を変化させる。

    説明には２種類ある

    • 自分主導の説明
    • 相手主導の説明

    それぞれの特徴は以下の通り

    自分主導の説明

    プレゼンテーションなど、ゼロから組み立てる説明。

    1. 前提をそろえる
      これから話す内容について、相手がどの程度のレベルの知識を持っているか

      前提となる情報を共有できているか（過去の経緯、履歴。数字の定義など）
      今日はどこまで話すか
    2. 結論・主張・本質
      一言でいい
    3. 根拠・理由・事実
      根拠・理由は３つ話す。
      ロジックを強くするのは、どれだけ事実を調べられるか。
      政府や大手企業の公開資料を味方につけるとよい。
    4. 補足情報
      多すぎてもいけない。
    5. 結論・相手に促したいアクション
      最後にまとめる言葉で相手の印象が変わる。

    相手主導の説明

    相手から質問され、説明を求められるなどの問いに答える説明。

    • 大きいポイントから、小さいポイントの順番で説明する。
      事実であることが重要になる。
    • 相手が知りたいのは、自分の解釈なのか、事実かを見極めて、相手の聞きたい方から話す。
    • 事実を話す際は客観的なものから話す。

    優先順位をつけて、捨てる
    優先順位の最上位は「相手が知りたいこと」
    これに関係しない情報は捨てる

    「自分の思考」を整理するコツ

    以下のステップでまとめる

    1. 相手の知りたいことを明確にする
      なにが一番知りたいか
    2. 自分の知りたいことを明確にする
      伝えたい内容の中に、相手にどう動いて欲しいのかを含める。
      仕事のコミュニケーションは人に動いてほしいというのが源泉にあるはず。
    3. 情報のギャップがないかを確認する
    4. ギャップを埋めるために、なにが必要かを考える

    「相手の思考」を整理するコツ

    自分が強い立場に置かれているのか、弱い立場に置かれているのかで違う。

    自分が強い立場の時

    過去の自分を思い出す。

    相手の気持ちに配慮する必要がなく、忖度の必要がない。

    自分が弱い立場の時

    相手が求めているものを想像する

    印象に残る伝え方のコツ

    伝えたい情報をどれだけ詳しく持っているか。

    自分の持っている情報量でしか話せない。

  • S3 バケットに対して特定IP からのみ接続を許可する

    バケットに接続できる IP を絞りたいことがある。バケットポリシーを記載することで制御可能なので方法を紹介。

    ブロックパブリックアクセス (バケット設定)

    ブロックパブリックアクセスはすべてオフにする

    バケットポリシー

    バケットポリシーの設定は以下の通り

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::tsukada-hoge-js",
                "arn:aws:s3:::tsukada-hoge-js/*"
            ],
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "1.1.1.111/32",
                        "2.2.2.222/32"
                    ]
                }
            }
        }
    ]
}

    ポイントとして、

    Resource にバケット自体を宣言するのとは別にバケット配下を /* でワイルドカードで指定する必要があるという点だ。

  • EBS でパフォーマンスをあげるには

    ストライピングする

    EBS はストライピングすることができ、最大で 60,000 MB/s を出すことができる。

    ただし、パフォーマンスはボリュームサイズによって比例するとのこと。

    注意点

    SSD のボリュームに対してバースト機能は存在しない

    参考情報

    https://aws.amazon.com/jp/ebs/faqs/

  • EFS のバーストスループットについてまとめる

    EFS のファイルシステムは

    • バーストスループット
    • プロビジョニングされたスループット

    の 2 つある。それぞれの特徴をまとめる。

    バーストスループット

    EFS のスループットは、ストレージクラスのファイルシステムのサイズが大きくなるにつれて上昇する。

    100G使っているファイルシステムの場合、

    バーストスループットでは 1日あたり 72分間のみ 300M/s の読み込みをできる。

    （通常モードは 15M/s）

    プロビジョニングされたスループット

    保存されたデータ量とは別に、

    ファイルシステムのスループット (MiB/秒) を簡単にプロビジョンされる。

    1日1回動くバッチ処理などのような、瞬間的に使うような使われ方をする場合は、バーストスループットを選ぶとメリットを享受できそうだ。

    参考情報

    https://docs.aws.amazon.com/ja_jp/efs/latest/ug/performance.html

    https://docs.aws.amazon.com/ja_jp/efs/latest/ug/storage-classes.html

  • S3 のバケットを誤って公開した場合の検知方法

    S3 のバケットを誤って公開してしまった時、どのように検知するかをまとめた。

    案は２つ

    1. Lambda を呼び出して、 S3 バケットを保護する CloudWatch Events ルールを設定
    2. S3 のオブジェクトレベルのログを有効にして、 CloudTrail でパブリック読み取りアクセス許可を持つ PutObject API が検出されたとき、 SNS に通知するような CloudWatch イベントを作る。

    この２つの方法は取ることができるが、単純に案1 の s3 から Lambda をトリガーしてチェックを行うのは実装は簡単そう。

    しかし、やろうと思えば案2 の仕組みをつくることもできる。

  • AWS CLI で CloudWatch logs を見る

    CloudWatch logs を確認したいが、AWS コンソール に入らずとも CLI で確認することができる。

    $ aws --profile stg logs get-log-events --log-group-name /ecs/hogehoge --log-stream-name ecs/stream --output text

EVENTS  1628662114657   COPY FROM S3.   1628662110415
EVENTS  1628662114657   logs ......       1628662111623
EVENTS  1628662404609   running...................................................................................................................................................................................................................................................................................................      1628662401927
EVENTS  1628662404609   処理時間：289.469252秒  1628662401927

    1行目は EVENTS

    2行目は タイムスタンプ

    3行目にログが記載されている。

    https://docs.aws.amazon.com/cli/latest/reference/logs/get-log-events.html