nikaeraの投稿 - Crieit

📔 ECS Fargate のメトリクスを Prometheus Agent 使って AMP に送って Grafana で監視する

2021-12-19T01:01:44+09:00

はじめに

この記事は AWS Advent Calendar 2021 の 5 日目の記事です。

Fargate で Node.js アプリのメトリクスを Prometheus Agent をサイドカーコンテナとして動かして、Amazon Managed Service for Prometheus (AMP) に送信して Grafana で見られるようにしてみました。

ちなみに Promethus Agent はまだ実験的な機能なため、実務での利用は推奨しません。

本記事の環境構築には AWS CDK を利用しています。

動作環境

Node.js v16.13.0
AWS CDK 2.0.0 (build 4b6ce31)
Prometheus 2.32.1

環境構築

AWS CDK で環境構築する

CDK で構築作業を進めます。まずは下記コマンドで CDK プロジェクトを作成します。使用言語は TypeScript を選択します。

mkdir prometheus-agent-test && cd prometheus-agent-test
cdk init --language typescript

まず CDK でインフラ構築を進めていく前に、メトリクス収集テスト用の Node.js アプリを準備します。

ECS Fargate で動かす Node.js アプリを準備する

prom-client を利用して、Node.js のメトリクスが取得できるだけの Node.js アプリを準備します。prometheus-agent-test フォルダで下記コマンドを実行します。

mkdir metrics-app && cd metrics-app
npm init -y
npm install --save prom-client

次に metrics-app フォルダ内に index.js を作成して下記を編集します。

// metrics-app/index.js
"use strict";

const http = require("http");
const server = http.createServer();

const client = require("prom-client");
const register = new client.Registry();

// 5秒間隔でメトリクスを取得する
client.collectDefaultMetrics({ register, timeout: 5 * 1000 });

server.on("request", async function (req, res) {
  // /metrics にアクセスしたら、Prometheus のレポートを返す
  if (req.url === "/metrics") {
    res.setHeader("Content-Type", register.contentType);

    const metrics = await register.metrics();
    return res.end(metrics);
  } else {
    return res.writeHead(404, { "Content-Type": "text/plain" });
  }
});

server.listen(8080);

node index.js コマンドを実行して http://localhost:8080/metrics にアクセスしてみます。下記のように各種メトリクスが出力されている様子が確認できれば OK です。

Prometheus のレポートが正常に出力されている様子

今回は ECS 上で Node.js アプリを動作させるため、Dockerfile も作成します。

# metrics-app/Dockerfile
FROM public.ecr.aws/docker/library/node:16-alpine3.12 AS builder

EXPOSE 8080
WORKDIR /usr/src/app

COPY package*.json ./
RUN npm install --max-old-space-size=4096

COPY . .

CMD [ "node", "index.js" ]

上記 Dockerfile 作成後、再び動作検証のため下記コマンドを実行してから、http://localhost:8080/metrics にアクセスしてみます。

docker build -t prometheus-agent-test/metrics-app .
docker run -p 8080:8080 prometheus-agent-test/metrics-app:latest

先ほどと同様に http://localhost:8080/metrics アクセス時に各種メトリクスが出力されている様子を確認できれば OK です。

Node.js アプリを監視する Prometheus Agent を準備する

まずは Prometheus 関連ファイルを配置するためのフォルダを作成します。prometheus-agent-test フォルダ内で下記コマンドを実行します。

mkdir prometheus-agent && cd prometheus-agent

次に Prometheus の設定テンプレートファイルを作成します。テンプレートファイルは sed を利用して中身の __TASK_ID__ および __REMOTE_WRITE_URL__ を書き換えて利用します。

# prometheus-agent/prometheus.tmpl.yml
global:
  scrape_interval: 5s
  external_labels:
    monitor: "prometheus"

scrape_configs:
  - job_name: "prometheus-agent-test"
    static_configs:
      - targets: ["localhost:8080"]
        labels:
          # デフォルトの localhost:8080 がインスタンスとして利用されると、
          # メトリクスの判別がしづらくなるため ECS Task の ID を利用する
          instance: "__TASK_ID__"

remote_write:
  # AMP ワークスペース作成時に控えておいた、
  # `エンドポイント - リモート書き込み URL` を設定する箇所
  - url: "__REMOTE_WRITE_URL__"
    sigv4:
      region: ap-northeast-1
    queue_config:
      max_samples_per_send: 1000
      max_shards: 200
      capacity: 2500

設定ファイルの作成が完了したら、テンプレートファイルを利用して Prometheus の設定ファイルを作成し、Prometheus Agent を起動させるためのシェルスクリプトを作成します。

# prometheus-agent/docker-entrypoint.sh
#!/bin/sh

while [ -z "$taskId" ]
do
  # ECS Fargate で起動したタスク ID を取得する
  taskId=$(curl --silent ${ECS_CONTAINER_METADATA_URI}/task | jq -r '.TaskARN | split("/") | .[-1]')

  echo "waiting..."
  sleep 1
done

echo "taskId: ${taskId}"
echo "remoteWriteUrl: ${REMOTE_WRITE_URL}"

# タスク ID `taskId` および、環境変数 `REMOTE_WRITE_URL` で、
# Prometheus のテンプレートファイル `prometheus.tmpl.yml` の内容を書き換え、
# その結果を `/etc/prometheus/prometheus.yml` に出力する
cat /etc/prometheus/prometheus.tmpl.yml | \
    sed "s/__TASK_ID__/${taskId}/g" | \
    sed "s>__REMOTE_WRITE_URL__>${REMOTE_WRITE_URL}>g" > /etc/prometheus/prometheus.yml

# --enable-feature=agent で Prometheus を Agent モードで起動する
# Prometheus のコンフィグファイルには上記で出力した `/etc/prometheus/prometheus.yml` を利用する
/usr/local/bin/prometheus \
    --enable-feature=agent \
    --config.file=/etc/prometheus/prometheus.yml \
    --web.console.libraries=/etc/prometheus/console_libraries \
    --web.console.templates=/etc/prometheus/consoles

これで Prometheus Agent 起動のための準備は整ったため、最後に Dockerfile を準備します。ちなみに Prometheus Agent は v2.32.0 以降で利用可能です。本記事では v2.32.1 を利用します。

# prometheus-agent/Dockerfile
FROM --platform=arm64 alpine:3.15

ADD prometheus.tmpl.yml /etc/prometheus/

RUN apk add --update --no-cache jq sed curl

# ARM64 で動作する Prometheus v2.32.1 を curl でダウンロード展開する
RUN curl -sL -O https://github.com/prometheus/prometheus/releases/download/v2.32.1/prometheus-2.32.1.linux-arm64.tar.gz
RUN tar -zxvf prometheus-2.32.1.linux-arm64.tar.gz && rm prometheus-2.32.1.linux-arm64.tar.gz

# `prometheus` コマンドを `/usr/local/bin/prometheus` に移動する
RUN mv prometheus-2.32.1.linux-arm64/prometheus /usr/local/bin/prometheus

COPY ./docker-entrypoint.sh /
RUN chmod +x /docker-entrypoint.sh
CMD ["/docker-entrypoint.sh"]

ここまでで CDK でインフラ整備を進めていくための下準備は完了です。

ECS Fargate 上で Node.js アプリおよび Prometheus Agent を動作させる

あとは CDK で ECS Fargate 上で Node.js アプリおよび Prometheus Agent、Grafana を動作させるための環境を整備していきます。

lib/prometheus-agent-test-stack.ts の内容を書き換えます。

// lib/prometheus-agent-test-stack.ts
import { Construct } from "constructs";
import {
  Stack,
  StackProps,
  aws_ecs as ecs,
  aws_logs as logs,
  aws_aps as aps,
  aws_ecs_patterns as ecs_patterns,
  aws_iam as iam,
  aws_elasticloadbalancingv2 as elbv2,
  Duration,
  CfnOutput,
} from "aws-cdk-lib";

export class PrometheusAgentTestStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    // Node.js アプリに ecs_patterns.ApplicationLoadBalancedFargateService を利用して ALB 経由でアクセス可能にする
    const projectName = "prometheus-agent-test";
    const fargateService =
      new ecs_patterns.ApplicationLoadBalancedFargateService(
        this,
        `${projectName}-fargate-service`,
        {
          serviceName: `${projectName}-fargate-service`,
          cpu: 256,
          desiredCount: 3,
          listenerPort: 80,
          taskImageOptions: {
            family: `${projectName}-taskdef`,
            image: ecs.ContainerImage.fromAsset("metrics-app"),
            containerPort: 8080,
            logDriver: ecs.LogDrivers.awsLogs({
              streamPrefix: `/${projectName}/metrics-app`,
              logRetention: logs.RetentionDays.ONE_DAY,
            }),
          },
          cluster: new ecs.Cluster(this, `${projectName}-cluster`, {
            clusterName: `${projectName}-cluster`,
          }),
          memoryLimitMiB: 512,
        }
      );
    fargateService.targetGroup.configureHealthCheck({
      path: "/metrics",
      timeout: Duration.seconds(8),
      interval: Duration.seconds(10),
      healthyThresholdCount: 2,
      unhealthyThresholdCount: 4,
      healthyHttpCodes: "200",
    });

    // 本質ではないが、Gravition2 で動作させたいために RuntimePlatform のプロパティを上書きしている
    const fargateServiceTaskdef = fargateService.taskDefinition.node
      .defaultChild as ecs.CfnTaskDefinition;
    fargateServiceTaskdef.addPropertyOverride("RuntimePlatform", {
      CpuArchitecture: "ARM64",
      OperatingSystemFamily: "LINUX",
    });

    // AMP への書き込み権限を付与する
    fargateService.taskDefinition.taskRole.addManagedPolicy(
      iam.ManagedPolicy.fromAwsManagedPolicyName(
        "AmazonPrometheusRemoteWriteAccess"
      )
    );

    // (2021/12/18) Amazon Managed Service for Prometheus のワークスペースを作成して、Prometheus の remote-write URL を取得する
    const apsWorkspace = new aps.CfnWorkspace(
      this,
      `${projectName}-prom-workspace`,
      {
        alias: `${projectName}-prom-workspace`,
      }
    );
    const apsWorkspaceRemoteUrl = `${apsWorkspace.attrPrometheusEndpoint}api/v1/remote_write`;

    // (2021/12/18) 本記事で頻出する "エンドポイント - リモート書き込み URL" をコンソールに出力する
    new CfnOutput(this, "prom-remote-write-url", {
      value: apsWorkspaceRemoteUrl,
      description: "Prometheus Workspace の remote-write URL",
      exportName: "PromRemoteWriteURL",
    });

    // AMP へメトリクス情報を送信するための Prometheus Agent コンテナを追加する
    const containerName = `${projectName}-prometheus-agent`;
    fargateService.taskDefinition.addContainer(containerName, {
      containerName,
      image: ecs.ContainerImage.fromAsset("prometheus-agent"),
      memoryReservationMiB: 128,
      environment: {
        // (2021/12/18) CDK 経由で作成した Prometheus の remote-write URL を設定する
        REMOTE_WRITE_URL: apsWorkspaceRemoteUrl,
      },
      logging: new ecs.AwsLogDriver({
        streamPrefix: `/${projectName}/prometheus-agent`,
        logRetention: logs.RetentionDays.ONE_DAY,
      }),
    });

    // Grafana のタスク定義を作成する
    const grafanaDashboardTaskDefinition = new ecs.FargateTaskDefinition(
      this,
      `${projectName}-grafana-taskdef`,
      {
        family: `${projectName}-grafana-taskdef`,
      }
    );
    // Grafana のタスクが Prometheus Query を叩けるように権限付与する
    grafanaDashboardTaskDefinition.taskRole.addManagedPolicy(
      iam.ManagedPolicy.fromAwsManagedPolicyName("AmazonPrometheusQueryAccess")
    );

    // Grafana のコンテナを追加する。パスプレフィクスには dashboard を設定する
    const grafanaDashboardContainerName = `${projectName}-grafana-dashboard`;
    grafanaDashboardTaskDefinition.addContainer(grafanaDashboardContainerName, {
      containerName: grafanaDashboardContainerName,
      image: ecs.ContainerImage.fromRegistry("public.ecr.aws/ubuntu/grafana"),
      environment: {
        AWS_SDK_LOAD_CONFIG: "true",
        GF_AUTH_SIGV4_AUTH_ENABLED: "true",
        GF_SERVER_SERVE_FROM_SUB_PATH: "true",
        GF_SERVER_ROOT_URL: "%(protocol)s://%(domain)s/dashboard",
      },
      portMappings: [{ containerPort: 3000 }],
      memoryLimitMiB: 512,
      logging: new ecs.AwsLogDriver({
        streamPrefix: `/${projectName}/grafana-dashboard`,
        logRetention: logs.RetentionDays.ONE_DAY,
      }),
    });

    const grafanaDashboardServiceName = `${projectName}-grafana-dashboard-service`;
    const grafanaDashboardService = new ecs.FargateService(
      this,
      grafanaDashboardServiceName,
      {
        serviceName: grafanaDashboardServiceName,
        cluster: fargateService.cluster,
        taskDefinition: grafanaDashboardTaskDefinition,
        desiredCount: 1,
      }
    );

    // Grafana のタスクを ALB のターゲットグループに紐づける
    fargateService.listener.addTargets(
      `${projectName}-grafana-dashboard-target`,
      {
        priority: 1,
        conditions: [elbv2.ListenerCondition.pathPatterns(["/dashboard/*"])],
        healthCheck: {
          path: "/dashboard/login",
          interval: Duration.seconds(10),
          timeout: Duration.seconds(8),
          healthyThresholdCount: 2,
          unhealthyThresholdCount: 3,
          healthyHttpCodes: "200",
        },
        port: 3000,
        protocol: elbv2.ApplicationProtocol.HTTP,
        targets: [grafanaDashboardService],
      }
    );
  }
}

その後、cdk deploy でインフラを構築します。

CDK によるインフラ構築が正常に実行された時の様子

デプロイが正常に完了したのを確認したら、Outputs に出力されている PrometheusAgentTestStack.prometheusagenttestfargateserviceServiceURL<識別子> の URL 末尾に /metrics を付与してアクセスしてみます。 出力されている URL のフォーマットは http://<識別子>.ap-northeast-1.elb.amazonaws.com になります。

つまり、http://<識別子>.ap-northeast-1.elb.amazonaws.com/metrics にアクセスします。

ALB 経由で Node.js アプリにアクセス可能なことを確認する

また、Outputs に出力されている PrometheusAgentTestStack.promremotewriteurl は後に利用する エンドポイント - リモート書き込み URL で使用するので控えておきます。

ここまでで AWS CDK でのインフラ構築作業は完了しました。最後に Grafana で AMP のメトリクスを可視化するための作業を進めていきます。

Grafana で Prometheus (AMP) のメトリクスを可視化する

先ほどの /metrics パスへのアクセス同様、Outputs に出力されている URL の末尾に /dashboard/login を付与してアクセスします。Grafana の初期ユーザおよびパスワードは admin となります。

つまり、http://<識別子>.ap-northeast-1.elb.amazonaws.com/dashboard/login にアクセスしてみます。

ログイン情報が正しければ、新しいパスワードを設定する画面に遷移するので新たなパスワードを入力してログインを終えます。ログイン後は、Prometheus (AMP) をデータソースとして追加するために下記の操作を行います。

Data sources をクリックする" />
1. 歯車アイコンをクリックして Data sources をクリックする

Add data source ボタンをクリックする" />
2. Add data source ボタンをクリックする

3. データソースとして Prometheus を選択する

4. Prometheus をデータソースとして追加する

Prometheus (AMP) に送信したメトリクスを Grafana で可視化するための準備が整ったので、実際に Grafana のダッシュボードでメトリクスを可視化してみます。手っ取り早くメトリクスを可視化するため、ダッシュボードには NodeJS Application Dashboard を利用します。

Import をクリックする" />
1. + アイコンをクリックして、Import をクリックする

NodeJS Application Dashboard の ID を入力して Load ボタンをクリックする" />
2. NodeJS Application Dashboard の ID を入力して Load ボタンをクリックする

NodeJS Application Dashboard のインポートを完了する" />
3. 必要な情報を入力して NodeJS Application Dashboard のインポートを完了する

4. ダッシュボードから Node.js アプリのメトリクスが確認できる

ここまでの手順でメトリクスの可視化は完了しましたが、負荷に応じて実際にメトリクスが変化する様子も確認してみます。Vegeta を利用して、実際に負荷をかけてみます。下記コマンドを実行します。

echo 'GET http://<識別子>.ap-northeast-1.elb.amazonaws.com/metrics' | vegeta attack -duration=5s | vegeta report

その後、再び Grafana のダッシュボードを見にいきます。負荷をかけた時間帯のみグラフに変化があることを確認できるはずです。

ダッシュボードの CPU 使用率のグラフに変化があったことを確認できる

おわりに

今回は ECS Fargate のメトリクスを Prometheus Agent で Amazon Managed Service for Prometheus (AMP) に送信し、それを Grafana で可視化する方法について紹介しました。

ECS のサービスでタスクを実行する場合はサービスディスカバリの利用が可能なため、Prometheus のサービスディスカバリの設定を行うことで、単一の Prometheus で全てのコンテナのメトリクスを扱うことも可能です。

また Node.js アプリを作成する際に利用した prom-client でカスタムメトリクスを作成することで、監視したい項目を自由に増やすことも可能です。

本記事が ECS Fargate を監視する際の検討材料の 1 つとなれたら幸いです。

参考リンク

📔Unity で iOS/Android アプリの設定値をセキュアに扱う方法

2021-08-16T02:31:05+09:00

はじめに

iOS/Android でユーザーの情報をセキュアに扱う必要があったので、調査したところ Android には EncryptedSharedPreferences が存在することを知りました。iOS には Keychain Services が存在します。

今回は Unity の iOS/Android プラットフォーム上で設定値を保存するための実装を行う必要があったので、Unity から扱えるようネイティブプラグインを作成しました。今後もこういった要望はありそうでしたので、記事として手順や内容を書き記しておくことにしました。

本記事内で紹介しているコードは下記にアップ済みです。

https://github.com/nikaera/Unity-iOS-Android-SecretManager-Sample

動作環境

MacBook Air (M1, 2020)
Unity 2020.3.15f2
Android 6.0 以上
- EncryptedSharedPreferences が使用可能なバージョン

Android のネイティブプラグインを作成する

Android 環境ではまず External Dependency Manager for Unity を利用して、Unity の Android ネイティブプラグインで EncryptedSharedPreferences 利用可能にします。

(追記) Gradle を利用したライブラリのインストール方法

shiena さんにご教授いただいたのですが、こちらの記事のように Gradle を利用することでも簡易にライブラリの取り込みが可能なようでした。

手順は上記の記事をご参照いただくとして、Gradle を利用する方法で外部ライブラリを取り込む際の Assets/Plugins/Android/mainTemplate.gradle および Assets/Plugins/Android/gradleTemplate.properties は下記になります。

```diff gradle:Plugins/Android/mainTemplate.gradle
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
+ implementation 'androidx.security:security-crypto:1.1.0-alpha03'
DEPS}

android {


```diff properties:Assets/Plugins/Android/gradleTemplate.properties
org.gradle.jvmargs=-Xmx**JVM_HEAP_SIZE**M
org.gradle.parallel=true
android.enableR8=**MINIFY_WITH_R_EIGHT**
+ android.useAndroidX=true
unityStreamingAssets=.unity3d**STREAMING_ASSETS**
**ADDITIONAL_PROPERTIES**

Gradle を利用した方法でライブラリを利用される際は、次の External Dependency Manager for Unity で必要なパッケージをインストールする の手順はスキップ可能です。EncryptedSharedPreferences を利用するためのネイティブコードを追加する のステップから進めてください。

External Dependency Manager for Unity を利用する方法だと、取り込み先プロジェクト内でライブラリの競合が発生する恐れがあります。Gradle を利用する方法であれば回避が可能です。¹

External Dependency Manager for Unity で必要なパッケージをインストールする

External Dependency Manager for Unity をインポートするため unitypackage をダウンロードして、EncryptedSharedPreferences を導入したい Unity プロジェクトを開いてから unitypackage をクリックすることで、External Dependency Manager for Unity を Unity プロジェクトにインポートします。

unitypackage をクリックして Unity プロジェクトに External Dependency Manager for Unity をインポートする" />

Unity プロジェクトの Build Settings からプラットフォームは Android に切り替えておきます。Enable Android Auto-resolution? というダイアログの選択肢はどちらを選んでも構いません。²

External Dependency Manager for Unity で各種パッケージを管理する方法は README に記載がある通り、*Dependencies.xml というファイルを Editor フォルダに配置することで可能になります。

今回は EncryptedSharedPreferences を導入するため、下記の xml ファイルを Editor フォルダ内に配置します。




    
        
        
            
                
                extra-google-m2repository

その後、Unity メニューから Assets -> External Dependency Manager -> Android Resolver -> Force Resolve を選択して、Assets/Editor/AndroidPluginDependencies.xml の内容を元に EncryptedSharedPreferences を利用するのに必要なパッケージを自動で Assets/Plugins/Android フォルダにダウンロードします。

Assets -> External Dependency Manager -> Android Resolver -> Force Resolve を選択する" />
1. Unity メニューから Assets -> External Dependency Manager -> Android Resolver -> Force Resolve を選択する

Assets/Plugins/Android フォルダに配置される" />
2. 実行に成功すると EncryptedSharedPreferences を利用するのに必要なライブラリ群が Assets/Plugins/Android フォルダに配置される

ここまで来ればあとは Android ネイティブコードを Assets/Plugins/Android フォルダ内に配置して Unity 側から叩けるようにするだけです。

EncryptedSharedPreferences を利用するためのネイティブコードを追加する

早速下記の Android ネイティブコードを Assets/Plugins/Android~~/SecretManager.java に配置します。

// Assets/Plugins/Android/SecretManager.java
package com.nikaera;

import com.unity3d.player.UnityPlayerActivity;

import java.lang.Exception;

// External Dependency Manager for Unity によって、
// 必要な jar が含まれているため EncryptedSharedPreferences の利用が可能になる
import androidx.security.crypto.EncryptedSharedPreferences;
import androidx.security.crypto.MasterKey;

import android.content.Context;
import android.content.SharedPreferences;
import android.content.SharedPreferences.Editor;

import android.os.Bundle;
import android.util.Log;

public class SecretManager {
  private SharedPreferences sharedPreferences;

  public SecretManager(Context context) {
    try {
        // EncryptedSharedPreferences で設定値を保存する際に用いる、
        // 暗号鍵を扱うためのラッパークラスをデフォルト設定で作成する
        MasterKey masterKey = new MasterKey.Builder(context)
                .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
                .build();

        // EncryptedSharedPreferences のインスタンスを生成する
        // コンストラクタで作成した masterKey を指定している
        this.sharedPreferences = EncryptedSharedPreferences.create(
          context, context.getPackageName(), masterKey,
          EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
          EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
        );
    } catch (Exception e) {
        e.printStackTrace();
    }
  }

  /**
   * 指定したキーで値を保存する関数
   * @param key 値を保存する際に用いるキー
   * @param value 保存したい値
   * @return boolean 値の保存に成功したかどうか
   */
  public boolean put(String key, String value) {
    SharedPreferences.Editor editor = sharedPreferences.edit();
    editor.putString(key, value);

    return editor.commit();
  }

  /**
   * 指定したキーで保存した値を取得する関数
   * `put` 関数で保存した値を取得するのに利用する
   * @param key 取得したい値のキー
   * @return string キーに紐づく値、存在しなければ空文字が返却される
   */
  public String get(String key) {
    return sharedPreferences.getString(key, null);
  }

  /**
   * 指定したキーで値を削除する関数
   * @param key 削除したい値のキー
   * @return boolean 値の削除に成功したかどうか
   */
  public boolean delete(String key) {
    SharedPreferences.Editor editor = sharedPreferences.edit();
    editor.remove(key);

    return editor.commit();
  }
}

その後、上記を Unity スクリプトから実行可能にするための C# クラスを作成します。本記事ではファイルを Assets/Scripts/EncryptedSharedPreferences.cs に配置します。

// Assets/Scripts/EncryptedSharedPreferences.cs
using UnityEngine;

/// 
///     利用するネイティブコードは Assets/Plugins/Android/SecretManager.java に記載
/// 
/// 
///     EncryptedSharedPreferences
/// 
class EncryptedSharedPreferences
{
    private readonly AndroidJavaObject _secretManager;
    public EncryptedSharedPreferences()
    {
        // コンストラクタで com.nikaera.SecretManager のインスタンス生成を行う
        var activity = new AndroidJavaClass("com.unity3d.player.UnityPlayer")
            .GetStatic("currentActivity");
        var context = activity.Call("getApplicationContext");
        _secretManager = new AndroidJavaObject("com.nikaera.SecretManager", context);
    }

    public bool Put(string key, string value)
    {
        return _secretManager.Call("put", key, value);
    }

    public string Get(string key)
    {
        return _secretManager.Call("get", key);
    }

    public bool Delete(string key)
    {
        return _secretManager.Call("delete", key);
    }
}

あとは用途に応じて下記のようなコードで設定値の保存や取得などを行えます。

// ...
var _sharedPreferences = new EncryptedSharedPreferences();

// name をキーとして値を nikaera で保存する
_sharedPreferences.Put("name", "nikaera");

// name をキーとして値を取得する
var name = _sharedPreferences.Get("name");

// "nikaera" が出力される
Debug.Log(name);

//　name をキーとして値を削除する
_sharedPreferences.Delete("name");

// ...

iOS のネイティブプラグインを作成する

iOS の場合は外部ライブラリを利用しないため、External Dependency Manager for Unity は利用しません。本来であれば Swift で信頼できる外部フレームワークを取り込み利用できると良さそうですが、今回は Objective-C でネイティブプラグインを書いていきます。³

Keychain Services を利用するためのネイティブコードを追加する

早速下記の iOS ネイティブコードを Assets/Plugins/iOS/KeychainService.mm に配置します。

// Assets/Plugins/iOS/KeychainService.mm~~
// Keychain Services を利用するために Security フレームワークを利用する
#import 

extern "C"
{
    // 指定したキーで値を保存する関数
    // - param
    //   - dataType:  値を保存する際に用いるキー
    //   - value: 保存したい値
    // - return
    //   - 保存時のステータスコードを返却する (0 以外は失敗)
    int addItem(const char *dataType, const char *value)
    {
        NSMutableDictionary* attributes = nil;
        NSMutableDictionary* query = [NSMutableDictionary dictionary];
        NSData* sata = [[NSString stringWithCString:value encoding:NSUTF8StringEncoding] dataUsingEncoding:NSUTF8StringEncoding];

        [query setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass];
        [query setObject:(id)[NSString stringWithCString:dataType encoding:NSUTF8StringEncoding] forKey:(id)kSecAttrAccount];

        OSStatus err = SecItemCopyMatching((CFDictionaryRef)query, NULL);

        if (err == noErr) {
            attributes = [NSMutableDictionary dictionary];
            [attributes setObject:sata forKey:(id)kSecValueData];
            [attributes setObject:[NSDate date] forKey:(id)kSecAttrModificationDate];

            err = SecItemUpdate((CFDictionaryRef)query, (CFDictionaryRef)attributes);
            return (int)err;
        } else if (err == errSecItemNotFound) {
            attributes = [NSMutableDictionary dictionary];
            [attributes setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass];
            [attributes setObject:(id)[NSString stringWithCString:dataType encoding:NSUTF8StringEncoding] forKey:(id)kSecAttrAccount];
            [attributes setObject:sata forKey:(id)kSecValueData];
            [attributes setObject:[NSDate date] forKey:(id)kSecAttrCreationDate];
            [attributes setObject:[NSDate date] forKey:(id)kSecAttrModificationDate];
            err = SecItemAdd((CFDictionaryRef)attributes, NULL);
            return (int)err;
        } else {
            return (int)err;
        }
    }

    // 指定したキーで値を取得する関数
    // - param
    //   - dataType: 値を取得する際に用いるキー
    // - return
    //   - キーに紐づく値、存在しなければ空文字が返却される
    char* getItem(const char *dataType)
    {
        NSMutableDictionary* query = [NSMutableDictionary dictionary];
        [query setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass];
        [query setObject:(id)[NSString stringWithCString:dataType encoding:NSUTF8StringEncoding] forKey:(id)kSecAttrAccount];
        [query setObject:(id)kCFBooleanTrue forKey:(id)kSecReturnData];

        CFDataRef cfresult = NULL;
        OSStatus err = SecItemCopyMatching((CFDictionaryRef)query, (CFTypeRef*)&cfresult);

        if (err == noErr) {
            NSData* passwordData = (__bridge_transfer NSData *)cfresult;
            const char* value = [[[NSString alloc] initWithData:passwordData encoding:NSUTF8StringEncoding] UTF8String];
            char *str = strdup(value);
            return str;
        } else {
            return NULL;
        }
    }

    // 指定したキーで値を削除する関数
    // - param
    //   - dataType:  値を削除する際に用いるキー
    // - return
    //   - 保存時のステータスコードを返却する (0 以外は失敗)
    int deleteItem(const char *dataType)
    {
        NSMutableDictionary* query = [NSMutableDictionary dictionary];
        [query setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass];
        [query setObject:(id)[NSString stringWithCString:dataType encoding:NSUTF8StringEncoding] forKey:(id)kSecAttrAccount];

        OSStatus err = SecItemDelete((CFDictionaryRef)query);

        if (err == noErr) {
            return 0;
        } else {
            return (int)err;
        }
    }
}

Keychain Services は Security フレームワークを利用するため、KeychainService.mm に対して Security フレームワークの依存関係を設定する必要があります。

KeychainService.mm で Security フレームワークの利用を可能にする" />
KeychainService.mm で Security フレームワークの利用を可能にする

その後、上記を Unity スクリプトから実行可能にするための C# クラスを作成します。本記事ではファイルを Assets/Scripts/KeychainService.cs に配置します。

// Assets/Scripts/KeychainService.cs
using System.Runtime.InteropServices;

/// 
///     実装は Assets/Plugins/iOS/KeychainService.mm に記載
/// 
/// 
///     Keychain Services
/// 
class KeychainService
{
#if UNITY_IOS
    [DllImport("__Internal")]
    private static extern int addItem(string dataType, string value);

    [DllImport("__Internal")]
    private static extern string getItem(string dataType);

    [DllImport("__Internal")]
    private static extern int deleteItem(string dataType);
#endif

    public bool Put(string key, string value)
    {
#if UNITY_IOS
        // 返却されるステータスが 0 なら成功
        return addItem(key, value) == 0;
#endif
    }

    public string Get(string key)
    {
#if UNITY_IOS
        return getItem(key);
#else
        return null;
#endif
    }

    public bool Delete(string key)
    {
#if UNITY_IOS
        // 返却されるステータスが 0 なら成功
        return deleteItem(key) == 0;
#endif
    }
}

あとは用途に応じて下記のようなコードで設定値の保存や取得などを行えます。

// ...
var _keychainService = new KeychainService();

// name をキーとして値を nikaera で保存する
_keychainService.Put("name", "nikaera");

// name をキーとして値を取得する
var name = _keychainService.Get("name");

// "nikaera" が出力される
Debug.Log(name);

//　name をキーとして値を削除する
_keychainService.Delete("name");

// ...

(余談) インターフェースで iOS/Android のふるまいを共通化する

このままだとプラットフォームを切り替える毎にコードを書き直さないとならないので、インターフェースを利用して共通化を行います。

public interface ISecretManager
{
    /// 
    /// 指定したキーで値を保存する関数
    /// 
    /// キー
    /// 値
    /// 保存に成功したかどうか
    bool Put(string key, string value); 

    /// 
    /// 指定したキーの値を取得する関数
    /// 
    /// キー
    /// 指定したキーで設定された値、無ければ null
    string Get(string key);

    /// 
    /// 指定したキーの値を削除する関数
    /// 
    /// キー
    /// 削除に成功したかどうか
    bool Delete(string key);
}

その後、Assets/Scripts/EncryptedSharedPreferences.cs および Assets/Scripts/KeychainService.cs を下記の通り ISecretManager の実装に紐付けます。

// Assets/Scripts/EncryptedSharedPreferences.cs
using UnityEngine;

/// 
///     利用するネイティブコードは Assets/Plugins/Android/SecretManager.java に記載
/// 
/// 
///     EncryptedSharedPreferences
/// 
class EncryptedSharedPreferences: ISecretManager
{
    private readonly AndroidJavaObject _secretManager;
    public EncryptedSharedPreferences()
    {
        var activity = new AndroidJavaClass("com.unity3d.player.UnityPlayer")
            .GetStatic("currentActivity");
        var context = activity.Call("getApplicationContext");
        _secretManager = new AndroidJavaObject("com.nikaera.SecretManager", context);
    }

    #region ISecretManager

    public bool Put(string key, string value)
    {
        return _secretManager.Call("put", key, value);
    }

    public string Get(string key)
    {
        return _secretManager.Call("get", key);
    }

    public bool Delete(string key)
    {
        return _secretManager.Call("delete", key);
    }

    #endregion
}

// Assets/Scripts/KeychainService.cs
using System.Runtime.InteropServices;

/// 
///     実装は Assets/Plugins/iOS/KeychainService.mm に記載
/// 
/// 
///     Keychain Services
/// 
class KeychainService: ISecretManager
{
#if UNITY_IOS
    [DllImport("__Internal")]
    private static extern int addItem(string dataType, string value);

    [DllImport("__Internal")]
    private static extern string getItem(string dataType);

    [DllImport("__Internal")]
    private static extern int deleteItem(string dataType);
#endif

    // KeychainService.mm に定義した関数を呼び出す
    #region ISecretManager

    public bool Put(string key, string value)
    {
#if UNITY_IOS
        return addItem(key, value) == 0;
#else
        return false;
#endif
    }

    public string Get(string key)
    {
#if UNITY_IOS
        return getItem(key);
#else
        return null;
#endif
    }

    public bool Delete(string key)
    {
#if UNITY_IOS
        return deleteItem(key) == 0;
#else
        return false;
#endif
    }

    #endregion
}

あとは上記をよしなに利用可能な SecretManager クラスを作成します。

// Assets/Scripts/SecretManager.cs
using UnityEngine;

/// 
///     Editor 利用時のみ PlayerPrefs を利用する
/// 
/// , 
public static class SecretManager
{
#if UNITY_EDITOR
#elif UNITY_ANDROID
        private static ISecretManager _instance = new EncryptedSharedPreferences();
#elif UNITY_IOS
        private static ISecretManager _instance = new KeychainService();
#endif

        public static bool Put(string key, string value)
        {
#if UNITY_EDITOR
                PlayerPrefs.SetString(key, value);
                PlayerPrefs.Save();

                return true;
#elif UNITY_IOS || UNITY_ANDROID
                return _instance.Put(key, value);
#else
                Debug.Log("Not Implemented.");
                return false;
#endif

        }

        public static string Get(string key)
        {
#if UNITY_EDITOR
                return PlayerPrefs.GetString(key);
#elif UNITY_IOS || UNITY_ANDROID
        return _instance.Get(key);
#else
            Debug.Log("Not Implemented.");
            return null;
#endif
        }

        public static bool Delete(string key)
        {
#if UNITY_EDITOR
            PlayerPrefs.DeleteKey(key);
            PlayerPrefs.Save();

            return true;
#elif UNITY_IOS || UNITY_ANDROID
            return _instance.Delete(key);
#else
            Debug.Log("Not Implemented.");
            return false;
#endif
        }
}

これでプラットフォーム間の実装差異を気にすることなく、下記のような記述で設定値の保存や取得などを行えます。iOS/Android 以外のプラットフォームで追加実装したい場合はプラットフォーム依存コンパイルと ISecretManager の実装クラスを新たに作成することで簡単に追加できます。

// ...
// name をキーとして値を nikaera で保存する
SecretManager.Put("name", "nikaera");

// name をキーとして値を取得する
var name = SecretManager.Get("name");

// "nikaera" が出力される
Debug.Log(name);

//　name をキーとして値を削除する
SecretManager.Delete("name");

// ...

おわりに

今回は iOS/Android で設定値をセキュアに扱うための方法についてまとめてみました。実際は Keychain Services 周りは実装が大変なので、External Dependency Manager for Unity とか使って KeychainAccess のような外部ライブラリを利用する構成のほうが良いと思われます。

本記事の内容に誤りがあったり、実際にはセキュアな実装ができていない等々あれば是非コメントでご指摘いただけますと幸いです。

参考リンク

逆に External Dependency Manager for Unity を利用する方法のメリットは、UnityPackage などでライブラリとして配布する際に、ライブラリを動作させるのに必要な外部パッケージも同梱した状態で配布が可能になるなどがあります。(当然ライセンスには気を付ける必要がありますが...) ↩︎
パッケージの依存関係を自動で解決するかどうかという選択肢になります。本記事では明示的に Resolve を実行するため Disable でも Enable でも進行上の問題はありません。 ↩︎
CocoaPods もサポートされているようなので、iOS でも Android 同様、外部ライブラリを取り込むのは簡単にできそうでした。例えば KeychainAccess とか使いたい。 ↩︎

📝 Azure Cosmos DB でソートしようとするとフリーズする

2021-07-06T00:47:48+09:00

MongoDB 用 API で Azure CosmosDB 向けの開発を行っていたのですが、sort 実行時にエラーが発生してしまいリソースが取得できなくなる問題が発生してしまいました。

結論から言ってしまうと、この Stack Overflow の回答通り対処すれば解決可能なのですが、簡易的に日本語でも解決策を記しておきます。

また、本記事内容の問題に遭遇したときに見つけたのですが、事前に Azure CosmosDB の Docker イメージを利用しておけば、CosmosDB 特有の挙動に気づけるようになるかもしれません。私は MongoDB の Docker イメージを利用して開発や動作検証を行っておりました。

公式サイトでの MongoDB 用 API でのインデックス管理についての記事を見ていくと下記の文言が出てきます。

クエリに並べ替えを適用するには、並べ替え操作で使用されるフィールドに対してインデックスを作成する必要があります。

そのため、例えば MongoDB の ORM である Mongoose の利用例でいうと、スキーマを定義する際に下記のようにソートに利用したいキーに対してインデックスを指定する必要があります。

@Schema({ timestamps: { createdAt: "created_at", updatedAt: "updated_at" } })
export class TestSchema1 extends Document {
  _id: string;

  // ソートしたいキーには index を付ける
  @Prop({ index: true })
  sort!: number;
}
const schema = SchemaFactory.createForClass(TestSchema1);
export const TestSchema1 = schema;

また、範囲検索を行いたい場合は各キーにインデックスを作成することで可能になります。

@Schema({ timestamps: { createdAt: "created_at", updatedAt: "updated_at" } })
export class TestSchema2 extends Document {
  _id: string;

  @Prop()
  start_at: Date;

  @Prop()
  end_at: Date;
}

// start_at と end_at で範囲検索を行いたいため、
// それぞれに unique インデックスを作成している
const schema = SchemaFactory.createForClass(TestSchema2)
  .index({ start_at: 1 }, { unique: true })
  .index({ end_at: 1 }, { unique: true });

export const TestSchema2 = schema;

地味な Tips のような記事ですが、割とハマりました。。この記事が同じ轍を踏んでしまっている方の参考になれれば幸いです 😇

📔 マイペースに技術研鑽を継続する方法

2021-06-26T20:44:05+09:00

Image by Hans Braxmeier from Pixabay

はじめに

技術研鑽のための行動が習慣化して確立してきたので、また困り始めた時に参照するための備忘録的な感じで、習慣化に至るまでの流れを記事化しておくことにしました。自分の中では努力していると一切感じず自然に技術研鑽及び技術者としてのプレゼンス向上のために行動できるサイクルができた印象です。

昔から色々なやり方で上記の習慣化にはトライしていたものの、全てが長続きしなかった自分でも継続できるやり方なので、ある程度の再現性はあるかもしれません。(が、あくまでも自分のやり方にはなります。。🙃

ちなみに本記事の内容を推敲していたところ、最近読んだ心理的安全性のつくりかたに出てきた 「きっかけ・行動・みかえり」 のパターンになっていることに気づきました。

技術研鑽のサイクル

自分で自分のモチベを保ちつつ、自然な技術研鑽サイクルとして定着したフローを説明していきます。

「きっかけ」：実現したい開発アイデアが浮かぶ

Image by Hans Braxmeier from Pixabay

個人的に突発的にコレ作れたら面白そうとか、自分はコレがあったら便利だなっていうアイデアが浮かぶことがあるのですが、大体そのアイデアを本気で実現したいと本当に思えるピークは体感最長でも 3-4 日くらいです。 そのため、アイデアを具体化して開発に着手するまでの期間としては 3-4 日以内を目安に考えています。

アイデアが思い浮かんでから長く期間が空いてしまい、具体化する気が無くなってしまった場合はメモアプリにアイデアをストックしておきます。 それらを見返すとより有益なアイデアが浮かんだりするので今後のきっかけ作りに有効活用できます。

また、 開発のアイデアについてですが、プライベートだけでなく仕事で開発しているシステムの新機能/改善案等もアイデアとして扱うことが可能です。 自身の仕事の質向上にもつながりますし、行動を起こすためのきっかけ作りとしても利用できて、技術検証や実装等は業務時間で行えるため割とオススメの方法です。

当たり前ですが NDA に触れるような内容を自身の成果として公開してしまうのは絶対にダメです。あくまでも一般的な技術知識のみを自身の得た知見として公開するというスタンスです。

「行動」：開発アイデアを検証可能な形で実装する

Image by Sasin Tipchai from Pixabay

開発では、とにかく動作確認が可能な形で実装を行うことに注力します。細かい設計などは置いておいて仮説検証を優先していくイメージです。 そのため、技術選定は何基準でも問題ありませんが、アイデアの内容によってそこら辺の技術基準は変えていくのが良いと考えています。

例えば、プラグインやライブラリの開発については使い慣れた言語や業務で利用している技術を選定すると、知識や知見を深めることに繋がりやすかったです。サービス開発については初期は触れる技術領域が広く浅くになりがちなので、新しい技術など使い慣れていない言語などを採用して知識や知見を広げることを意識すると最後まで楽しく開発できました。

技術研鑽という名目で取り組む開発なので、完成を目指す必要はありません。しかし、成果物として完成させることを目指したいという場合は、モチベーションを絶やさないようベースとなる機能の実装を短期間で行うことを意識します。ベースとなる機能の実装というのは、一通りそのシステムの動作検証を他者が行える状態を示します。システムの動作検証を他者が行える状態まで持っていければ、正しく成果物が評価できる状態になっているはずだからです。

まとめると、モチベを保てるやり方を意識して技術選定を行い、具体的な成果物を意識してベースとなる機能の実装を短期間の細かいサイクルで進められると、満足感のある形で開発を進めることができました。

「みかえり」：過程で得たもの全てをアウトプットする

Photo by Greg Rakozy on Unsplash

成果物の公開だけでなく、その開発を通して得た知見や知識及びソースコードなど全てアウトプットします。行動の途中だとしてもモチベが下がってきたら、みかえりのフェーズに移行します。例えば、成果物で言うと、ストア公開するだけでなくソースコードも GitHub の公開リポジトリにアップします。知識や知見などは技術ブログで記事化してまとめて公開します。 他者の目に触れる場所へ公開することを意識すると、アウトプットの質を高めるモチベに繋がります。 承認欲求を満たすためではなく、あくまで自分のアウトプットの質を高める施策の一貫として考えます。

上記を意識するとリファクタリングやベスプラに沿った開発ができているか等のチェックに繋がり、知識や知見をより深めることに繋がります。記事化も同様で、文章として知見や知識を残す過程で正しい内容なのか、本当に正しく動作するソースコードが書けているかに意識が向くため、誤った知識の修正や復習に繋がります。

成果物だけでなく身につけた技術も含めて全てをアウトプットすることで、余すこと無く行動した結果を有効活用できます。このサイクルを何回か行い習慣化してくると、インプットした内容を全てアウトプットしきるための行動が自然と起こせるようになっていきました。アウトプットする過程できっかけが生まれて更に行動することにつながっていくという流れも生まれました。

具体例としては、シンプルなプラグインを作っていく過程で、ライブラリ化やモジュール化した方が良い機能がでてきたので、別リポジトリに切り出してパッケージマネージャーからインストール可能にしました。また、業務で特殊な事情で取り組んだ開発内容を新たな知見として記事化してアウトプットを増やすことができるようになりました。

ちなみに私はアウトプットする手段としての記事化には重い腰が中々上がらない人間だったのですが、堤修一さんの Youtube 動画と同様の考え方に自然に至りました。

全てが自分のやった成果として目に見える形で残っていくので、後から見返したときに自分の実績として実感が湧きやすく、作りっぱなしで終わっていた頃と比べると相当な達成感を味わうこともできます。ゲームでいう様々な実績を解除してくような感覚に近いかもしれません。🎮

おわりに

現状個人的には上記のサイクルが上手く機能していて、最近習慣化の軌道に乗った感じが自分の中にあったので知見として記事化しておくことにしました。今後、上記サイクルについては改善を繰り返しながらアップデートしていきますが、一旦現状の内容を後から見返せるようにしました。

また今回始めて記事内でイメージ画像をふんだんに使ってみましたが、画像探すの楽しいし記事のクオリティが上がったと錯覚できるので、今後もポエム記事については積極的に画像を利用していこうと思いました (違

この記事内容がどなたかの行動を起こすきっかけとなれれば幸いです！🙏

📝 pytest で alembic のマイグレーションを行う方法

2021-06-26T20:15:08+09:00

はじめに

FastAPI と SQLAlchemy を利用して Web API 開発を行っていた際、SQLAlchemy のマイグレーションツールである alembic を利用していました。

ただ E2E テストを書こうとした際に、pytest 実行中に alembic でデータベースマイグレーションを行う方法が分からず模索していました。結果的にマイグレーションのやり方は分かったものの一応今後も利用するかもしれないため、その内容を記事として残しておくことにしました。

本記事内で利用しているソースコードを含む FastAPI プロジェクトを GitHub リポジトリ上にアップしておいたので、詳細を確認されたい方がいればご参照くださいませ。

alembic でマイグレーションを行う

conftest.py にグローバルで利用するマイグレーション用の fixture を定義すれば OK です。

# conftest.py

import os

import alembic.config
import pytest
from sqlalchemy import create_engine
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker
from sqlalchemy_utils import database_exists, create_database, drop_database

# テスト用の初期データを定義した module を import する (必要があれば)
# from .seed import users, contents


# 指定したパラメータを用いて alembic によるデータベースマイグレーションを行う
# 引数のデフォルト設定では全てのマイグレーションを実行するようになっている
def migrate(migrations_path, alembic_ini_path='alembic.ini', connection=None, revision="head"):
    config = alembic.config.Config(alembic_ini_path)
    config.set_main_option('script_location', migrations_path)
    if connection is not None:
        config.attributes['connection'] = connection
    alembic.command.upgrade(config, revision)


# テスト実行用にセットアップされたデータベースのセッション情報を扱う関数
# scope に session を指定することでテスト全体で一回だけ実行されるようにする
@pytest.fixture(scope="session", autouse=True)
def SessionLocal():
    test_sqlalchemy_database_url = os.environ['DATABASE_URL']
    engine = create_engine(test_sqlalchemy_database_url)

    # 既にテスト用データベースが存在していたら破棄する
    if database_exists(test_sqlalchemy_database_url):
        drop_database(test_sqlalchemy_database_url)

    # テスト用データベースを作成する
    create_database(test_sqlalchemy_database_url)

    # 環境変数 DATABASE_URL で指定したデータベースに対して、
    # マイグレーションを行いテスト実行に必要なテーブルを一括作成する
    # 第一引数に指定している alembic は `alembic init <環境名>` 実行時に指定した環境名を入力
    with engine.begin() as connection:
        migrate("alembic", 'alembic.ini', connection)

    Base = declarative_base()
    Base.metadata.create_all(engine)
    SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)

    # テスト用の各種データを追加する (必要があれば)
    # db_session = SessionLocal()

    # for user in users:
    #     db_session.add(user)
    # db_session.commit()

    # for content in contents:
    #     db_session.add(content)
    # db_session.commit()

    # db_session.close()

    # テスト用データ追加後のセットアップ済みの状態で
    # テスト用に利用する SessionLocal を返却する
    yield SessionLocal

    # テストが全て終わったら、テスト用データベースを破棄して、
    # SQLAlchemy のセッションも切断する
    drop_database(test_sqlalchemy_database_url)
    engine.dispose()

FastAPI の pytest への適用例

上記を関数を利用する方法は各自のテスト環境によって異なると思いますが、一応私が FastAPI のテストコードを書く際に利用したソースコードを元に参考例を載せておきます。

conftest.py と同じディレクトリに client.py を作成します。

# client.py

from fastapi import Header, HTTPException, status
from fastapi.testclient import TestClient

from app.dependencies import get_database
from app.main import app


# conftest で定義した fixture の SessionLocal を元に、
# データベースセッションを作成するための override_get_db 関数を定義して、
# get_database の代わりに override_get_db を実行するよう差し替える
def temp_db(f):
    def func(SessionLocal, *args, **kwargs):
        def override_get_db():
            db = SessionLocal()
            try:
                yield db
            finally:
                db.close()

        app.dependency_overrides[get_database] = override_get_db
        f(*args, **kwargs)
        app.dependency_overrides[get_database] = get_database

    return func

client = TestClient(app)

あとは pytest のコード内で下記のような記述を行えば、FastAPI の内部でテスト用データベースを利用してくれるようになります。

# test_main.py
from fastapi import status

from .client import client, temp_db


# temp_db fixture を定義しておくことで、
# 関数の実行中は FastAPI の内部でテスト用データベースを利用する
@temp_db
def test_read_me_token_valid():
    response = client.get("/users/me", headers={"Authorization": "Bearer 1234567890"})
    assert response.status_code == status.HTTP_200_OK

#...

参考リンク

📝 Node.js パッケージを公開するための GitHub Actions を構築する

2021-06-21T22:22:57+09:00

react-emoji-textarea の開発を行った際、リリースを作成したら自動的に Node.js パッケージにライブラリが公開される仕組みがほしいと考え、GitHub Actions でそれを実現することにしました。

その際、公式サイトに公開されている内容を参考に GitHub Actions を作成したのですが、そのまま利用すると私の環境では下記のエラーが発生してしまいました。

error Couldn't publish package: "https://registry.yarnpkg.com/@nikaera/react-emoji-textarea: You do not have permission to publish \"react-emoji-textarea\". Are you logged in as the correct user?"

上記のエラーについて調査しながら改修したところ、最終的に下記の GitHub Actions で Node.js パッケージを公開できるようになりました。secrets.NPM_TOKEN には NPM Token を登録します。

# package.yml
name: Node.js Package
on:
  # workflow_dispatch を追加して手動でも実行できるよう改修
  workflow_dispatch:
  release:
    types: [created]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: "14.x"
          registry-url: "https://registry.npmjs.org"
          # registry.npmjs.org へアクセスする際は必ず認証を試みるオプションを追加
          always-auth: true
          # scope には自分のユーザ名を指定
          scope: "@nikaera"
        # .npmrc に https://registry.npmjs.org アクセス時に利用する認証情報を記載する
      - run: echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}" > ~/.npmrc
      - name: Build react-emoji-textarea 😆💖
        run: |
          yarn install --frozen-lockfile
          yarn format
          yarn build
      - run: yarn publish --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

📝 Chrome 拡張で 1つのウインドウを使い回す方法

2021-06-21T22:21:42+09:00

Teemo という Chrome 拡張を開発したのですが、その際 1 つのウインドウを使い回す構成にしたいなと考えていました。

例えば何も考えずに chrome.windows.create を Chrome 拡張を開くたびに呼び出すと、呼び出すたびにウインドウが新規作成されてしまいます。そうすると、都度画面に不要なウインドウが出てきて邪魔になるだけでなく、手動で不要なウインドウを消す作業をユーザーに強いることとなってしまいます。。🙃

上記のような挙動が望まれるケースもあると思いますが、Teemo ではウインドウ間を頻繁に行き来するため、ショートカットを利用して拡張機能を呼び出すことを見込んでいました。そのため、ショートカットを利用して拡張機能を呼び出すたびにウインドウが新規作成され続ける挙動は望んでいませんでした。

1 つのウインドウを使い回すためには、chrome.windows.create 時に作成される window の id を保持しておきます。その後、Chrome 拡張が呼び出されるたびに window が既に存在するかどうかを保持していた id を元にチェックします。既に window が存在していた場合はそれを使いまわします。存在していなかった場合は、chrome.windows.create で window を新規作成します。

// background.js
// window の id を保持しておくための変数
let vid = -1;

chrome.browserAction.onClicked.addListener(function () {
  // vid の値を元に Chrome 拡張で開いた window の取得を試みる
  chrome.windows.get(vid, function (chromeWindow) {
    // エラーが無く、既に window が存在している場合は、
    // そのステータスを { focused: true } にすることで最前面に呼び出す
    if (!chrome.runtime.lastError && chromeWindow) {
      chrome.windows.update(vid, { focused: true });
      return;
    }

    // 上記以外のパターンでは window を新規作成する
    chrome.windows.create(
      {
        url: "index.html",
        type: "popup",
      },
      function (window) {
        // 新規作成した window を使い回せるようにするため、
        // vid 変数に window の id を保持しておく
        vid = window.id;
      }
    );
  });
});

上記コードで 1 つのウインドウを使い回すことが出来るようになるはずです。✅

📔 チャットの短文作成に便利な Chrome 拡張機能を開発してみた

2021-06-13T20:10:47+09:00

はじめに 📝

最近とある事情により Twitter の DM を利用しているのですが、Slack などのように絵文字をショートカット入力できないことにフラストレーションが溜まってきていました。そのため、絵文字をショトカで入力可能にしてくれる Chrome 拡張機能を探したのですが見つけられませんでした。

そこで、無いなら作ろうということで Teemo を開発しました。

ソースコードは GitHub 上で公開しています。何かご要望等ございましたら PR や Issue 作成頂けますと喜びます。Teemo の実際の挙動については下記の動画で確認できます 🎥

Teemo 💕 - Quickly generate chat message with embedded emoji! 💖😆

考えていたこと 💭

今回 Teemo の開発を行うに当たり、考えていた点は下記になります。

よくある : 入力からの絵文字ショートカットを導入する
- Slack や GitHub、JIRA などではおなじみの入力方法 ⌨️
パレットから選択する際は半角英数字で検索できるようにしたい
- Twitter では日本語で検索しないと絵文字が探せない 🔍
- 普段英数字で絵文字検索をするので目的の絵文字が見つけづらい 🕵️
拡張機能を利用することで文章入力の煩わしさが増加することは避けたい
- コピペや文章クリアの機能等にもショトカ利用できるようにしたい 💨

プロトタイピングしながら友人に進捗をシェアしながら開発は進めていきました。本当は個人で利用する想定で進めていたのですが、割と評判が良かったため Chrome ウェブストアに公開するのを目標に動いていました。そして、Chrome ウェブストアで公開できるクオリティを目指して動いたことで満足のいく拡張機能が作れました。

使い方 ⚒️

Teemo の使い方について紹介いたします。

Teemo を Chrome 拡張機能として追加する 🛍️

まずは Chrome ウェブストアにアクセスして、Teemo を Chrome に追加する必要があります。

1. Chrome ウェブストアにアクセスして右上の Chrome に追加 ボタンをクリックする

2. 拡張機能として Teemo の追加が完了したら、ツールバーのアイコンをクリックするか Ctrl or Cmd + Shift + O を入力して Teemo のエディタが開くことを確認する

上記確認できれば Teemo が正常に Chrome 拡張機能として追加できています。

Teemo で絵文字を `:` でショートカット入力する 💨

Teemo のエディタでは : を利用することで文章入力を止めることなく、シームレスに絵文字入力が行えます。: を入力後、関連ワードを半角英数字で入力することで絵文字候補がウィンドウ下部に表示されます。入力したい絵文字をマウスかキーボードの矢印キーで選択して入力できます。

: を入力後、関連ワードを半角英数字で入力することで絵文字候補がウィンドウ下部に表示される 💨

Teemo で絵文字をパレットから選択して入力する 🎨

絵文字をパレットから選択して入力するには Ctrl or Cmd + E キーを入力するか、ウィンドウ下部の真ん中にある 🎨 ボタンをクリックしてパレットを表示する必要があります。ちなみに絵文字選択用のパレットには OSS の Emoji Mart を利用しています。

パレットで関連ワードを入力することで絵文字検索ができる。絵文字をクリックすることで入力できる 🐱

Teemo で入力した文章をクリップボードにコピーする 📋

入力した文章は Ctrl or Cmd + C キーを入力するか、ウィンドウ下部の右にある 📋 ボタンをクリックすることで全文コピーが可能です。わざわざ範囲選択を行わずとも文章を全文コピーすることができます。コピーが正常にできるとウィンドウ下部の真ん中にある 📋 ボタンが 📋✔️ ボタンになります。

Teemo で文章入力後 Ctrl + C で全文コピー後、ツイート編集画面にペーストした時の様子 🐦

Teemo で入力した文章をクリアする 🧼

Teemo では単一のウィンドウを使い回すため、改めて文章を作成する際に一度入力した文章をクリアする必要があります。 そのため、Ctrl or Cmd + R キーを入力するか、ウィンドウ下部の左にある 🆕 ボタンをクリックすることで文章をクリアできるようにしています。

Teemo の入力欄を 🆕 ボタンをクリックしてクリアした時の様子 🧼

おわりに 🔚

個人的に Teemo のおかげで、Twitter での絵文字を利用した文章作成についてストレス無く出来るようになったので良かったです。副次的な効果として、どんなサイトでも絵文字を利用した文章作成が簡単に出来るようになったため、他に絵文字をショートカット入力できないサイトがあったとしても同様の困りごとは発生しなくなりました。☺️

SNS 上などで文章を作成する際に絵文字を頻繁に利用する方には割とご満足いただける拡張機能になっているはずです多分 🙋

📝 Rails で config/database.yml よりも ENV['DATABASE_URL'] の設定が優先される話

2021-05-30T20:49:14+09:00

MySQL を利用する Rails プロジェクトを起動しようとしたところ、下記のエラーが発生しました。

bin/rails s
# データベースアダプターには mysql2 を選択している状態なのに postgresql で接続しようとしている
Error loading the 'postgresql' Active Record adapter. Missing a gem it depends on? pg is not part of the bundle. Add it to your Gemfile. (LoadError)

# config/database.yml ファイルの中身一部抜粋

# mysql2 をデータベースアダプターとして利用しているため、
# PostgreSQL 接続のための pg ライブラリの追加を求めるエラーが発生しているのは何かおかしい。。
default: &default
  adapter: mysql2
#...

何でや、、と思い Rails のドキュメントを読んでいた所、公式サイトに Connection Preference に関する記述を見つけました。

Since pool is not in the ENV['DATABASE_URL'] provided connection information its information is merged in. Since adapter is duplicate, the ENV['DATABASE_URL'] connection information wins.

どうやら config/database.yml と ENV['DATABASE_URL'] の両方が設定されている場合、設定値に重複がある項目については ENV['DATABASE_URL'] の値が優先されるようでした。

今回は DATABASE_URL に下記の PostgreSQL URL が設定されてしまっていたため、config/database.yml では MySQL を利用していたのにも関わらず、データベースアダプターに PostgreSQL が使われてしまっていたようです。

env | grep DATABASE_URL
# 環境変数 DATABASE_URL に PostgreSQL の URL が設定されている
DATABASE_URL=postgresql://user:password@localhost:5432/something_development

そのため、DATABASE_URL の中身を空にすることで、本来の意図通りに config/database.yml の設定を反映させることができました。

# 筆者は fish を利用しているので set -e で環境変数を空にした
set -e DATABASE_URL

# 何も出力されないことを確認し DATABASE_URL が空であることを確認する
env | grep DATABASE_URL

# Rails サーバーが正常に起動するか再度確認する
bin/rails s

#...
# 無事アプリケーションサーバーが起動すること確認できれば OK
=> Booting Puma
=> Rails 6.0.3.6 application starting in development
=> Run `rails server --help` for more startup options
Puma starting in single mode...
* Version 4.3.7 (ruby 2.6.1-p33), codename: Mysterious Traveller
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://127.0.0.1:3000
* Listening on tcp://[::1]:3000
Use Ctrl-C to stop

今回はたまたま別プロジェクトでゴニョゴニョ作業をしていた名残で環境変数 DATABASE_URL が設定されてしまっていて、かつそのままの流れで Rails プロジェクトで作業していたため遭遇してしまいました。。

ローカル環境で変数を設定する際は direnv や dotenv 等を利用して極力手動では環境変数をいじらないようにしようと思いました (所感)

参考リンク

Configuring Rails Applications — Ruby on Rails Guides

GameCI で Unity の CI 環境を GitHub Actions で構築する

2021-05-26T22:30:30+09:00

はじめに

先日同僚が Unity の CI 環境を構築するためのライブラリである GameCI について教えてくれました。早速 GameCI の GitHub Actions を利用して、サンプルプロジェクトで色々動作検証してみたところ、Unity の CI 環境を楽に構築できることが分かりました。

もちろん、Unity Cloud Build を利用すれば CI 環境の構築は以前から楽にできました。しかし、選択肢の 1 つとして GameCI を持っておくことで、サクッと GitHub Actions に統合する形で Unity の CI 環境を導入できるのは他には無いメリットを感じました。

本記事で紹介しているソースコード、及び検証時に利用したプロジェクトは GitHub にアップ済みですので、手っ取り早く内容を把握されたい方は下記をご参照くださいませ。

https://github.com/nikaera/Unity-GameCI-Sample

業務でも利用できそうなので、GameCI を利用して CI 環境を構築する手順を記事でまとめました。

GameCI に備わっている機能紹介

GameCI には現状下記の GitHub Actions が用意されているようです。

機能	概要
Activation	Unity ライセンスを任意の Unity バージョンで発行する
Test runner	Unity の PlayMode 及び EditMode のテストを実行する (テスト結果の出力にも対応)
Builder	任意の Platform ビルドを実行する (アーティファクト利用でダウンロードも可能)
Returning a license	Unity ライセンスの返却ができる (Professional License のみ対応)
Remote builder	GitHub Actions のスペックでは満足のいくビルドができない際に AWS 環境でハイスペックなマシンを用意してビルドできる。ビルドのためのインフラ構築には AWS CloudFormation を使用している (現在は AWS のみ対応。今後 GCP, Azure にも対応予定とのこと)
Deployment	Unity ビルドを各種 Platform 向けにデプロイする (iOS 及び Android のみ記載あり。厳密に言うと `Builder` でビルド出力した内容を `fastlane` を用いてデプロイするためのワークフロー紹介になっている)

上記を見ると既に GameCI には開発者として Unity CI に欲しい機能は最低限揃っているように見受けられました。 また本記事では、今後機会があれば試してみたいと考えていますが Remote builder 及び Deployment については言及していません。

今回は実例を交えながら Activation 及び Test runner、Builder、Returning a license の使用方法について紹介していきます。

Activation: GameCI で必要となる Unity License のアクティベーションを行う

GameCI で Unity ライセンスをアクティベートするには Activation を利用します。早速ドキュメントの手順に沿って作業を進めていきます。

まず CI を導入したい GitHub 上の Unity プロジェクトの .github/workflows 内に Unity ライセンスアクティベート用のワークフローファイルを作成します。

# .github/workflows/activation.yml
name: Acquire activation file
on:
  workflow_dispatch: {}
jobs:
  activation:
    name: Request manual activation file 🔑
    runs-on: ubuntu-latest
    steps:
      # GameCI の Activation を利用して alf ファイルを発行する
      - name: Request manual activation file
        id: getManualLicenseFile
        uses: game-ci/unity-request-activation-file@v2
        with:
          # Unity プロジェクトのバージョンを指定する
          # ProjectSettings/ProjectVersion.txt に記載されているバージョンを入力すれば OK
          unityVersion: 2020.3.5f1
      # Upload artifact (Unity_v20XX.X.XXXX.alf)
      - name: Expose as artifact
        uses: actions/upload-artifact@v2
        with:
          name: ${{ steps.getManualLicenseFile.outputs.filePath }}
          path: ${{ steps.getManualLicenseFile.outputs.filePath }}

その後、デフォルトブランチにプッシュして GitHub Actions で実行可能にしたら、下記手順に従い Unity ライセンスファイルのアクティベート及びダウンロードを行います。

alf ファイルを生成する" />
1. ブラウザから GitHub リポジトリにアクセスして、Unity ライセンスアクティベート用のワークフローを実行して alf ファイルを生成する

2. ワークフローの実行に成功したら、該当項目をクリックして詳細画面に遷移する

Artifacts の項目から alf ファイルをダウンロードする" />
3. Artifacts の項目から alf ファイルをダウンロードする

alf ファイルをアップロードする" />
4. Unity license manual activation webpage からログインして alf ファイルをアップロードする

5. Unity ライセンスの利用用途に応じて適切な選択肢を入力する (本記事では Personal ライセンスを選択)

Download license ボタンをクリックして ulf ファイルをダウンロードする" />
6. Download license ボタンをクリックして ulf ファイルをダウンロードする

これで Unity ライセンスファイルのアクティベートは完了です。次にアクティベートしたライセンスファイルを GitHub リポジトリの Secrets に登録して、GameCI で PlayMode 及び EditMode のテストが実行できるようにしていきます。

alf 拡張子のファイルがライセンスリクエストファイルを指していて、Unity ライセンスの発行に必要となるファイルです。ulf 拡張子のファイルが Unity ライセンスのファイルです。¹

Test runner: PlayMode 及び EditMode テストを実行して結果を参照する

GitHub Actions 上でテストを実行するために、先ほどアクティベートした Unity ライセンスの情報をワークフロー上で扱えるようにする必要があります。そのため、まずは Secrets に ulf ファイルの内容を登録することから始めます。

Secrets 登録画面に遷移する" />
1. Unity ライセンスの情報登録のため、Github リポジトリの Secrets 登録画面に遷移する

Secrets の UNITY_LICENSE を参照する。そのため、Name を UNITY_LICENSE で Value に ulf ファイルの中身をコピー & ペーストしておく" />
2. GameCI はライセンス情報参照のため、デフォルト設定では Secrets の UNITY_LICENSE を参照する。そのため、Name が UNITY_LICENSE、Value には ulf ファイルの中身を登録する²

上記作業で GameCI でテストやビルド実行を行える環境が整ったので、動作検証のためテスト実行用のワークフローファイルを作成します。

# .github/workflows/test.yml
name: Run EditMode and PlayMode Test
on:
  workflow_dispatch: {}
jobs:
  test:
    name: Run EditMode and PlayMode Test
    runs-on: ubuntu-latest
    steps:
      # actions/checkout@v2 を利用して作業ディレクトリに
      # Unity プロジェクトの中身をダウンロードしてくる
      - name: Check out my unity project.
        uses: actions/checkout@v2

      # GameCI の Test runner を利用して
      # EditMode 及び PlayMode のテストを実行する
      - name: Run EditMode and PlayMode Test
        uses: game-ci/unity-test-runner@v2
        env:
          # 2. の手順で Secrets に登録した Unity ライセンスの情報を指定する
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}

          # もし Professional license を使いたい場合は、
          # メールアドレス、パスワード、シリアルナンバーを入力する必要がある
          # ref: https://game.ci/docs/github/test-runner#professional-license
          # UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          # UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
          # UNITY_SERIAL: ${{ secrets.UNITY_SERIAL }}
        with:
          projectPath: .
          # テストの実行結果もみたい場合は githubToken を指定する
          # secrets.GITHUB_TOKEN は Secrets 未登録でも利用可能
          githubToken: ${{ secrets.GITHUB_TOKEN }}

          # Unity プロジェクトのバージョンを指定する
          # ProjectSettings/ProjectVersion.txt に記載されているバージョンを入力すれば OK
          unityVersion: 2020.3.5f1

          # 実行したいテストの種類を指定できる
          # 指定可能な値は All, PlayMode, EditMode
          # testMode: All

          # テスト実行時に利用したい Docker イメージを明示的に指定できる
          # customImage: 'unityci/editor:2020.1.14f1-base-0'

      # テストの実行結果をアーティファクトにアップロードしてダウンロードして参照できるようにする
      - uses: actions/upload-artifact@v2
        if: always()
        with:
          name: Test results
          path: artifacts

上記のワークフローファイルを GitHub Actions 上で動作検証する際の手順は下記になります。

1. Unity のテストを実行するためのワークフローを選択して実行する

Test Results の項目からテストの実行結果を確認する" />
2. ワークフローの実行が成功したら、詳細画面に遷移した後、Test Results の項目からテストの実行結果を確認する

テスト実行用のワークフローファイルでは workflow_dispatch で実行可能にしていますが、pull_request を利用すればプルリク時にテストを実行させることが可能になります。

Builder: プロジェクトのビルドを実行して出力結果を確認する

GameCI にはプロジェクトのビルドを行うための GitHub Actions も用意されています。実際に GameCI で WebGL ビルドを行いその内容を GitHub Pages で確認できるようにして動作検証していきます。

早速 WebGL ビルドを行うためのワークフローファイルを作成していきます。

# .github/workflows/webgl_build.yml
name: Run the WebGL build
on:
  workflow_dispatch: {}
jobs:
  build:
    name: Run the WebGL build
    runs-on: ubuntu-latest
    steps:
      # actions/checkout@v2 を利用して作業ディレクトリに
      # Unity プロジェクトの中身をダウンロードしてくる
      - name: Check out my unity project.
        uses: actions/checkout@v2

      # GameCI の Builder を利用して、
      # Unity プロジェクトのビルドを実行する
      - name: Run the WebGL build
        uses: game-ci/unity-builder@v2
        env:
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
        with:
          # 今回は WebGL ビルドを行いたいため WebGL を指定する
          # WebGL 以外の指定可能な値は下記に記載の値が利用可能
          # ref: https://docs.unity3d.com/ScriptReference/BuildTarget.html
          targetPlatform: WebGL

          unityVersion: 2020.3.5f1
      # Builder で出力した WebGL ビルドを GitHub Pages にデプロイする
      - name: Deploy to GitHub Pages
        uses: JamesIves/[email protected]
        with:
          # GitHub Pages デプロイ用の Orphan ブランチ名を指定する
          branch: gh-pages

          # デプロイ用ビルドフォルダパスを指定する
          # GameCI の Builder はデフォルトでは build フォルダにビルド内容を出力する
          folder: build

      # Builder で出力した WebGL ビルドをアーティファクトでダウンロード可能にする
      - name: Upload the WebGL Build
        uses: actions/upload-artifact@v2
        with:
          name: Build
          path: build

上記のワークフローファイルを GitHub Actions 上で動作検証する際の手順は下記になります。

1. Unity の WebGL ビルドを実行するためのワークフローを実行する

2. ワークフローの実行が成功したら、詳細画面に遷移した後、ビルド内容が正常そうか確認する

3. ビルド内容を確認するための GitHub Pages の設定を Settings から行う

4. GitHub Pages でブラウザから WebGL ビルドの動作確認をする

上記のように Builder を利用することで WebGL ビルドの成否及び、最新のビルド内容を常に GitHub Pages で見られるようにできます。 すると WebGL ビルドが正常かどうかの確認が常に GitHub Pages を見れば把握できるようになるため、Unity1 週間ゲームジャムなどに参加する際で便利に活用できそうです。

WebGL ビルドを行う際、Unity バージョンやアセットの対応状況によっては正しくブラウザ上で動作しないビルドが出力されます。ただし、ブラウザで発生するエラー内容によっては WebGL のビルド設定を見直すだけで解決できる場合があります。 例えば unityframework is not defined というエラーが発生した際は、この記事のように WebGL の Build Settings を見直すことで解決できる場合があります。

私の環境では JamesIves/github-pages-deploy-action で GitHub Pages へのデプロイを行った際、デフォルトでは /WebGL/WebGL フォルダにビルド内容が出力されました。そのため、ブラウザから WebGL ビルドにアクセスする際、/WebGL/WebGL のような URL にアクセスする必要がありました。

Returning a license: GameCI で利用している Unity License を返却する

通常利用することは無いと公式サイトにも書かれていますが、Professional License の返却も GameCI で行うことが可能です。 今回は Personal License を利用したため使用しませんでしたが、下記をワークフローのステップに組み込むことで Professional License を返却できるようです。

# ...
# どこかのタイミングでライセンスのアクティベートを行う
- name: Activate Unity
  uses: game-ci/unity-activate@v1
  env:
    UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}

#...
# ステップの最後などに game-ci/unity-return-license@v1 を呼び出して
# アクティベート済みのライセンスを返却する
- name: Return license
  uses: game-ci/unity-return-license@v1
  if: always()
  #...

おわりに

以前 Unity コマンドを駆使して自分で CI 環境を構築した経験があるのですが、
GameCI を利用した方が全然楽に Unity CI 環境構築を GitHub Actions 上で行えました。

ちなみに GameCI で利用されている Docker イメージは以前からよく使われていた gableroux/unity3d が元になっているようでした。ってか GabLeRoux さんのホームページを見たら、GameCI の開発を始めた方のようでした。すごい。

本記事が GitHub Actions で Unity CI 環境構築を始めようとしている方の助けになれれば幸いです。

参考リンク

alf ファイル及び ulf ファイルの実態は XML ファイルです。 ↩︎
適当なテキストエディタで ulf ファイルを開き全文をコピー & ペーストします。 ↩︎

📝 Pillow を使って画像に縦書きテキストを埋め込む

2021-05-23T18:18:06+09:00

はじめに

縦書きテキストを画像に埋め込みたいと頼まれたので、
Python 製の画像処理ライブラリ Pillow を使ってサクッと実装してみました。

一応ソースコードは Gist にもアップ済みです ✍️
https://gist.github.com/nikaera/c1049708ff548b06cab0ae377adc4ac7

動作環境

Python 3.9.5
Pillow 8.2.0

画像に縦書きテキストを埋め込む

まずは今回利用する Pillow を予めインストールしておきます。

pip install Pillow

その後 main.py を作成して下記を入力します。
テキストを埋め込みたい画像を main.py と同じフォルダに sample.jpeg という名前で配置しておきます。

# main.py
# Pillow の利用するモジュールのみをインポートする
from PIL import Image, ImageDraw, ImageFont

# 読み込みたいフォント情報を入力する
font_name = "/System/Library/Fonts/ヒラギノ角ゴシック W0.ttc"
font_size = 48
font = ImageFont.truetype(font_name, font_size)

# テキストを埋め込みたい画像 sample.jpeg を読み込む
im = Image.open('sample.jpeg')
d = ImageDraw.Draw(im)

# 画像に埋め込みたいテキスト情報を入力する
# (後述するが、改行コードには未対応)
text = "bifdLcFCKXtFJZmPZhzdefjhhYTtuJPAYsR"

# 文章を改行するまでの文字数を入力する
split_number = 11

# split_number で指定した文字数ごとに分割され配列に格納される
# ref: https://qiita.com/yasunori/items/551a7c20ef9b81474e2a
splits = [text[i: i+split_number] for i in range(0, len(text), split_number)]

# 画像の width を読み込み、画像の右端の座標を取得する
# top_right_margin には余白を設定する (描画領域の端が画像の端と被ってしまうため)
w, _ = im.size
top_right_margin = 13
right_edge = w - top_right_margin

# テキストの入力領域に端が赤い四角形を描画する
d.rectangle((right_edge, top_right_margin, right_edge - font_size * len(splits), font_size * split_number + top_right_margin), fill=(255, 255, 255), outline=(255, 0, 0))

# 分割した文章を上記四角形内に左にずらしながら縦書き入力する
for index, item in enumerate(splits):
  d.text((right_edge - (font_size / 2) - font_size * index, top_right_margin), item, fill="black", anchor="mt", font=font, direction="ttb")

# 縦書きテキストを埋め込んだ画像を test.png として出力する
im.save("test.png")

上記ソースコード内で特筆すべき事項として d.text があります。¹
まず anchor オプションで文字を横中央に寄せて、縦を上端に寄せるよう設定しています。

更に direction オプションを利用することで、文字列を縦に入力しています。縦に入力するためのオプションとして ttb を入力しています。

実際に main.py を実行した際に生成される画像は下記のとおりです。

テキストを埋め込む前の画像

main.py を実行してテキストを埋め込んだ画像" />
main.py を実行してテキストを埋め込んだ画像

おわりに

今回は Pillow を用いて縦書きテキストの画像埋め込みを実装しましたが、
ブラウザベースで埋め込みをやりたい場合は html2canvas からの png 出力ダウンロードで実装できそうでした。(ただその場合は各種ブラウザ対応とかモバイル対応が大変そう。。 👀)

参考リンク

当初は multiline_text 関数を用いて改行にも対応した形でテキスト埋め込みを実装する予定でした。しかし、ValueError: ttb direction is unsupported for multiline text というエラーが発生してしまい multiline_text 関数の利用は断念しました。。😭 ↩︎

Zenn の記事を DEV に自動的に同期させる GitHub Action 作ってみた

2021-03-22T13:21:27+09:00

はじめに

去年 DEV のアカウントを作成したものの、今まで全く有効活用出来ていませんでした。

DEV にはカノニカル URL を設定出来るので、常々 Zenn の記事を投稿する際にクロスポストしたいなと考えておりました。そこで、Zenn に記事を投稿したら、自動的に DEV にも記事を投稿 & 同期する GitHub Action を作ってみました。
sync-zenn-with-dev-action

今回初めて GitHub Action を自作したのですが、その中で得た知見を残す形で記事を書くことにしました。また、GitHub Action は TypeScript で作成しました。

開発した GitHub Action の概要

まずはザッとどのような GitHub Action を作成したのか、概要について説明いたします。

GitHub リポジトリで管理している Zenn の記事を DEV に同期して投稿する GitHub Action を作成しました。 その際に DEV へ投稿する記事には Zenn の該当記事へのカノニカル URL も自動で設定できます。これにより DEV と Zenn へ記事をシームレスにクロスポストすることが可能となります。

今回作成した GitHub Action を利用するワークフローファイルの一例は下記となります。

name: "Sync all Zenn articles to DEV"
on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: checkout my project
        uses: actions/checkout@v2
      - name: dev.to action step
        uses: nikaera/sync-zenn-with-dev-action@v1
        # id を設定することで、後のジョブで Output で指定した値が参照可能になる
        id: dev-to
        with:
          # DEV の API キーを指定する
          api_key: ${{ secrets.api_key }}
          # (オプション) DEV に記事を投稿した際に Zenn のカノニカル URL を設定したい場合に指定する
          # username: nikaera
          # (オプション) 改行区切りで指定した articles フォルダ内のファイルパスを記載した txt ファイルを指定することで、記載された記事のみを同期するようになる。
          # 他プラグインと組み合わせることで差分のみを txt ファイルに載せることが可能。詳細については後述の Outputs の項目に記載。
          # added_modified_filepath: ./added_modified.txt
          # (オプション) Zenn の articles 以下全ての記事を常に DEV に同期するか指定する
          # update_all が true のときは added_modified_filepath は無視される。
          # update_all: false
        # 上記アクション実行時に DEV に新規で同期する記事に関しては Zenn のマークダウンヘッダに
        # 該当する DEV の記事の ID が dev_article_id として記載されるようになる。
        # 今後はその ID を元に同期するようになるため、該当する Zenn の記事をコミットする。
        # 新規で同期する記事が無ければ、このジョブは実行しない。
      - name: write article id of DEV to articles of Zenn.
        run: |
          git config user.name github-actions
          git config user.email [email protected]
          git add ${{ steps.dev-to.outputs.newly-sync-articles }}
          git commit -m "sync: Zenn with DEV [skip ci]"
          git push
        if: steps.dev-to.outputs.newly-sync-articles
        # Outputs には DEV の記事情報 (title, url) が含まれるようになるため、
        # 最後に出力して実行結果の内容を確認することもできる
      - name: Get the output articles.
        # dev-to という id が紐付いたジョブの Outputs を取得して echo で内容を出力する
        run: echo "${{ steps.dev-to.outputs.articles }}"

簡単に nikaera/sync-zenn-with-dev-action@v1 というジョブの内部処理について説明いたします。

Inputs の update_all 及び added_modified_filepath で受け取った情報を元に、
どの記事を DEV に同期させるか判定する
DEV に同期する記事のファイルパス一覧を取得して、
それぞれの記事のヘッダに dev_article_id の記載があるか判定する
Inputs の api_key を利用して、Zenn の記事に dev_article_id が含まれていれば、
該当する DEV の記事を更新する。含まれていなければ DEV に新規で記事を作成する
Inputs の username を利用して、
DEV の記事に該当する Zenn 記事のカノニカル URL を設定する
DEV に新規で記事を作成した場合は、
Zenn の該当記事のヘッダに dev_article_id を書き込む
DEV に記事を投稿する際、Zenn は対応しているが、
DEV では対応していない記述は削除する (::: 記法や一部のコード記法)
記事の公開ステータス及びタグなどについても DEV の記事に反映する¹
新規で DEV に記事を同期した Zenn 記事のファイルパスを、
Outputs の newly-sync-articles に設定する
(後のジョブで dev_article_id の含まれた記事をコミットしたいため)
ワークフローで同期された記事情報は Outouts の articles に設定する

Inputs と Outputs の内容一覧については下記になります。

Inputs

キー	説明	必須
api_key	DEV の API Key を設定する	o
username	Zenn の自分のアカウント名を設定する (DEV に同期する記事に Zenn のカノニカル URL を設定したい場合のみ)	x
added_modified_filepath	改行区切りで指定した articles フォルダ内のファイルパスを記載した txt ファイルを指定することで、記載された記事のみを同期するようになる。PR やコミット差分のファイルのみを取得するための GitHub Action jitterbit/get-changed-files@v1 と組み合わせることで、更新差分のあった記事のみを随時同期することも可能。² 更新差分のあった記事のみを随時同期するための実際のワークフローファイルはこちら	x
update_all	Zenn の全ての記事をどうきするかどうかを設定する。GitHub Action 初回実行時のみ true にする使い方を想定している。デフォルトは true。`added_modified_filepath` よりも `update_all` が優先されるため `added_modified_filepath` を設定する場合は false を設定する必要あり`	x

Outputs

キー	説明
articles	同期された DEV の記事のタイトル及び URL が格納された配列
newly-sync-articles	DEV で新たに新規作成された Zenn 記事のファイルパスが格納された配列。実際のワークフローファイルの該当する記述のように、必ずコミットに含めるようにする必要がある (理由は後述)

Inputs 及び Outputs については公式サイトの説明をご参照ください。

Zenn の記事を DEV に同期するための仕組み

Zenn の記事を新規で DEV に同期する際は、DEV に記事を新規作成する必要があります。その際に Zenn の記事と DEV の記事を紐付けるための何らかの仕組みが必要となります。そうしないと、今後 Zenn の記事内容を更新した際に、DEV のどの記事に内容を同期させればよいかが不明なためです。

そこで、記事を同期するための仕組みとして、dev_article_id というフィールドを Zenn のマークダウンヘッダに追記することで DEV の同期すべき記事との紐付けを行うことにしました。dev_article_id には DEV の記事作成 API 実行時の返り値である id を設定します。

一度 id を dev_article_id として Zenn の記事に紐付けてしまえば、次回以降に記事の同期を行う際は DEV の記事更新 API を利用できます。

また、Outputs の newly-sync-articles には新規で作成された DEV 記事の id である dev_article_id が追記された Zenn 記事のファイルパスが格納されています。そのため、nikaera/sync-zenn-with-dev-action@v1 実行後は、下記のように steps.dev-to.outputs.newly-sync-articles 内に格納されたファイル群をコミットに反映させる必要があります。

# `nikaera/sync-zenn-with-dev-action@v1` 実行後に必ず定義すべきジョブ
# DEV に新規に作成した記事がなければ実行しない (if: steps.dev-to.outputs.newly-sync-articles)
- name: write article id of DEV to articles of Zenn.
    run: |
        git config user.name github-actions
        git config user.email [email protected]
        git add ${{ steps.dev-to.outputs.newly-sync-articles }}
        git commit -m "sync: Zenn with DEV [skip ci]"
        git push
    if: steps.dev-to.outputs.newly-sync-articles

上記のジョブで newly-sync-articles に格納された dev_article_id が追記された Zenn 記事は随時コミットに反映しないと、Zenn の全ての記事が同期毎 DEV に新規作成され続けるという不具合を引き起こしてしまうので、ご注意ください

GitHub Action を開発する手順

サクッと開発に取り組みたかったため、Docker コンテナを利用する方法ではなく、JavaScript を利用する方法で開発を進めていくことにしました。

TypeScript で GitHub Action を作る

GitHub 公式が TypeScript で GitHub Action を作るためのテンプレートプロジェクトを用意してくれています。今回はこのテンプレートプロジェクトを利用する形でプロジェクトを作成しました。

(余談) GitHub Action では Docker コンテナを用いてワークフローを実行可能です。そのため、実行環境は自由に設定出来ます。(Go, Python, Ruby, etc.)

早速 TypeScript のテンプレートプロジェクトを元に自分の GitHub Action プロジェクトを作成します。

1. テンプレートプロジェクトを元に GitHub Action の TypeScript プロジェクトを作成する

2. プロジェクトの作成後 git clone してきて開発する準備を整える

GitHub Action プロジェクトの開発を進めるための準備を行う

テンプレートプロジェクトを git clone したら、まずは action.yml の内容を変更します。
今回作成した GitHub Action の action.yml は下記となっております。

# action.yml
# GitHub Action のプロジェクト名
name: 'Sync Zenn articles to DEV'
# GitHub Action のプロジェクト説明文
description: 'Just sync Zenn articles to DEV.'
# GitHub Action の作者
author: 'nikaera'
# GitHub Action に渡せる引数の値定義
inputs:
  api_key:
    # フィールドの指定が必須であれば true、必須でなければ false を設定する
    # DEV の API キーは同期を行う際に必須なため、true を設定している
    required: true
    # フィールドの説明文
    description: 'The api_key required to use the DEV API (https://docs.forem.com/api/#section/Authentication)'
  username:
    required: false
    description: "Zenn user's account name. (Fields to be filled in if canonical url is set.)"
  articles:
    required: false
    description: "The directory where Zenn articles are stored."
    # フィールドにはデフォルト値を指定することも可能
    # Zenn の記事がデフォで格納されているフォルダ名を指定している
    default: articles
  update_all:
    require: false
    description: "Whether to synchronize all articles."
    default: true
  added_modified_filepath:
    required: false
    description: |
      Synchronize only the articles in the file path divided by line breaks.
      You can use jitterbit/get-changed-files@v1 to get only the file paths of articles that have changed in the correct format.
      (https://github.com/jitterbit/get-changed-files)
# GitHub Action 実行後に参照可能になる値定義
outputs:
  articles:
    description: 'A list of URLs of dev.to articles that have been created or updated'
  newly-sync-articles:
    description: 'File path list of newly synchronized articles.'
# GitHub Action の実行環境
runs:
  using: 'node12'
  # テンプレートプロジェクトでは コンパイル先が dist になるため `dist/index.js` を指定している
  main: 'dist/index.js'

TypeScript のテンプレートプロジェクトでは、バンドルツールとして ncc が採用されています。GitHub Action 実行時に使用されるのは ncc によりコンパイルされた単一の JavaScript ファイル (dist/index.js) になります。

あとは src フォルダ内でプログラムを書いて、npm run all && node dist/index.js のようにコマンド実行しながら開発を進めていくだけです。

(余談) GitHub Action の開発ツールとして Docker を利用した act というものが存在するようです。ローカル環境で検証する際は既知の問題に対応する必要がありそうですが、GitHub Action の開発で非常に有効活用できそうで気になっております。

今回の開発では利用しなかったのですが、今後開発を進めていく中で利用する機会も出てきそうなので、その際は本記事内容を更新する形で知見を追記したいと考えております。

:::

GitHub Action を実装する際に利用した機能

GitHub Action を実装する際に利用した機能を、実際のコード内容を抜粋して簡単に説明していきます。下記で紹介する内容は GitHub Actions Toolkit の機能です。

/**
下記の yml の with で指定した値は core.getInput で受け取ることが可能。

- name: dev.to action step
    uses: nikaera/sync-zenn-with-dev-action@v1
    id: dev-to
    with:
        # DEV の API キーを指定する
        api_key: ${{ secrets.api_key }}
*/
core.getInput("api_key", { required: true });
core.getInput("update_all", { required: false });

/**
下記の yml の steps.<ジョブで指定した id>.outputs で参照可能な値をセットすることが可能。
セットする内容は文字列である必要がある。

- name: dev.to action step
    uses: nikaera/sync-zenn-with-dev-action@v1
    id: dev-to
- name: Get the output articles.
    run: echo "${{ steps.dev-to.outputs.articles }}"
*/

core.setOutput("articles", JSON.stringify(devtoArticles, undefined, 2));
core.setOutput("newly-sync-articles", newlySyncedArticles.join(" "));

/**
GitHub Action 実行時に出力されるログをレベルごとに出力することが可能
core.debug はローカル実行時のみに出力内容を確認することができる
*/
core.debug("debug");
core.info(`update_all: ${updateAll}`);
core.error(JSON.stringify(error));

上記だけ把握してれば GitHub Action の開発は問題なく行うことができました。

作成した GitHub Action を実際に GitHub 上で実行可能にする

ローカル環境で一通り開発が完了したら、GitHub リポジトリに push した後タグ付けを行います。GitHub Action はタグを設定しないと実行できないため必要な作業となります。 今回タグ付けは GitHub 上で行いました。

1. タグの項目をクリックする

2. Create a new release ボタンをクリックしてタグ作成画面に遷移する

3. Publish release ボタンをクリックしてタグの作成を完了する

上記の例では v1 というタグを作成したので nikaera/sync-zenn-with-dev-action@v1 のような記述で GitHub Action を利用可能になりました。 私は Zenn の記事を zenn.dev というリポジトリで管理しているため、早速このリポジトリに GitHub Action を導入してみます。

Zenn の全ての記事を DEV に同期するためのワークフロー

本記事の GitHub Action では DEV の API キーを使用するため、事前にシークレットへ API_KEY という名称で値を登録しておきます。公式サイトの手順に従いシークレットの登録が完了したら、該当リポジトリに .github/workflows/sync-zenn-with-dev-all.yml というワークフローファイルを作成します。

# .github/workflows/sync-zenn-with-dev-all.yml
name: "Sync-All Zenn with DEV"
on:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    if: contains(github.event.head_commit.message, '[skip ci]') == false
    steps:
      - name: setup node project
        uses: actions/checkout@v2
      - name: dev.to action step
        uses: nikaera/sync-zenn-with-dev-action@v1
        id: dev-to
        with:
          api_key: ${{ secrets.api_key }}
          # Zenn の自分のアカウント名を指定すると
          # DEV 記事のカノニカル URL に Zenn 記事の URL を指定できる
          # username: nikaera
          update_all: true
      - name: write article id of DEV to articles of Zenn.
        run: |
          git config user.name github-actions
          git config user.email [email protected]
          git add ${{ steps.dev-to.outputs.newly-sync-articles }}
          git commit -m "sync: Zenn with DEV [skip ci]"
          git push
        if: steps.dev-to.outputs.newly-sync-articles
      - name: Get the output articles.
        run: echo "${{ steps.dev-to.outputs.articles }}"

上記は手動実行が可能な Zenn の記事を全て DEV に同期するためのワークフローファイルになります。作成が完了したらワークフローファイルを実行して、記事が正常に同期できているか確認してみます。

1. Actions タブをクリックする

2. 作成した Sync-All Zenn with DEV ワークフローファイルを選択する

3. Run workflow ボタンを実行して、ワークフローを実行する

4. ワークフローの実行が正常に完了していれば、ログに DEV の記事情報が出力される

5. dev.to にアクセスして Zenn の記事情報が正常に同期されていることを確認する

正常に Zenn の全ての記事が DEV に同期されていることが確認できたら、次は Zenn の記事が新規作成されたり、更新されたときのみに DEV に同期するためのワークフローファイルを作成します。

更新差分のあった Zenn 記事のみを DEV に同期するためのワークフロー

main ブランチが更新されたときのみ更新された記事のみを DEV に同期するためのワークフローファイルを作成します。該当リポジトリに .github/workflows/sync-zenn-with-dev.yml というワークフローファイルを作成します。

# .github/workflows/sync-zenn-with-dev.yml
name: "Sync Zenn with DEV"
on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    if: contains(github.event.head_commit.message, '[skip ci]') == false
    steps:
      - name: setup node project
        uses: actions/checkout@v2
      - name: get modified files
        id: files
        uses: jitterbit/get-changed-files@v1
      - name: output modified files to text
        run: |
          for changed_file in ${{ steps.files.outputs.added_modified }}; do
            echo "${changed_file}" >> added_modified.txt
          done
      - name: dev.to action step
        uses: nikaera/sync-zenn-with-dev-action@v1
        id: dev-to
        with:
          api_key: ${{ secrets.api_key }}
          # Zenn の自分のアカウント名を指定すると
          # DEV 記事のカノニカル URL に Zenn 記事の URL を指定できる
          # username: nikaera
          added_modified_filepath: ./added_modified.txt
          update_all: false
      - name: write article id of DEV to articles of Zenn.
        run: |
          git config user.name github-actions
          git config user.email [email protected]
          git add ${{ steps.dev-to.outputs.newly-sync-articles }}
          git commit -m "sync: Zenn with DEV [skip ci]"
          git push
        if: steps.dev-to.outputs.newly-sync-articles
      - name: Get the output articles.
        run: echo "${{ steps.dev-to.outputs.articles }}"

上記ワークフローファイルの作成が完了したら、早速動作確認のために、まさに今執筆中の本記事内容をリポジトリに push してみます。

1. git push 後に該当するワークフローの実行結果を確認する

2. dev.to に執筆途中の内容で記事が同期されていることを確認する

これまで説明してきた 2 つのワークフローを利用することで、大抵のユースケースはカバーできるはずです。

おわりに

GitHub Action の勉強のために取り組んだプロジェクトですが、思いの外楽しくて他にも色々な機能のアイデアがあるので随時実装していきたいと考えています。(英訳, タイトルフォーマット変更, etc.)

DEV に Zenn の記事をクロスポストする GitHub Action を公開することで、いつもお世話になっている Zenn というプラットフォームを海外の方に認知していただける機会を創出できたのかもと考えたらテンションが上がってきました。

それはさておき、Zenn の記事を他でも有効活用するための GitHub Action を開発する際には、恐らく本記事で紹介した GitHub Action のコードが参考になるはずです。

また、GitHub Action の Marketplace というものが用意されているようなので、開発がある程度完了次第、こちらに申請するのも試してみたいと考えております。

ところで、Crieit さんにも記事投稿 API ができたらクロスポストできるようにしたいな...という個人的願望がありますｗ

参考リンク

DEV (Forem) の仕様上、タグは最大でも 4 つまでしか設定できないため、Zenn で設定したタグの先頭 4 つまで DEV の記事には設定しています ↩︎
当然といえば当然ですが jitterbit/get-changed-files@v1 は workflow_dispatch でワークフローを手動実行した際や、force push 等でファイル差分を正確に特定できない操作には対応しておりませんので、その場合はエラーが発生します ↩︎

📔 PlayFab の API 制限に引っかかった

2021-03-16T01:03:30+09:00

はじめに

PlayFab で CloudFunction を利用しているときに API 制限に引っかかってしまいました。負荷テストをした際に初めて気づいたのですが、公式ページにも言及が無かったため発覚が遅れてしまいました。そのため、PlayFab に依存していた機能を部分的に外す必要が出てきてしまい苦労しました。

本記事では、上記のような事態に陥る方を減らすため、API 制限に気づくまでの軌跡を辿りながら、PlayFab の CloudFunction を利用する際の注意点について、記事として残しておきたいと思います。

PlayFab の API 制限に引っかかった要因

PlayFab の CloudFunction を利用すると、PlayFab 経由で独自 Web API を実行することが可能になります。また、CloudFunction 経由で独自 Web API を実行すると、PlayFab ユーザ情報が含まれたパラメタが含まれた状態でリクエストが飛んでくるため、その情報を利用することでサーバーサイドで PlayFab の操作を行うことが出来るようになり大変便利です。

そのため、あるプロジェクトでは PlayFab CloudFunction を Azure Function や AWS Lambda のような FaaS を使っている感じで利用しておりました。そして、その利用の仕方は誤りであったことに後々気づきます...

負荷テストを実装するフェーズで CloudFunction を大量に叩いてみる

PlayFab の CloudFunction を実行するにあたり利用した PlayFab の API は Server-Side Cloud Script - Execute Function というものになります。

同接 2000 人想定で負荷テストのシナリオを実装することが求められていたため、その通りシンプルに 2000 件同時に Server-Side Cloud Script - Execute Function を実行するシナリオを Gatling で組んでみました。すると、何回やっても数十件以上は必ずエラーが発生していることが分かりました。

# Gatling で負荷テストを実行した際に 50件失敗している様子
================================================================================
---- Global Information --------------------------------------------------------
> request count                                       2000 (OK=1950   KO=50    )
> min response time                                    320 (OK=320    KO=354   )
> max response time                                  14459 (OK=9723   KO=14459 )
> mean response time                                   998 (OK=934    KO=3485  )
> std deviation                                       1510 (OK=1304   KO=4310  )
> response time 50th percentile                        545 (OK=543    KO=656   )
> response time 75th percentile                       1085 (OK=1077   KO=7209  )
> response time 95th percentile                       2243 (OK=2029   KO=10210 )
> response time 99th percentile                       7947 (OK=7775   KO=14353 )
> mean requests/sec                                    100 (OK=97.5   KO=2.5   )
---- Response Time Distribution ------------------------------------------------
> t < 800 ms                                          1393 ( 70%)
> 800 ms < t < 1200 ms                                 367 ( 18%)
> t > 1200 ms                                          190 ( 10%)
> failed                                                50 (  3%)
---- Errors --------------------------------------------------------------------
> status.find.is(200), but actually found 400                        50 (100.0%)
================================================================================

正直 2000件程度の API アクセスであれば、何の問題もなく負荷テストが通ると考えていたので、この結果には驚きました。原因は何なのか調べたところ、Azure Function で PlayFab ユーザ認証を行うために利用していた Authentication - Validate Entity Token で 503 エラーが発生していることが分かりました。

少ない API 実行件数で負荷テストを実行する場合は問題ないのですが、件数が一定数超えたタイミングで 503 エラーが返却されるようになってしまいます。しかし、たまに同じ件数を実行しているはずなのにスムーズに全件 API 実行に成功することもありました。これは何らかのレートリミット等に引っかかっているのかも知れないということで調査したところ、次の事実が判明しました。

CloudFunction は FaaS の用途には適さない

どうやら PlayFab 公式フォーラムのある投稿によると、PlayFab の Server API を呼び出す際は 10秒間に 1000回という制限があるようでした。 そして、この制限を突破するには商用のための契約をした後にインスタンス割当に関する交渉をすることで可能になるかも知れないとのことでした。

Servers are rate limited to 1,000 calls per 10 seconds. What jital is highlighting that the per-player rate should be no more than a few times a minute. A server can call at a higher rate, as it is calling for a lot of users, potentially. If you need a higher limit than 1,000 per 10 seconds, you'll want to talk to our sales team about getting on an Enterprise contract so that we can work with you on custom limits. There's an option on the Contact Us form on the main site to message them, if you want to go that route.

つまり、普通に PlayFab を利用している限りはプランをアップグレードしようと制限に引っかかるということが分かりました。 また、今年 1月に投稿された内容を見るに 10秒以内に 5000以上のユーザーがログイン/登録できたとあり、もう API の 10秒間に 1000回呼び出し制限は撤廃されたのかを聞いているユーザがいたのですが、まだ撤廃されていないと返信されていたので偶然だったようでした。

ちなみに私も上記が気になったので、セッションごとにレートリミットのかかり方が変わるのか検証するために異なるユーザ情報を用いてリクエスト 2000件を並列に実行してみましたが、503 エラーは変わらず返却され続けていたので、少なくとも私の手元の環境では効果はなさそうでした。

No, the rate limits on the Client and Server API calls has not changed. However, the rate limits are currently enforced on a per-server basis. And since the service runs a great many servers for load balancing, it is possible to exceed those limits from time to time.

原因の調査中 PlayFab は EC2 の us-west-2 リージョンでリクエストを受けていそうなことが分かったのですが、そのアクセス先のインスタンスがロードバランサによって分散されているため、レートリミットの制限がインスタンス先により、時と場合によって制限されるかどうかが決まってくるのかもしれないとのことでした。

以上のことから、PlayFab の CloudFunction については Azure Function や AWS Lambda のような FaaS のような用途には使わず、あくまでもアプリケーションで補助的に利用するための独自スクリプトを動かす程度に留めて利用するのが正解なように感じました。

PlayFab のユーザ認証情報である SessionTicket や EntityToken を利用することで、認証周りの実装部分を省くことが出来るかも知れないと思い期待していたのですが、それは別の BaaS を使うか IaaS で自前で作るのが良さそうでした。

おわりに

API の 10秒間に 1000回呼び出し制限については明示的にドキュメントに記載があるわけでもなかったため、気づくことが出来ずプロジェクト終盤で気づくという事故が起きてしまったのですが、私と似たような境遇に陥る人が少しでも減るようにと記事を書いてみました。

とはいえ、少し調べれば出てくるような制限だったので純粋に調査不足だったなあと反省しました。。CloudFunction はとても便利ですが、利用する際は API の呼び出し制限等用法には十分お気をつけてご利用くださいませ。

PlayFab が便利な BaaS であることに疑いの余地は無いので今後も利用すると思いますが、知見を貯めつつ効果的に使えるよう勉強していきたいと考えております。また何か知見を得たら随時ブログ記事に書き溜めていきたいと思います。

参考リンク

Gatling で複数ユーザ認証した情報を元に負荷テストする

2021-03-15T12:45:11+09:00

はじめに

今までは JMeter でしか負荷テストを行ったことなかったのですが、最近 PlayFab で CloudFunction の負荷テストを行う際に Gatling を初めて利用しました。

今回の負荷テストでは、各ユーザ毎のレートリミットの制限等も考慮した実利用時を想定した形で行うことが要求されたため、単一ユーザの認証情報を使い回すことは望ましくないと考えました。そこで、複数の認証済みユーザの情報を元に PlayFab の CloudFunction の負荷テストを実施したのですが、若干実装に苦戦したため手順について記事として残しておくことにしました。

また、本記事では Gatling のセットアップから記載していますが、該当コードやその説明を早く見たいという方は 複数ユーザ認証を行うテストシナリオを実装する 項目をご参照ください。

動作環境

macOS Big Sur
Java OpenJDK 12.0.1
- 未インストールの方は事前に公式サイトから OpenJDK をインストールしてください

Gatling の環境を整える

Gatling には 2 種類のセットアップ方法が用意されています。 スタンドアローンなツールを直接公式サイトからダウンロードするか、Maven や sbt といったツール経由でダウンロードするか選択できます。

どちらの方法でセットアップするかについてですが、新規でテストケースを Gatling で書いていく用途だと前者になり、既存のプロジェクトに Gatling を取り込む用途だと後者になるかと存じます。

本記事では、前者のスタンドアローンなツールを直接公式サイトからダウンロードする方法で Gatling の環境をセットアップします。

公式サイトから Gatling をダウンロードする

Gatling のトップページに遷移して、ページを 2 Ways to use Gatling の項目までスクロールした後、ダウンロードボタンをクリックします。

DOWNLOAD GATLING'S BUNDLE にある DOWNLOAD NOW ボタンをクリックする

ファイルダウンロード後はダウンロードした zip ファイルを適当なフォルダに展開して配置します。
早速ターミナルで展開したフォルダ内にある ./bin/gatling.sh を実行して、正常にコマンドが実行できるか確認してみます。

OS が Windows の場合は ./bin/gatling.bat を実行します。

⊨ ./bin/gatling.sh                   ~/D/gatling-charts-highcharts-bundle-3.5.1
GATLING_HOME is set to /Users/nika/Desktop/gatling-charts-highcharts-bundle-3.5.1
Choose a simulation number:
     [0] computerdatabase.BasicSimulation
     [1] computerdatabase.advanced.AdvancedSimulationStep01
     [2] computerdatabase.advanced.AdvancedSimulationStep02
     [3] computerdatabase.advanced.AdvancedSimulationStep03
     [4] computerdatabase.advanced.AdvancedSimulationStep04
     [5] computerdatabase.advanced.AdvancedSimulationStep05
0 # 実行したいテストの番号を入力する、今回は適当に 0 を指定
Select run description (optional)
# 実行するテストに関する説明文を入力する。何も入力する内容が無い or
# 説明文の入力が完了したら Enter を入力して、実際にテストを実行する

# 選択したテストの実行が開始する
# (0 を入力したので computerdatabase.BasicSimulation が実行される)
Simulation computerdatabase.BasicSimulation started...

#...

Simulation computerdatabase.BasicSimulation completed in 26 seconds
Parsing log file(s)...
Parsing log file(s) done
Generating reports...

# テストの実行が無事完了すると、結果が表示されレポートファイルが生成される。
# レポート生成先のファイルパスは実行結果の末尾に表示される。
# レポートファイルは HTML で生成されるため、適当なブラウザで開くことで内容を確認することが出来る。

================================================================================
---- Global Information --------------------------------------------------------
> request count                                         13 (OK=13     KO=0     )
> min response time                                    230 (OK=230    KO=-     )
> max response time                                    483 (OK=483    KO=-     )
> mean response time                                   324 (OK=324    KO=-     )
> std deviation                                         98 (OK=98     KO=-     )
> response time 50th percentile                        259 (OK=259    KO=-     )
> response time 75th percentile                        415 (OK=415    KO=-     )
> response time 95th percentile                        476 (OK=476    KO=-     )
> response time 99th percentile                        482 (OK=482    KO=-     )
> mean requests/sec                                  0.481 (OK=0.481  KO=-     )
---- Response Time Distribution ------------------------------------------------
> t < 800 ms                                            13 (100%)
> 800 ms < t < 1200 ms                                   0 (  0%)
> t > 1200 ms                                            0 (  0%)
> failed                                                 0 (  0%)
================================================================================

Reports generated in 0s.
Please open the following file: /Users/nika/Desktop/gatling-charts-highcharts-bundle-3.5.1/results/basicsimulation-20210314133324259/index.html

./bin/gatling.sh を実行した後、上記のような出力が確認できれば、問題なくスタンドアローン版の Gatling 環境のセットアップが完了しています。

また、負荷テストのレポートを確認したい場合は、出力結果にある Please open the following file: <レポートのファイルパス> に記載されているファイルをブラウザで開きます。
html 拡張子を開くアプリのデフォルトが何らかのブラウザになっているのであれば、ターミナルから open <レポートのファイルパス> を実行するのでも構いません。

Gatling でテストシナリオを実装する

Gatling のテストシナリオを書く場所は ./user-files/simulations フォルダ内になります。 テストシナリオを Scala で書いた後、ファイルを ./user-files/simulations フォルダに配置します。すると、./bin/gatling.sh を実行した際の実行するテストシナリオのリストに出てくるようになります。

簡単なテストシナリオを試しに書いてみる

まずは試しに私のブログに対してのアクセス負荷を計測するためのテストを実装していきます。./user-files/simulations フォルダ内に nikaera.com フォルダを作成し、AccessSimulation.scala という負荷テストのシナリオファイルを作成します。

// ./user-files/simulations/nikaera.com/AccessSimulation.scala
package com.nikaera

import scala.concurrent.duration._

import io.gatling.core.Predef._
import io.gatling.http.Predef._

import scala.collection.mutable.ListBuffer
import io.gatling.core.structure.PopulationBuilder

// 1. Simulation クラスを継承してテストシナリオを実行するクラスを定義する
class AccessSimulation extends Simulation {

  // 2. HTTP アクセスする際の設定値を入力する。
  // 今回はアクセス先のベース URL を定義するための baseUrl のみ指定
  val httpConf = http
    .baseUrl("https://nikaera.com")

  // 3. Scala の ListBuffer を用いて複数シナリオを格納する scenarios 変数を用意する
  val scenarios = new ListBuffer[PopulationBuilder]()

  // 4. httpConf で設定した情報を元に / (https://nikaera.com) 及び
  // /tech/ (https://nikaera.com/tech/) へ同時 10 アクセスするのを、
  // 5秒毎に 3回実行するシナリオを作成して、scenarios 変数に格納する
  val pollingApiScn = scenario("Polling Simulation")
    .exec(
      http("Top Page")
        .get("/")
        .check(status.is(200))
    )
    .exec(
      http("Tech Page")
        .get("/tech/")
        .check(status.is(200))
    )
  scenarios += pollingApiScn
    .inject(
      atOnceUsers(10),
      nothingFor(5 seconds),
      atOnceUsers(10),
      nothingFor(5 seconds),
      atOnceUsers(10)
    )
    .protocols(httpConf);

  // 5. 4. で定義したシナリオを実行して https://nikaera.com のアクセス負荷を計測する
  setUp(
    scenarios(0)
  )
}

再度 ./bin/gatling.sh を実行して、実際に負荷テストを行ってみます。

⊨ ./bin/gatling.sh                   ~/D/gatling-charts-highcharts-bundle-3.5.1
GATLING_HOME is set to /Users/nika/Desktop/gatling-charts-highcharts-bundle-3.5.1
Choose a simulation number:
     [0] com.nikaera.AccessSimulation
     [1] computerdatabase.BasicSimulation
     [2] computerdatabase.advanced.AdvancedSimulationStep01
     [3] computerdatabase.advanced.AdvancedSimulationStep02
     [4] computerdatabase.advanced.AdvancedSimulationStep03
     [5] computerdatabase.advanced.AdvancedSimulationStep04
     [6] computerdatabase.advanced.AdvancedSimulationStep05
0 # 作成したテストシナリオである com.nikaera.AccessSimulation を選択して実行します。
Select run description (optional)

Simulation com.nikaera.AccessSimulation started...

#...

Simulation com.nikaera.AccessSimulation completed in 10 seconds
Parsing log file(s)...
Parsing log file(s) done
Generating reports...

================================================================================
---- Global Information --------------------------------------------------------
> request count                                         60 (OK=60     KO=0     )
> min response time                                     11 (OK=11     KO=-     )
> max response time                                    372 (OK=372    KO=-     )
> mean response time                                   104 (OK=104    KO=-     )
> std deviation                                         99 (OK=99     KO=-     )
> response time 50th percentile                         53 (OK=53     KO=-     )
> response time 75th percentile                        212 (OK=212    KO=-     )
> response time 95th percentile                        259 (OK=259    KO=-     )
> response time 99th percentile                        307 (OK=307    KO=-     )
> mean requests/sec                                  5.455 (OK=5.455  KO=-     )
---- Response Time Distribution ------------------------------------------------
> t < 800 ms                                            60 (100%)
> 800 ms < t < 1200 ms                                   0 (  0%)
> t > 1200 ms                                            0 (  0%)
> failed                                                 0 (  0%)
================================================================================

Reports generated in 0s.
Please open the following file: /Users/nika/Desktop/gatling-charts-highcharts-bundle-3.5.1/results/accesssimulation-20210314144205502/index.html

テストシナリオの実行に成功していることが確認できたら、複数ユーザ認証した情報を元に行うテストシナリオを書いていきます。

複数ユーザ認証を行うテストシナリオを実装する

複数ユーザ認証するテストシナリオを実装していきます。PlayFab で複数ユーザの認証情報を元に CloudFunction の負荷テストを行うことを想定しています。テストシナリオを作成するにあたり、./user-files/simulations/ フォルダに新たに playfab.com フォルダを作成して、その中に TestCloudFunctionSimulation.scala ファイルを生成します。

下記コードの setUp でシナリオを複数指定する箇所についてですが、より良いやり方があれば是非ご教授いただけますと幸いです...

// ./user-files/simulations/playfab.com/TestCloudFunctionSimulation.scala
package com.playfab

import java.io._
import java.net.{HttpURLConnection, URL}
import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._
import scala.util.Random
import scala.util.parsing.json.JSON
import scala.collection.mutable.ListBuffer
import io.gatling.core.structure.PopulationBuilder

class TestCloudFunctionSimulation extends Simulation {
  // PlayFab に登録されたユーザの ID 群
  val playfabUsers = Array[String](
    "user1",
    "user2",
    "user3",
    "user4",
    "user5",
    "user6",
    "user7",
    "user8",
    "user9",
    "user10"
  )

  // PlayFab の TitleId 及び Secret を変数に保持しておく
  val playfabId = "XXXXX"
  val playfabSecret = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  val playfabApiUrl =
    s"https://${playfabId}.playfabapi.com"

　// PlayFab の Login With Server Custom Id を利用して、
  // ユーザの認証情報を取得するために用いる関数
  def getPlayfabAuth(serverCustomId: String): Option[Any] = {
    val url = new URL(
      s"${playfabApiUrl}/Server/LoginWithServerCustomId"
    )
    val con = url.openConnection().asInstanceOf[HttpURLConnection]
    HttpURLConnection.setFollowRedirects(false)
    con.setRequestMethod("POST")
    con.setRequestProperty("Content-Type", "application/json")
    con.setRequestProperty("X-SecretKey", playfabSecret)
    con.setDoOutput(true)

    val out = new OutputStreamWriter(con.getOutputStream(), "UTF-8")
    out.write(s"""{
        "CreateAccount": false,
        "ServerCustomId": "${serverCustomId}"
    }""")
    out.flush()
    out.close()
    con.connect()

    val in = con.getInputStream

    val br = new BufferedReader(new InputStreamReader(in, "UTF-8"));
    val json = br.readLine()

    in.close()
    con.disconnect()

    return JSON.parseFull(json)
  }

  val httpConf = http
    .baseUrl(playfabApiUrl)
    .header("Content-Type", "application/json")

  // CloudFunction の Request Body を作成するために利用する関数
  def cloudScriptDto(funcName: String, funcArgs: String): String = {
    return s"""{
        "FunctionName": "${funcName}",
        "FunctionParameter": ${funcArgs}
    }"""
  }

  val scenarios: ListBuffer[PopulationBuilder] =
    new ListBuffer[PopulationBuilder]()

  playfabUsers.foreach(userId => {
    // playfabUsers で指定したユーザ ID 情報を元に、
    // PlayFab の認証情報を取得利用することで、
    val playfab = this.getPlayfabAuth(userId).get
    val map: Map[String, Option[Any]] =
      playfab.asInstanceOf[Map[String, Option[Any]]];

    // 愚直に JSON オブジェクトのパースを行い、必要な情報を変数に取り出す。
    val data = map.get("data").get.asInstanceOf[Map[String, Option[Any]]];
    val entityTokenInfo =
      data.get("EntityToken").get.asInstanceOf[Map[String, Option[Any]]];
    val entityToken =
      entityTokenInfo.get("EntityToken").get.asInstanceOf[String];

    val entity =
      entityTokenInfo.get("Entity").get.asInstanceOf[Map[String, Option[Any]]];
    val entityId =
      entity.get("Id").get.asInstanceOf[String];

    // Test2 API については CloudFunction 実行時のパラメタを、
    // ランダム指定したいため、Random を用いてパラメタを散らすようにする
    val rand = new Random
    val values = Array(
      "value1",
      "value2",
      "value3",
      "value4",
      "value5"
    )
    val values_length = values.length

    // アクセス負荷を調査したい CloudFunction API 群を実行する。
    val pollingApiScn = scenario(s"PollingSimulation: ${entityId}")
      .exec(
        http("Test1 Api")
          .post("/CloudScript/ExecuteFunction")
          .header("X-EntityToken", entityToken)
          .body(StringBody(cloudScriptDto("Test1", null)))
          .check(status.is(200))
      )
      .exec(
        http("Test2 Api")
          .post("/CloudScript/ExecuteFunction")
          .header("X-EntityToken", entityToken)
          .body(
            StringBody(
              cloudScriptDto(
                "Test2",
                s"""{"value": "${values(rand.nextInt(values_length))}"}"""
              )
            )
          )
          .check(status.is(200))
      );

    // 1 ユーザあたり 3秒毎に 100回ずつ API 群を実行した際の
    // 負荷テストのシナリオを scenarios 変数に格納する
    scenarios += pollingApiScn
      .inject(
        atOnceUsers(100),
        nothingFor(10 seconds),
        atOnceUsers(100),
        nothingFor(10 seconds),
        atOnceUsers(100)
      )
      .protocols(httpConf);
  });

  // scenarios 変数に格納されたテストシナリオを並列実行する
  setUp(
    scenarios(0),
    scenarios(1),
    scenarios(2),
    scenarios(3),
    scenarios(4),
    scenarios(5),
    scenarios(6),
    scenarios(7),
    scenarios(8),
    scenarios(9)
  )
}

ザッとインラインコメントで説明を書きましたが、重要な点についてのみ補足します。
def getPlayfabAuth は PlayFab 認証するための関数となっていますが、適宜認証に用いるサービス毎で関数の内容を変更することで、他サービスで認証するための関数として利用可能です。
また playfabUsers.foreach 内で各ユーザが実行するテストシナリオを生成しつつ、それらを scenarios 変数に保持しています。そうすることで、最後に setUp 関数でシナリオをまとめてセットできるようになります。

playfabUsers.foreach で値を指定するのではなく CSV でテストに与えるフィードデータを定義するする方法もあります。認証部分も含めてテストシナリオを書きたい場合にも便利に利用できます。またアカウント情報を CSV ファイルに定義しておくと、テストユーザの情報を新規追加したい場合で管理が楽になります。

上記テストシナリオのソースコードを応用することで、様々なサービスで複数ユーザ認証した情報を元に負荷テストを行うためのシナリオを作成することが可能となります。

おわりに

今回は Gatling で複数ユーザ認証した情報を元に負荷テストする手順について書きました。

Gatling で生成されるレポートは見やすく、改善点を洗い出してコードの改善作業をするのにとても有用でした。 また、JMeter と比べて動作が軽いため気軽に実行しやすく、テストシナリオが全てコードで管理されているためシナリオの改変も素早く行うことが出来ました。

個人的にはテストシナリオを全てコードで記述できる Gatling が気に入ったので今後も有効活用していきたいと感じました。ただ、Gatling 以外にも Python で書ける locust や JavaScript で書ける k6 など、他にも気になるツールがいくつかあったので今後試してみたいなと考えています。

勝手に負荷テストは JMeter 一択だと思っていたのですが、負荷テストツールには色々あるようなのでプロジェクトや自分にあったものを選定していけるよう随時キャッチアップしていきたいと感じました。

参考リンク

📝 Jest で private readonly な値をモックする方法

2021-03-08T01:51:05+09:00

はじめに

Jest でクラスの private readonly な変数を差し替えたい時に若干引っかかったのでメモっておきます。タイトルでは Jest とありますが、本記事の内容は JavaScript でモックする際の有効な手法の 1 つとして利用することが可能です。

Object.defineProperty を利用して値を差し替える

結論から言うと変数を差し替えたい場合は下記のような記述になります。

const mockValue = "";
Object.defineProperty(service, "privateReadOnlyValue", {
  value: mockValue,
});

ちなみに関数を差し替えたい場合は下記のような記述になります。

Object.defineProperty(service, "privateSumFunction", {
  value: jest.fn((a, b) => a + b),
});

各種テストケースで使いまわしているインスタンスの private readonly な変数をモックした場合、値をリストアしたいケースも出てきました。その場合の記述としては、下記が有効でした。

// tmpService 変数に service インスタンスを clone して利用する
const tmpService = Object.create(service);
Object.defineProperty(tmpService, "privateReadOnlyValue", {
  value: "",
});

おわりに

Object.defineProperty と Object.create を駆使すれば大体のケースでは事足りそうです。

参考リンク

AWS Lightsail Containers に Actix web をデプロイする

2021-01-23T21:12:04+09:00

はじめに

Actix web で Web アプリケーションを作ったのですが、技術勉強も兼ねていたので、デプロイ先も今まで試したことがないものを試そうとしていました。そこで、日頃業務でも AWS を利用しているということもあり、去年末に発表された AWS Lightsail Containers をデプロイ先に採用しました。

AWS Lightsail Containers へのデプロイ自体は非常に簡単でした。また、デプロイにあたり Rust の Docker イメージ作成のやり方も学べました。今回はそのあたりの手順をまとめる形で記事として書き残しておくことにしました。

Actix web の Docker イメージを作成する

開発したアプリケーションでは React でフロントエンド開発をしていて、ビルドしたものを Actix web の public フォルダに配置する形で公開しています。そのため、下記の Dockerfile ではマルチステージビルドを利用しておりますが、本質的には FROM rust:1.49 以降の記述が Actix web に関するものとなります。

# React ビルド用のイメージ
FROM node:14.15.4-alpine3.10 as client_builder

ARG REACT_APP_API_URL
ARG REACT_APP_GYAZO_AUTH_URL
ARG REACT_APP_GA_UNIVERSAL_ID

WORKDIR /client
COPY ./client/package*.json .
RUN yarn install

ADD ./client .
RUN yarn build

# Actix web ビルド用のイメージ
FROM rust:1.49

# Actix web にアクセスするためのポートを公開する
EXPOSE 8080

# Actix web プロジェクトのフォルダをイメージに追加する
WORKDIR /server
ADD ./server .

# プロジェクトフォルダ内で `cargo install` してビルドを生成する
RUN cargo install --path .

# 不要になったファイル群を削除する
RUN ls | grep -v -E 'templates' | xargs rm -r

# React ビルド用のイメージでビルドした内容を Actix web ビルド用イメージに追加する
COPY --from=client_builder /client/build ./build
RUN mkdir tmp

# `cargo install` コマンドで生成したビルドを実行して Actix web を起動する
# 下記のコマンド名称は Cargo.toml 内の [package.name] に準ずる
CMD ["bloggimg-server"]

また、Docker ビルド時のオプション管理を楽にするため、Docker Compose を利用しました。単一の Docker イメージをビルドする際にも利用しておくことで、後々コンテナを追加して連携させたいときにも即座に対応できたりでオススメです。

# docker-compose.yml

# context に Actix web プロジェクトのパスを指定する
# args に Docker ビルド時に利用したい ARGS の値を環境変数で設定する
# image に Docker の <イメージ名:タグ名> を指定する (今回は Docker Hub にデプロイする想定)
# env_file に開発/動作検証時に利用したい dotenv ファイルを指定する
# ports にポートマッピングの設定を書く

version: '3.8'
services:
  app:
    build:
      context: ./
      args:
        - REACT_APP_API_URL=${REACT_APP_API_URL}
        - REACT_APP_GYAZO_AUTH_URL=${REACT_APP_GYAZO_AUTH_URL}
        - REACT_APP_GA_UNIVERSAL_ID=${REACT_APP_GA_UNIVERSAL_ID}
    image: n1kaera/bloggimg:v1.0.0
    env_file:
      - ./server/.env
    ports:
      - 8080:8080

上記を自分の Actix web プロジェクトに応じて改変し docker-compose up して動作検証します。動作検証ができ次第、docker-compose build を実行して Docker イメージをビルドします。ビルドに成功したら次は Docker Hub にイメージを push します。

Docker Hub にビルドしたイメージを push する

今回は AWS Lightsail Containers で使用するイメージの管理に Docker Hub を利用します。Docker Hub へ push する前に docker login --username= コマンドで Docker Hub へのログインを済ませておきます。

その後 docker-compose push コマンドで Docker イメージを Docker Hub に push します。

Docker Hub のページから、正常に Docker イメージが push できていそうか確認する

Docker イメージの push が成功していることを確認できたら、残りは AWS Console 上での作業になります。

AWS Console から Lightsail Containers Service を作成する

AWS Console にログイン後、Lightsail サービスを選択して Lightsail サービスのトップページへ遷移します。遷移したら Containers タブを選択し、Create container services ボタンから Container Service を作成します。

AWS Console へログイン後 Lightsail のページに遷移して、Containers タブを選択する

Containers タブを選択すると出てくる、Create container services ボタンをクリックする

Create container services ボタンをクリックした遷移先の画面で、リージョンやキャパシティ (Micro であれば 3ヶ月間のみ無料で利用可能) 等を選択して、名称を入力します。今回は最初にデプロイのための準備をすでに済ませているので、Container Service を作成するついでにデプロイ設定も行います。

デプロイ設定は Set up your first deployment の項目から行うことが可能です。

Set up deployment の部分をクリックして、デプロイの設定項目を表示する

Docker Hub イメージを利用してデプロイする際に必要な設定項目を入力する

コンテナのヘルスチェックのための情報を入力する

すべての情報入力が完了したら Create container services ボタンをクリックする

遷移後の画面下部の Deployment versions からデプロイ状況の確認が行える

正常にデプロイできていれば Deployment versions の項目が Active になる

デプロイが完了したら Public domain が発行されているはずなので、正常にアクセスして Web アプリケーションが利用できそうか確認します。Public domain は該当する Container Service のトップページから確認できます。

AWS Lightsail Containers のトップページにある Public domain から動作検証する

一通りの動作検証を行い、正常にデプロイできていそうか確認する

これで作業は完了です。新しい Docker イメージでデプロイし直したい場合は、Deployments タブの Modify your deployment リンクをクリックすれば可能です。

(おまけ) 独自ドメインで Container Service へアクセス可能にする

AWS Lightsail Containers では独自ドメインの紐付け及び、HTTPS 化も簡単に設定できます。Custom domains タブを選択した後、画面下部にある Create certificate リンクをクリックすることで設定画面を表示します。

Custom domain タブをクリックしてから、Create certificate リンクをクリックする

各種設定項目の入力が完了したら Create ボタンをクリックする

ドメイン検証のために、CNAME レコードの設定を求められるので各自で設定作業を行う

正常に CNAME レコードを設定した後、しばらく経つと Status が Valid になる

上記まで確認したら、Create certificate で設定したドメインの CNAME レコードに Public domain の値を設定しておきます。設定内容が反映され次第、独自ドメインへアクセスすることで HTTPS 経由で Container Service へアクセスできるようになります。

Custom domains で Container Service で起動しているサービスにアクセスできることを確認する

おわりに

AWS Lightsail Containers を利用して Actix web プロジェクトをデプロイする手順について簡単にまとめてみました。便利ではあるものの、個人開発で利用する分には価格面及び性能面で Lightsail Instance のほうが良いなと現時点では感じてしまいました。

しかし、日本リージョンが用意されていたりロードバランサーを備えていたり、簡単にスケールさせやすくかつ定額で利用可能なサービスであるというメリットを活かせる場面があれば有効活用できそうだなと感じました。

参考リンク

Actix web で HttpOnly な Cookie を設定する

2021-01-23T14:33:35+09:00

はじめに

最近 Rust を勉強するため、Actix web で Bloggimg という Web アプリケーションを作りました。その際、セッション管理のために Cookie を利用したのですが、その際の手順及び設定方法についてまとめておきます。

本記事では Rust や Actix web のインストール方法については説明しません。Mac であれば brew install rustup して rustup-init した後、PATH に $HOME/.cargo/bin を追加するだけで大丈夫なはずです。詳細なインストール手順については公式サイトをご参照ください。

開発環境については VSCode の Rust Plugin がオススメです。Rustup で Rust をインストールしている場合、設定から Rustup の PATH を $HOME/.cargo/bin/rustup にするだけで利用可能です。設定手順の詳細はこちらをご参照ください。

動作環境

Mac mini (M1, 2020)
- Rust 1.49
- Actix web 3

サーバー側で Cookie を設定するため、HTTP レスポンスヘッダーに Set-Cookie を含める形でセッション情報をクライアントへ渡します。その際、最低でも Cookie の属性に HttpOnly と Secure、SameSite=Strict は設定します。実際の Cookie を設定するための Actix web でのサンプルコードは下記になります。

use std::env;
use actix_web::{App, HttpServer};
use actix_web::cookie::{Cookie, SameSite};
use actix_web::{get, web, Error, HttpRequest, HttpResponse};

use serde::{Deserialize};

/// Cookie に設定するキー
/// 今回は cookie_test をキーとして使用する
/// 
const KEY: &str = "cookie_test";

/// 存在していれば、HTTP Request ヘッダーから Cookie 文字列を取得する関数
/// 
/// # Arguments
/// * `req` - actix_web::HttpRequest
/// 
/// # Return value
/// * Option - key=value; key1=value1;~ のような Cookie の文字列
/// 
fn get_cookie_string_from_header(req: HttpRequest) -> Option {
    let cookie_header = req.headers().get("cookie");
    if let Some(v) = cookie_header {
        let cookie_string = v.to_str().unwrap();
        return Some(String::from(cookie_string));
    }
    return None;
}

/// 存在していれば、特定のキーで Cookie に設定された値を取得するための関数
/// 
/// # Arguments
/// * `key` - Cookie から取り出したい値のキー
/// * `cookie_string` - get_cookie_string_from_header 関数で取得した Cookie の文字列
/// 
/// # Return value
/// * Option - Cookie に設定されている値を取得する
/// 
fn get_cookie_value(key: &str, cookie_string: String) -> Option {
    // 取得した Cookie 文字列を ; で分割してループで回す
    let kv: Vec<&str> = cookie_string.split(';').collect();
    for c in kv {
        // Cookie 文字列をパースして key で指定した値とマッチしたキーが存在するかチェックする
        match Cookie::parse(c) {
            Ok(kv) => {
                if key == kv.name() {
                    // key で指定した値とマッチしたキーが存在していたら、その値を取得する
                    return Some(String::from(kv.value()));
                }
            }
            Err(e) => {
                println!("cookie parse error. -> {}", e);
            }
        }
    }
    return None;
}

/// 特定のキーで環境変数から値を取得するための関数
/// 
/// # Arguments
/// * `key` - 環境変数から取り出したい値のキー
/// 
/// # Return value
/// * String - 環境変数の値を文字列として取得する
/// 
fn get_env(key: &str) -> String {
    match env::var(key) {
        Ok(value) => return value,
        Err(e) => println!("ENV: ERR {:?}", e),
    }
    return String::new();
}

/// 環境変数に設定された HTTPS の値が 1 か判定する
/// Cookie の属性に Secure を付与するか判定するのに使用する
/// 
/// # Return value
/// * bool - Secure 属性を付与するか判定するための真偽値
/// 
fn is_https() -> bool {
    return get_env("HTTPS") == "1";
}

/// Cookie に設定する値を扱う HTTP Query の定義
#[derive(Deserialize)]
pub struct CookieQuery {
    pub value: String,
}

/// Cookie を設定するために用意したルート
/// 
/// # Example
/// 
/// 例えば GET /cookie?value=test にアクセスした場合、
/// Cookie に cookie_test=test が設定されるようになる
/// 
#[get("/cookie")]
async fn set_cookie(query: web::Query) -> Result {
    // 設定したい Cookie を作成する
    // その際に Secure, HttpOnly, SameSite=Strict 属性を付与する
    let cookie = Cookie::build(KEY, &query.value)
            .secure(is_https())
            .http_only(true)
            .same_site(SameSite::Strict)
            .finish();

    // 作成した Cookie を HTTP Response の Set-Cookie ヘッダーに含めることで、
    // HTTP Response を受け取ったクライアントに Cookie をセットさせる
    return Ok(HttpResponse::Ok()
        .header("Set-Cookie", cookie.to_string())
        .body(""));
}

/// KEY で指定した Cookie が存在すれば、その値を返却する
/// KEY で指定した Cookie が存在しなければ、空の文字列を返却する
#[get("/")]
async fn index(req: HttpRequest) -> Result {
    let cookie_string = get_cookie_string_from_header(req);
    if let Some(s) = cookie_string {
        if let Some(v) = get_cookie_value(KEY, s) {
            return Ok(HttpResponse::Ok().body(v));
        }
    }
    return Ok(HttpResponse::Ok().body(""));
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .service(set_cookie)
            .service(index)
    })
    .bind("0.0.0.0:8080")?
    .run()
    .await
}

ザッとインラインコメントで説明していますが、
最も重要な set_cookie 関数について簡単に説明します。

Actix web には Cookie クラスが存在します。この Cookie クラスは Cookie 文字列を生成したり、パースしたりするのに役立ちます。set_cookie 関数では、Cookie を生成するための関数 Cookie::build を利用しています。

Cookie::build 関数を利用することで、メソッドチェインで Cookie の値や属性を設定できます。作成した Cookie は to_string 関数を使用することで文字列として出力できます。出力した Cookie 文字列を HTTP レスポンスヘッダーに Set-Cookie として設定すれば Cookie を設定できます。

動作検証

今回用意した Actix web のサンプルコードには 2つのエンドポイントを用意しました。

URI	説明
`GET /cookie`	`value` クエリで HttpOnly な Cookie を設定する
`GET /`	`GET /cookie` で設定した Cookie を確認する

cargo run で Actix web のサンプルを起動した後に、ブラウザで http://localhost:8080/cookie?value=sample にアクセスしてみます。またその際に HTTP レスポンスヘッダーを確認したいため、開発者ツールを開いておきます。

HTTP レスポンスヘッダーに Set-Cookie が含まれていることを確認する

Set-Cookie が含まれていることが確認できたら正常に Cookie が設定されているか確認します。

HTTP リクエストヘッダーの Cookie に cookie_test=sample が存在していることを確認する

実際にブラウザーにも Cookie が正しく設定されているか、開発者ツールで確認する

正常に Cookie がセットされていることが確認できれば作業完了です。Cookie の属性に Secure を設定した場合の動作検証は、環境変数に HTTPS=1 をセットして cargo run で可能です。

おわりに

Actix web で割と汎用的に使えそうな知識として Cookie の設定方法について、メモ的な記事を書いてみました。引き続き、Rust への理解を深めるために Bloggimg の開発を進めながら学習を進めていきます 🧑‍🎓

本記事の内容がセキュリティの観点から適切でない場合等はコメントでご指摘いただけますと幸いです。

参考リンク

📔 ブログを書く用途に特化した Gyazo のツールを開発してみた

2021-01-18T02:08:16+09:00

Gyazo を技術記事を書く用途で使っているので専用の便利ツールを作ってみた

はじめに

いつもブログ記事に載せるキャプチャ画像の編集 & アップロード先として Gyazo を利用させていただいているのですが、日々使っている中で不満に感じる点もちょくちょく出てくるようになってきました。

そのため、3連休を用いて Rust の勉強がてら Bloggimg というウェブアプリケーションを作ってみました。ソースコードは MIT ライセンスで GitHub のリポジトリにアップしております。ちなみに最初は Gyazo for Blog という名称で開発をしていたため、本記事内のスクショには Gyazo for Blog という文字列が出てきますが、現在は Bloggimg という名称になっております。。

Bloggimg を開発したのは、ブログ記事を書く際に利用する画像のアップロードから加工、マークダウンとして利用するまでのフローを最適化したかったからです。ブログ記事を書く際に、記事内で用いるスクショ画像の加工や、そのアップロードにすごく時間を取られてしまうなーと日頃から感じていたのでそれを解決したかったのです。✅

開発中に得た知見等については別途技術記事として書いて残す予定です。

考えていたこと

今回 Bloggimg の開発を行うに当たり、考えていた点は下記になります。

画像の編集ツールは引き続き Gyazo に用意されているものを使う
- 既に最高に使いやすい 👑
キャプチャ画像をアップロードする際に、自動的に特定のコレクションに紐付けるようにする
- 技術記事毎にコレクションを分けて管理しているため、技術記事を書いている最中にアップするキャプチャ画像は全て特定のコレクションにまとまっていて欲しい
ワークスペースのようなツールを目指し、ブログを書く時だけに使える機能を開発する
- 例えば、ワンクリックで画像マークダウンの記述がコピーできたり、画像のアップロードをし直しやすくするため画像削除がお手軽に出来るよう削除ボタンに即アクセス出来るようにしたり...

特にアップした画像を 自動的に特定のコレクションに紐付けるようにする については本記事で紹介しているウェブアプリケーションを作成するキッカケとなった点なので外せない点でした。

使い方

Bloggimg の使い方についてご紹介いたします。

ログインする

Bloggimg を利用するためには、まず Gyazo アカウントでログインして頂く必要がございます。トップページの右上にあるログインボタンから Gyazo アカウントでログインします。

1. トップページ右上に配置されたログインボタンから Gyazo アカウント認証を行う

2. Gyazo アカウント認証が正常に完了したら、再度トップページを開く

3. トップページを開いた時に Gyazo にアップした直近の画像が確認できるはずです

ログアウトする

ウェブアプリケーションからログアウトするには、ログイン後にトップページ右上に表示される ログアウト ボタンをクリックすることでログアウトできます。

ログイン後にトップページ右上に表示される ログアウト ボタンをクリックしてログアウトする

画像ファイルをアップロードする

画像は一枚でも複数枚でもアップロードすることが可能です。画像アップロードの方法としてドラッグ & ドロップとファイル選択ダイアログを用意しております。

画面中央の点線枠内に画像ファイルをドラッグ & ドロップするか、点線枠内をクリックしてファイル選択ダイアログから選択することで画像をアップロードできる

画像ファイルをアップロードする際に自動でコレクションを紐付ける

Gyazo トップページ左端にコレクションリストが表示されているので、画像を紐づけたいコレクションを選択します。新たにコレクションを作成する場合はコレクションリスト上部にある コレクションを作成 ボタンをクリックします。

1. コレクションリストの中から画像を紐づけたいコレクションを選択する

2. コレクションを選択後に遷移した先の URL 末尾のコレクション ID をコピーする

3. トップページの最上部に 2. で控えていたコレクション ID をペーストする

上記までのステップが完了し、正しくコレクション ID が入力できていれば、次回以降のファイルアップロード時に自動で指定したコレクションに画像が紐づくようになります。

アップロードした画像ファイルを編集する

画像ファイルのアップロード時や 画像の再読み込み ボタンをクリックすることで、最新 20件の画像リストを画面最下部にロードされます。画像リストの各項目ではプレビュー、編集、削除、マークダウンのコピーを行うことが可能です。

画像リストの各項目の機能概要図

プレビュー

サムネ画像をクリックすることで、Gyazo にアップした元画像をプレビューすることが可能です。サムネ画像では画像の判別がしにくい場合に詳細を確認するための機能となります。

アップした画像の詳細を確認するためにプレビュー機能を利用する

編集

編集は該当画像の Gyazo ページにて行えるように、タイトルをクリックすることで Gyazo ページを別タブで開きます。

別タブで開いた Gyazo ページから画像の編集作業を行う

削除

画像の削除は 画像の削除 ボタンをクリックすることで、削除を行うための画面に遷移します。削除しようとしている画像で間違いないか確認後、削除を行うという手順になっております。

Gyazo から選択した画像を削除する

マークダウンのコピー

マークダウンをコピー ボタンをクリックすることで、クリップボードにマークダウン形式で該当画像を表示するための記述をコピーすることができます。具体的には下記のような記述がコピーされます。

ブログを書く先がマークダウン形式での記述に対応していれば、そのままペーストするだけで画像を表示することが可能です。

![スクリーンショット 2021-01-11 17.10.11.png](https://i.gyazo.com/a3e219b5efb8494103432b369ee99534.png)

おわりに

この記事を書くのにも実際に Bloggimg を用いましたが、個人的に今までよりも Gyazo でブログ記事内で利用する画像に関する作業効率は上がったように感じました。ブログを書くという用途に Gyazo を利用されている方のお役に立てれば幸いです。

また、今後は下記の機能実装を進めていく予定です。

画像アップ時に自動でアスペクト比を維持した状態で画像のリサイズを自動で行う機能
画像アップ時のタイトルの接頭辞が指定できるようにする機能
編集した画像が自動的にコレクションに紐づく機能
- 心残りな点として編集した画像をコレクションに紐付ける機能は API でできなかったため、現在手動で行う必要があります。。Gyazo の API がコレクションの紐づけにも対応したら対応したいと考えています ✅

📝 AWS Lambda で cron みたいに定期実行する

2021-01-06T01:15:51+09:00

コンテナをホットスタンバイさせるために EC2 でインスタンス起動して cron で ping 飛ばしていたのですが、コスト的に勿体ないなーと思っていました。しかし、「AWS Lambda 使えばいいじゃん」という指摘を受け、確かにってなったので cron で定期実行していた ping 処理を AWS Lambda + EventBridge で置き換えました。

実は Heroku Scheduler とか使って同様のことをしていた時期もあったのですが、10分毎しか実行できない制約があったりして使い勝手が悪かったので、後々も使っていけそうな知見な気がしたのでメモがてら記事で残しておくことにしました。

まず、AWS Console から Lambda サービスを選択して関数を新たに作成します。

1. AWS Lambda のトップ画面から関数作成のための画面に遷移する

2. 必要な情報を入力して Lambda の関数を作成する

関数が作成でき次第、ping 処理を書いていきます。http リクエストを行うためのライブラリとして Node.js の標準モジュール(https) を利用します。

Lambda 関数作成直後の index.js は下記のような記述になっていると思います。

// index.js
exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

こちらを Node.js の標準モジュール(https) を利用する形で下記のように書き換えます。

// index.js
// "https://www.google.com/" に HTTP リクエストを実行する (ping)
const https = require('https');

const httpRequest = async (url) => {
    return new Promise((resolve, reject) => {
        const req = https.request(url, (res) => {
            let body = '';
            res.on('data', (chunk) => {
                body += chunk;
            });
            res.on('end', () => {
                console.log(`response: ${body}`);
                resolve(body);
            });
        })

        req.on('error', (e) => {
            console.error(e);
            reject(e);
        });

        req.end();
    });
}

exports.handler = async (event) => {
    const body = await httpRequest("https://www.google.com/");
    return {
        statusCode: 200,
        body
    };
};

その後、右上にある Deploy ボタンをクリックして関数にソースコードを反映します。実際に関数が意図したとおりに動作するか、Test ボタンをクリックして動作検証してみます。

Test ボタンをクリックします" />
1. Test ボタンをクリックします

2. 動作検証時のパラメーターを入力してテスト環境を作成する

3. 2. のテスト環境で関数の動作検証を行い正常に実行できていることを確認する

正常に関数が実行できていること確認できれば、後は定期実行可能にすれば作業完了です。定期実行するためのスケジューラには EventBridge を利用します。Add trigger ボタンから EventBridge を追加します。

Add trigger ボタンからトリガー追加画面に遷移する" />
1. Add trigger ボタンからトリガー追加画面に遷移する

2. EventBridge トリガーを追加して定期実行の設定を行う

3. EventBridge トリガーの追加が無事に完了したことを確認する

また 2. では 1分毎に実行するスケジュールを設定しましたが、EventBridge の書式を用いてより複雑なスケジュール設定を行うことも可能です。

最後に本当に定期実行されていて、関数の実行も正常に行われていそう確認します。Monitoring タブをクリックして、関数の実行状況を確認していきます。

Monitoring タブをクリックする" />
1. Monitoring タブをクリックする

2. Lambda 関数が定期実行されていることを確認する

3. Lambda 関数の実行結果が正しいことも確認する

これで作業完了です。お疲れさまでした。

📔 2020年の振り返り

2020-12-31T17:34:56+09:00

はじめに

今年は結果的にプライベートと仕事の両面で充実した年にできました。来年の自分が今を振り返れるように、今年始めからの記憶を引っ張り出しながら総括しました。

今年問わず作ったものは Tech ページに、技術記事については RSS Feeds にまとめてあります。

出来事

1月

Death Stranding のプラチナ獲得
弊社に面接にいらっしゃったベテラン開発者の方に何でうちに応募してくださったのか聞いたら、僕の Twitter や Qiita アカウントを見てくださり技術力がありそうと判断してくれたからと聞いて爆嬉しかった
ambr オフ会参加 (オフィシャルなオフ会に初参加)
Quest 用アプリケーションの初リリース体験実績解除
- 申請時の知見の一部については Qiita 記事として投下
Android で AR アプリケーションの開発及び、マルチプレイを可能にするバックエンド開発を担当した

2月

Docker で各種モバイル VR 向けの Unity ビルドが出来るようにした
フルリモートでアジャイルな開発チームにジョインする (WebView/ReactNative/iOS/Android)
- 主は ReactNative の iOS/Android のネイティブプラグイン開発
- コア機能の実装にのみ注力しパフォーマンスチューニング等々を行っていたためポジション的にはひたすら地味だった

3月

note デビューした
- 初投稿は精神衛生を保つため Chrome で Twitter を閲覧している時にフォロワー数を非表示にするっていうやつ
お題が「Home」の web1week に参加した
- 参加した時に投稿した記事はこちら

4月

会社の Medium ブログ開設したのと、いくつか記事を寄稿した
- Azure Kinect DK の開発環境構築から KinectFusion のサンプルを動かすまで
- 最短で Magic Leap 1 の開発環境を構築する
色々工夫して iPhone TrueDepth を WebRTC でブラウザに転送して、Three.js で表示する仕組みを実現した
- Twitter でシェアしてみたら、予想だにしないことに一方的に尊敬していたエンジニアの方々からいいねを貰えてモチベが爆上がりした
CloudFormation と和解。IaC の利便性を完全に理解し始める
今更 SEKIRO にハマりまくる & プラチナトロフィー獲得
デス・ストランディングから学んだことが現在の自分の考え方の基礎として根付き始める
- 全ての考え方を 0 or 1 ではなく、グラデーションにハメ込むことが出来るようになった

5月

再びお題が「Like」の web1week に参加した
- 参加した時に投稿した記事はこちら (あとから確認したら投稿先を間違えていた...)
Medium に目次が無いことに不満をいただき Chrome プラグインを作成する
- プラグインの紹介記事まで書いてたけど全くインストール数伸びなかった、、けど今みたら 12人ほど使ってくれている人いるぽくて嬉しい
お題が「密」の unity1week に参戦した

6月

S3 + EventBridge + CloudWatch + CloudFront + MediaLive + MediaPackage + AppSync + Amplify + DynamoDB + Cognito + Lambda + API Gateway + SSM という AWS ガッツリなインフラ構築から、バックエンド開発及び iOS アプリ開発までをおもむろに始めた
- まず DynamoDB の仕様にハマる (自分のリサーチ & 勉強不足によるせい...)
- つぎに MediaPackage + CloudFront の構築に苦戦する
- そしてデバッグが辛くなり Serverless Framework でエラーを検知して Webhook で Slack に通知を飛ばす方法を実践し始めたりしていた
シェンムー3 のプレイを開始。ワクワクするし美しすぎる町並みに興奮し、しばらくの間深夜までプレイする日々が続く
映画の HELLO WORLD を見て、劇中 3回号泣する
- 元々は Unity で作られたシーンがあるという記事を見て興味を持ち見ようと思い立った感じだった

7月

ひたすらトラブルバスターしてた (一番忙しかった気がする)

8月

Ghost of Tsushima にハマりまくる & プラチナトロフィー獲得
DDD 開発の際、DI コンテナ入れたいよねっていう話から TypeScript 環境で利用可能なライブラリを調査して InversifyJS と tsyringe を見つける
- 最初 InversifyJS を発見してそれで開発をしていたものの、microsoft 製の tsyringe を発見し、「メンテナが大手だしコンストラクタインジェクションだけしか使わないし、こっちのが良くね？」という話になり InversifyJS から tsyringe へのリライト作業を行う...w
AWS SDK for Go で関数の引数と返り値を Type で定義するっていう考え方は非常に参考になった
- 引数が *Input という定義で、返り値が *Output という定義で分かりやすく読みやすい
自作 iOS ライブラリの CocoaPods 対応について C++ 周りの linker error に対する解決のためのアドバイスを急ぎ求められたので、共有された情報から自分がハマった経験に照らし合わせてソレっぽい対策案を共有したらガチッとハマって解決でき、経験が生きた感がめっちゃあって、めちゃくちゃ嬉しかった

9月

フライパンでコーヒーの焙煎を始める
- チャフの飛散に苦しめられるが、風呂場で作業することで諸々ストレスフリーになる
- このときはまだ、後ほど焙煎機を購入することになるとは夢にも思わなかったのである...
Azure を用いた開発に本格的に携わり始める
- その際得た知見は Zenn で本としてまとめた。本来は記事として書くつもりだったが、分量が増えすぎたため記事内容を分割して、本としてまとめた
- PlayFab CloudFunctions のための関数実装のために Azure でシステム構築していたため、PlayFab にもそれなりに詳しくなる
とある案件から別案件に移る際に、 「えー、〇〇に行っちゃうんですか。nikaera さんは今後も〇〇を一緒にやっていって欲しいのに」 って結構強めに言われたことが未だにめちゃくちゃ嬉しい
シンガポール現地のフリーランスの方と仕事を共同で進めることになる。技術に関する事柄やプライベートに関する事柄のやり取り等々、全て英語でコミュニケーションを行わざるを得なくなり、そのおかげで英語でコミュニケーションを取ることに一切抵抗が無くなる

10月

約 10 年ぶりに私用携帯を HTC EVO から iPhone 12 mini に機種変する
- 開発用途でなく普段生活で使うことのみを考慮するということであれば iPhone 12 mini は最強にオススメできるスマホです
- 会社支給のスマホで 7年近くを賄っていたため、特に不便がなかったため...
AWS Amplify への PR がマージされる
- もとは serverless-amplify-simulator の Issue で議論していたのだが、改修すべき内容は amplify-cli にあったのでそちらで PR を提出した
- 細かくづまづいた点を進捗共有兼ねて Issue で一人投稿しまくっておくと、他の開発者の役にも立てるし自然とその問題に詳しくなっていくし、OSS 活動への取っ掛かりとしては最高なんじゃないかと勝手に思い始める
NPM に初自作ライブラリを公開する
- serverless-amplify-auth という Amplify 開発を行う際は必ず行うであろう IAM Policy の制限を Serverless で行うことが出来るようにするやつ

11月

Hugo で自分のブログ(nikaera.com)を GitHub Pages 上に構築する
カジュアル面談した人に Qiita のネタ記事見ましたって言われて嬉しいよりも恥ずかしいが上回った
Etsy でアクセサリ販売している方に日本のフリマ事情を詳細にお伝えしたらおまけのプレゼントを送付してくださった
- ちなみに購入物は Death Stranding のドリームキャッチャー
Moonlander が自宅に届きテンション上がって紹介記事を書く

12月

今年学んだ重要なことを記事として残しといた (これもある意味総括な気がする)
GitHub Profile を充実させる
- こんな感じ -> https://github.com/nikaera
- 更に GitHub Profile を充実させるために Zenn のバッジを作成するサービスを作った
Lapras の技術力スコアが 3.36 になってた
- 基準とか良く分からないけど純粋に上位 13% に入ったと言われてるのは嬉しかった
いくつか空いてたアドベントカレンダーに参戦した
- MediaPackage 用の CloudFront ディストリビューションを AWS SDK で作成する
- Serverless のプラグインを TypeScript で作成する方法
AWS Lambda を用いた他社製品との連携システムが好評で、去年から今年末まで特に目立った不具合等も起きずに運用できたため、次期開発に繋がりそうとの連絡があり開発者として爆喜ぶ

おわりに

今年は後半からすごい勢いでギアが入ってきた感があり、諸々活動するための足がかりを作れた気がします。身も心も進化したなと思えて成長できたなという充足感は割と高めな 1年だったので、この勢いのまま 2021 年もマイペースに色んなことにチャレンジしていければなーと思っております。

この記事を書いている人物のプロフィールは Profile からご確認いただけます。何かございましたら Contact からお気軽にご連絡くださいませ。

それではみなさま良いお年を！！😆

nikaeraの投稿 - Crieit

📔 ECS Fargate のメトリクスを Prometheus Agent 使って AMP に送って Grafana で監視する

📔Unity で iOS/Android アプリの設定値をセキュアに扱う方法

📝 Azure Cosmos DB でソートしようとするとフリーズする

📔 マイペースに技術研鑽を継続する方法

📝 pytest で alembic のマイグレーションを行う方法

📝 Node.js パッケージを公開するための GitHub Actions を構築する

📝 Chrome 拡張で 1つのウインドウを使い回す方法

📔 チャットの短文作成に便利な Chrome 拡張機能を開発してみた

Teemo で絵文字を : でショートカット入力する 💨

📝 Rails で config/database.yml よりも ENV['DATABASE_URL'] の設定が優先される話

GameCI で Unity の CI 環境を GitHub Actions で構築する

📝 Pillow を使って画像に縦書きテキストを埋め込む

Zenn の記事を DEV に自動的に同期させる GitHub Action 作ってみた

📔 PlayFab の API 制限に引っかかった

Gatling で複数ユーザ認証した情報を元に負荷テストする

📝 Jest で private readonly な値をモックする方法

AWS Lightsail Containers に Actix web をデプロイする

Actix web で HttpOnly な Cookie を設定する

📔 ブログを書く用途に特化した Gyazo のツールを開発してみた

📝 AWS Lambda で cron みたいに定期実行する

📔 2020年の振り返り

Teemo で絵文字を `:` でショートカット入力する 💨