継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

『コネヒトマルシェオンライン』で会社でのデータ活用に向けての取り組みを発表した

タダです.

2/25 開催のコネヒトさんのイベント『コネヒトマルシェオンライン「機械学習・データ分析」』で LT 発表させてもらいました.5分の発表だったので発表中に触れられなかった話をこの記事で書いていきたいと思います.

connehito.connpass.com

発表資料

発表資料はこちらです.

発表の振り返り

発表は以前の AWS DevDay Online で発表していたものをアップデートした内容なんですが,当時は改善をし始めたばかりの頃であまり運用での課題はでていませんでした.Athena でのデータ分析業務を回せるかをやってみたものの変数が使えないことがネックで書き直しのコストがあがって分析業務が回らなかったり,当時 Athena の利用するための専用ツールを入れてなかったため非エンジニアの学習コストが高くなり,メンバーのフォローも足りず結局使われなくなっていきました.

そこで,①データ分析業務における Athena の課題を潰しつつ,②様々なデータソースに対応した非エンジニアも使えるツールを導入していけないかと検討しました.結果として①Athena -> BigQuery への置き換え,②redash の導入をしていきました.特に redash をいれたのにはもう1つ理由があり,個々人で管理している SQL や閲覧が必要なデータを redash 上に集約して全員が見える状態にしていくのを目指しました.これでredash を中心にして社内のチームで見るデータを集約し,全員の視線を集めデータドリブンな動きがしやすくなるような形を目指していきます.

ただ,複雑なクエリを実行したら他のクエリが実行されずに詰まったり,今は EC2 1台で運用しているので可用性も低いです.社内での redash 活用が広がってきたのでこれらの課題はなんとかしていきます.

SQL 勉強会も非エンジニアの方々も興味持ってくれて参加率が高いので,内容もなるべく実務につながるよう実業務で使っているデータを使った演習を組み込んで毎週開催しています.演習の正答率をみたり,業務での SQL 周りの困り事をできる限り解消して勉強会を通じて狙った効果の実現をやってきます.

SQL 勉強会のモチベーションは Mackerel CRE を担当されている吉田さんにインスパイアされています.先日の OSO 2020 の発表も組織内でのデータ活用をしていく活動はとても良かったのでみてない方は一度ご覧ください! www.yasuhisay.info

まとめ

会社でのデータ活用をよりよくしていくための取り組み2つを発表させていただきました.まだまだ課題の改善も克服しなければならないこともあるので引き続き活動続けて行きます!今回発表の機会をいただきありがとうございました😌

Aurora MySQL でレプリケーションを行うためにバイナリログを有効化する

タダです.

Aurora MySQL のデータを DMS でのレプリケーションをやりたいと思い,バイナリログを有効化する機会がありました.初めてやったので設定について振り返っていきます.なお,Aurora のバージョンは 5.6.mysql_aurora.1.22.2で確認してます.

DB クラスターパラメーターグループの binlog_format を編集する

Aurora MySQL でバイナリログを有効化する方法として,DB クラスターパラメーターグループの binlog_format を編集する必要があります.パラメーターとしてROW/MIXED/STATEMENTがあります.変更前は下記のようになっていました.

mysql> show global variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | OFF   |
+---------------+-------+
mysql> show variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | STATEMENT|
+---------------+-------+

DMS でのレプリケーションにおいてはバイナリログは ROW で設定することがドキュメントで記載されていたので ROW を設定しています.

Set the binlog_format parameter to "ROW".

docs.aws.amazon.com

binlog_format 設定変更後の作業

binlog_format 変更後は WRITER 側を再起動する必要があります.再起動後,再度パラメーターを確認するとlog_binbinlog_formatのパラメーターが変わりバイナリログが出力されたのを確認できます.

mysql> show global variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.01 sec)
mysql> show variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
1 row in set (0.00 sec)
mysql> show binary logs;
+----------------------------+-----------+
| Log_name                   | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000001 |       120 |
| mysql-bin-changelog.000002 |     43424 |
+----------------------------+-----------+
2 rows in set (0.00 sec)

まとめ

Aurora MySQL でのバイナリログの有効化方法とその作業後の確認した点をまとめました.データベースでのオペレーションは経験値が低い分学びが多いので記録する記事を残していければと思います.

コンテナを使って gsutil で S3 のデータを GCS に同期してみる

タダです.

S3 から GCP のストレージサービスである GCS に対してオブジェクトを同期させたいことがあり,定期実行させるし Fargate に登録して処理させることにしたのでその設定をまとめていきます.

S3 から GCS への同期手法

S3 から GCS への同期手法としてgsutilを使ってみました.ZOZO Technologies さんのブログでも出ていたので自分もこの記事で初めて知り,AWS CLI の s3 コマンドのようにコマンドラインで GCS へアクセスできるツールだと感じました.データの同期だけをしたいだけなのでこのツールを使おうと思い,ZOZO Technologies さん同様にrsyncコマンドでやってます.

cloud.google.com

cloud.google.com

関連記事

techblog.zozo.com

Fargate に登録する Dockerfile の作成

Fargate で使う Dockerfile を作っていきます.コンテナイメージは google/cloud-sdk を使いました.このコンテナイメージの中にgsutilも入っていますし,BigQuery のコマンドのbq も入っているので使っています.S3 から GCS への同期をするための関連処理をスクリプトにまとめて関連のパッケージをいれていきました.

FROM google/cloud-sdk:alpine

RUN apk update && \
    apk upgrade && \
    apk add --no-cache bash python3 python3-dev py3-pip jq
RUN yes|pip3 install awscli 
COPY xxx.sh xxx.sh

RUN chmod +x xxx.sh
ENTRYPOINT ["./xxx.sh"]

スクリプトでハマったこと

スクリプトではざっくりと S3 バケットと GCS バケットの情報に加え,プロジェクト名やサービスアカウントの JSON 情報を Secret Manager などに保存していたのを値を取得しつつ,次のようなコマンドを実行しています.

gsutil rsync -r -d s3://S3BUCKET/xxx gs://GCSBUCKET/

ただ gsutil の実行してもエラーが出て実行ができずハマったのですが,.botoファイルが必要でアクセスキーやシークレットアクセスキーの情報を記載しなければいけませんでした..botoファイルへの定義をスクリプト実行時のみで設定してタスクを実行するようにして同期ができるようになりました.

cloud.google.com

まとめ

S3 から GCS にデータ同期をする時にコンテナでやってみたのでその内容をまとめてみました.普段 AWS をよく触るのですが,GCP も触ってみて初めてばかりで新鮮な経験ができました.同期したデータを BigQuery にも使い始めてみたのですが,課題がでてきているので今度は BigQuery の記事をかけたらなと思います.

AWS CLI で AWS SSO を使うための方法を確認した

タダです.

AWS SSO を経由で AWS CLI コマンドを実行することが増えてきて設定方法を確認したので備忘録として記事にまとめていきます.

事前準備

事前準備として AWS CLI のバージョンを2を使う必要があり,導入しておきます.

この機能は、AWS CLI バージョン 2 でのみ使用できます。

次の機能は、AWS CLI バージョン 2 を使用している場合にのみ有効です。AWS CLI バージョン 1 を使用している場合には無効です。

docs.aws.amazon.com

SSO の設定

導入後,SSO の設定をしていきます.aws configure sso コマンドを実行します.するとウィザードに沿って設定していき,最初 SSO の認証画面に遷移します.

 aws configure sso
SSO start URL [None]: https://xxx.awsapps.com/start#/
SSO Region [None]: ap-northeast-1
Attempting to automatically open the SSO authorization page in your default browser.

f:id:sadayoshi_tada:20210213131926p:plain f:id:sadayoshi_tada:20210213131936p:plain

認証が終わると,他の後続設定を行って aws s3 ls --profile xxxx のところまでいけば終わりです.

There are 5 AWS accounts available to you.
Using the account ID xxxx
There are 2 roles available to you.
Using the role name "xxxx"
CLI default client Region [ap-northeast-1]:
CLI default output format [json]:
CLI profile name [xxxx]:

To use this profile, specify the profile name using --profile, as shown:

aws s3 ls --profile xxxx

~/.aws/config に次の定義が追加されます.

[profile xxx]
sso_start_url = https://xxx.awsapps.com/start#/ #SSO のユーザーポータルを指す URL
sso_region = ap-northeast-1 #SSO のリージョン 
sso_account_id = xxx #アカウント
sso_role_name = xxx #スイッチロール名
region = ap-northeast-1 #CLI のデフォルトリージョン
output = json #出力形式

SSO のサインインと一時認証情報の取得

初期設定したあとに SSO のサインインして認証情報の取得を行ってみます.下記のコマンドを実行して行います.

aws sso login --profile xxx
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:

https://device.sso.ap-northeast-1.amazonaws.com/

Then enter the code:

xxxx-xxxx
Successully logged into Start URL: https://xxx.awsapps.com/start#/

まとめ

備忘録として AWS CLIAWS SSO を使った設定と一時認証情報の取得をやってみました.AWS SSO を使っている場合特にお世話になりそうな部分なのでまとめてみました!

関連ドキュメント

docs.aws.amazon.com

AWS SAM と GitHub Actions を使った Lambda のデプロイフローの検証をしてみた

タダです.

業務で Lambda をデプロイを独自スクリプトと CodePipline,CodeBuild を使っていたのですが,開発チームとの相談を経て置き換えを図ろうとGitHub Actions を使ったデプロイフローを検証する機会があったのでこの記事に検証した内容をまとめます.

検証概要

Lambda のコードを管理しているリポジトリでは,以下のようなトップディレクトリ配下に関数ごとにディレクトリがあります.その中に AWS SAM のコードやアプリケーションのコードが入っているような構造になっているのですが,このコードが上位のブランチと差分があるものだけデプロイしたいと思い,検証しました.

.
├── README.md
├── lambdaA-functions
│   ├── README.md
│   ├── __init__.py
│   ├── xxx
│   │   ├── __init__.py
│   │   ├── app.py
│   │   └── requirements.txt
│   └── template.yaml
├── lambdaB-functions
│   ├── README.md
│   ├── __init__.py
│   ├── xxx
│   │   ├── __init__.py
│   │   ├── app.py
│   │   └── requirements.txt
│   └── template.yaml
└── lambdaC-functions
    ├── README.md
    ├── __init__.py
    ├── events
    │   └── event.json
    ├── xxx
    │   ├── __init__.py
    │   ├── app.py
    │   └── requirements.txt
    └── template.yaml

GitHub Actions の定義外観

GitHub Actions の定義としては以下のようなものにしました.

YAML の定義

on:
  pull_request:
    paths:
      - '**app.py'

env:
  TARGET_BRANCH: ${{ github.base_ref }}

jobs:
  sam-test:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout'
        uses: actions/checkout@v2

     - name: 'Fetch'
        run: git fetch --depth 1 origin ${TARGET_BRANCH}

      - name: Set up Python ${{ matrix.python-version }}
        uses: actions/setup-python@v2
        with:
          python-version: '3.7'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install awscli
          pip install aws-sam-cli

      - name: Configure AWS credentials for prod
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION}}

      - name: Build & Deploy
        run: |
          for FILE in $(git diff origin/${TARGET_BRANCH} HEAD --diff-filter=AM --name-only -- "*app.py") ; do
            cd $(dirname ${FILE}); cd ../
            STACK_NAME=`pwd | awk -F "/" '{ print $NF }'`
            sam build --use-container
            sam package --template-file template.yaml --output-template-file packaged.yaml --s3-bucket ${{ secrets.AWS_SAM_BUCKET }} --region ${{ secrets.AWS_REGION}}
            sam deploy --template-file packaged.yaml --stack-name ${STACK_NAME} --s3-bucket ${{ secrets.AWS_SAM_BUCKET }} --region ${{ secrets.AWS_REGION}} --capabilities CAPABILITY_IAM
            cd ../
          done

処理の大枠

検証なのでプルリクのどんなイベントでもトリガーするようになっています.プルリクが走ったらpathで指定した AWS SAM のapp.pyに変更があるかをみるようにしています.

push および pull_request イベントを使用する場合、1 つ以上の変更されたファイルが paths-ignore にマッチしない場合や、1 つ以上の変更されたファイルが、設定された paths にマッチする場合にワークフローを実行するように設定できます。 タグへのプッシュに対して、パスのフィルタは評価されません。

docs.github.com

on:
  pull_request:
    paths:
      - '**app.py'

処理の中身ですが,デプロイにあたって予め, AWS CLIAWS SAM CLI を入れたり,クレデンシャル情報をsecrets設定から読み込む処理をしています.

jobs:
  sam-test:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout'
        uses: actions/checkout@v2
      - name: Set up Python ${{ matrix.python-version }}
        uses: actions/setup-python@v2
        with:
          python-version: '3.7'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install awscli
          pip install aws-sam-cli

      - name: Configure AWS credentials for prod
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION}}

そして,肝心のビルドやデプロイ部分ですが,処理は上位ブランチと差分があるapp.pyファイルの1つ上の階層のディレクトリに移動してビルドとデプロイ処理が走るようにしています.この辺の差分をチェックする処理を@yutaka0m さんのブログを参考にさせていただきました! ありがとうございます 🙇‍♂️

     - name: 'Fetch'
        run: git fetch --depth 1 origin ${TARGET_BRANCH}
~中略~
      - name: Build & Deploy
        run: |
          for FILE in $(git diff origin/${TARGET_BRANCH} HEAD --diff-filter=AM --name-only -- "*app.py") ; do
            cd $(dirname ${FILE}); cd ../
            STACK_NAME=`pwd | awk -F "/" '{ print $NF }'`
            sam build --use-container
            sam package --template-file template.yaml --output-template-file packaged.yaml --s3-bucket ${{ secrets.AWS_SAM_BUCKET }} --region ${{ secrets.AWS_REGION}}
            sam deploy --template-file packaged.yaml --stack-name ${STACK_NAME} --s3-bucket ${{ secrets.AWS_SAM_BUCKET }} --region ${{ secrets.AWS_REGION}} --capabilities CAPABILITY_IAM
            cd ../
          done

参考記事

tech.yutaka0m.com

まとめ

AWS SAM と GitHub Actions を使った Lambda のデプロイフローを検証してみたのでその内容まとめてみました.GitHub Actions で変更したコードをデプロイできるようになったのでフロー切り替えに適用していきたいと思います.

関連記事

sadayoshi-tada.hatenablog.com