「AWS」の記事 - Crieit

【AWS】EC2インスタンスに割当されたパブリックIPv4アドレスをRoute 53に登録するシェルスクリプト（IMDSv2版）

2024-03-05T17:01:50+09:00

参考記事

【出典】クラスメソッド：【Route53】EC2 から自身に付与されたパブリックIP を Route53 に設定したい
https://dev.classmethod.jp/articles/route53-record-ip-change-by-aws-cli/

IMDSv2が有効だと参考記事のシェルスクリプトは動かない！

IMDSv1はこれで良いが、IMDSv2が有効だと以下ではパブリックIPv4アドレスが取得不可です

IP_ADDRESS=`curl -s http://169.254.169.254/latest/meta-data/public-ipv4`

IMDSv2でパブリックIPv4アドレスを取得する方法は以下が参考になります

【出典】Amazon公式：インスタンスメタデータの取得
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html

IMDSv2対応版シェルスクリプト

Amazon公式情報を参考に修正したシェルスクリプトがこちら

#!/bin/bash
DOMAIN_NAME="example.me"
SUB_NAME="test01"
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
IP_ADDRESS=`curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/public-ipv4`

HOSTED_ZONE_ID="ZONE-IDを入力"

BATCH_JSON='{
  "Changes": [
    { "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "'${SUB_NAME}'.'${DOMAIN_NAME}'",
        "Type": "A",
        "TTL" : 300,
        "ResourceRecords": [
          { "Value": "'${IP_ADDRESS}'" }
        ]
      }
    }
  ]
}'

aws route53 change-resource-record-sets --hosted-zone-id ${HOSTED_ZONE_ID}  --change-batch "${BATCH_JSON}"

所感

IMDSv2についてよくわかっていなかったが、今回の件でIMDSv1との違いが少し理解できました。

【AWS】AWS IPアドレスの範囲から、東京リージョンの EC2 Instance Connect の範囲を検索する

2023-11-02T10:39:54+09:00

以下のコマンドを実行

（EC2やmacは、curlやjqがインストールされていない場合にはインストールが必要です）
実行することで東京リージョンの EC2 Instance Connect の範囲を絞り込んで出力できます

$ curl -s https://ip-ranges.amazonaws.com/ip-ranges.json| jq -r '.prefixes[] | select(.region=="ap-northeast-1") | select(.service=="EC2_INSTANCE_CONNECT") | .ip_prefix'

出力結果（2023/11現在）

3.112.23.0/29

ふと思ったこと

EC2 Instance Connect の範囲をマネージドプレフィックスリストに登録して、セキュリティグループで参照するようにしておけば、もし範囲が変わってもリストを更新するだけで済みそうですね。

Redshift Serverless について見かけた課題と対応策

2022-08-12T19:16:44+09:00

Redshift Serverless について見かけた課題と対応策（2022年7月19日時点）をまとめました。GitHubリポジトリ「Awesome Redshift JP」にまとめた内容の転記です。

概要

プレビュー料金に見える→金額あってそう
名前空間やワークグループの削除エラー→英語表示
ProvisionedとAPIが違う→ラッパーを使う
時間課金でストリーミング不向き→二台構成 or マイクロバッチ化

Redshift Serverless の料金表が「プレビュー」のままに見える（2022年7月19日時点）

日本語だと「プレビュー」の記載がありますが、英語だとPreviewの記載は外れています。料金表の内容も同じなので、日本語の翻訳が間に合っていないようです。

日本語の料金表:

英語の料金表:

Redshift Serverless の名前空間やワークグループの削除ができない（2022年7月19日時点）

日本語表示だとコンソールでエラーになってしまう。

Amazon Redshift Serverlessで名前空間もワークグループもコンソールのエラーで削除できない
https://twitter.com/Korosuke512tr/status/1547783609666265089

解決策1) 管理コンソールを日本語から英語に変える。

管理コンソールの言語を英語に変更して試していただくと、削除できるようになるかもしれません。
https://twitter.com/simosako/status/1547790642926870528

解決策2) CLI経由で削除する。

CLI で消せた
https://twitter.com/hayaok3/status/1547086353489620992

Redshift Serverless の credentials はiamが別

redshift:GetClusterCredentials ではなく redshift-serverless:GetCredentials が対象となる。

一時的な認証情報を使用してサーバーレスワークグループへの認証を行う場合は、ポリシーで redshift-serverless:GetCredentials アクションの使用が許可されていることを確認します。 > https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/data-api.html

非公式ラッパーとして https://github.com/mashiike/redshift-credentials が作られた。

ServerlessなのかProvisionedなのか意識して、更にAPIの投げわけしないといけないの？そう思った人（私）向けにServerlessでもProvisionedでも、どっちのエンドポイントをパラメータに渡してもいい感じに一時認証してDB USERとDB Passwordを返してくれる君を書いてみました。
https://datatech-jp.slack.com/archives/C03MHCZS2GG/p1657977637298559

Redshift Serverless は時間課金なのでバッチ向き

ストリーミング連携など、高頻度にデータ連携するときは以下の構成だとコスト効率が良い。

小さめの常駐インスタンスにデータを流す。
Redshift ServerlessからData Sharingで常駐インスタンスを参照する。

https://twitter.com/mashiike/status/1547032218140192768

Redshift Serverlessで完結したい場合は、ログをストリーミングでS3に反映しつつ、 Redshiftへのロードは1時間に1回のマイクロバッチで実現するような設計が考えられる。

https://twitter.com/yuzutas0/status/1547011222998220800

最後に

「Awesome Redshift JP」では、Amazon Redshift によるデータ活用を実現するためのノウハウや参考資料をまとめています。主に、Slackコミュニティ「datatech-jp」の「#redshift」チャンネルで会話しています。オススメの記事があればリポジトリに反映したいのでぜひ教えてください。

📔 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 つとなれたら幸いです。

参考リンク

【個人開発】（Nuxt.js + Rails）OSSやプロジェクトの、ソースコードを管理するGitHubのように、web上で結合テストをチームで同時に管理・実行・記録出来るプラットフォームを開発しました！

2021-10-25T15:29:45+09:00

はじめに

今回、個人で開発したWebサービス「Itamaster」の本番稼働版をリリースすることが出来ました！
こちらのサービスを開発しようと思った経緯は、ある日会社で、統合テストの管理・実行を行っていたときに、「何故ソースコードの管理プラットフォーム（GitHub等）はあるのに、結合テストの管理プラットフォームは無いんだろう」と思った事がきっかけです。
開発期間は八ヶ月ほど、作業工数は大体700時間です。

弊社、私の所属しているチームは結合テストはExcelによって管理しており、実行記録もExcelを利用しています。
Excelでの管理・実行には、以下のような不便な点がありました。

Excelでの作業は、PCにかかる負荷が大きかったこと。
会社のPCは自宅で扱うようなハイスペックなものではないため、Excelで作業を行っていると、セルをコピーしたりした時にPCがフリーズしたり、突然Excelが落ちて、保存していないデータが復旧しなかったりと、作業中に感じるストレスがとても大きかったです。
Excelだと、複数人で一つのファイルに対する作業が出来ないこと。
共有設定にして複数人で同時に作業すると、Excelが一層重くなったりして、とても実用出来るものではありませんでした。
Excelだと、一つのファイルは同時に一人でしか作業が出来ず、待ち時間の発生するメンバーがいました。
ローカルで作業しているメンバーの作業状況が把握出来ないこと。
私は管理者経験はありませんが、毎日の定時報告会や、Slackでのメッセージを見る限り、作業状況の把握が少しアナログに感じました。
Redmine等の進捗管理ツールも利用していますが、結局は自己申告であり、「どのくらいの作業が終わっていて、残っているのか」を管理者が一目で把握することが出来れば、課題を解決できると考えました。
サマリーレポートや、結果一覧表の作成が面倒
Excelから情報を整理して、Excelに表を作って、割合を求めて、グラフ化して......
テストが追加されたり、状況が変わると、また、情報を整理して、Excelに表を作って、割合を求めて、グラフ化して......
「あ"あ"あ"あ"あ"あ"あ"あ"あ"あ"あ"あ"あ"あ"あ"あ"あ"！！！！！！！」
ってなりました。

開発告知記事を書くのは初めてで、至らない点が多々あるかと思いますが
サービスの紹介、開発時の苦労や反省、所感を統括して書きたいと思います。
最後まで読んでいただければ幸いです。

【Twitterリンク】
https://twitter.com/@itamaster_

【Itamaster】
https://itamaster.work
PC推奨です。

【Itamaster　操作ガイド】（Itamasterのヘッダーと、フッターにも操作ガイドリンクを設置しています。）
https://qiita.com/Itamaster/items/3c271181e0c9c06d1d08

使用技術

npm 7.6.3
nuxtjs 2.15.3 (SPA モード)
- サクサクと、Excelのようなもっさり感やストレスの無いUXにしたかったため、SPAによって構築しました。
@nuxtjs/storybook 4.0.2
- コンポーネントのレイアウト・動作を開発中にリアルタイムで確認出来る、コンポーネントカタログ作成ツール。
  フロントエンドの単体テストの役割も果たします。
vuetify (@nuxtjs/vuetify 1.12.1)
- MaterialDesignベースのデザインライブラリです。
  少し挙動が不安定な点が目立ちました。
ruby 2.6.8
Ruby on Rails 6.1.4 (APIモード)
Device
- ログイン周り。フロントエンドにはトークンを渡します。フロントエンドではトークンをsession storageに一時保存し、axiosのインターセプターに噛ませることで、ログイン機能付きの認証認可を実現しました。
EC2(t2.small)
S3
ALB
ACM
RDS (mysql)
Route53
nginx
Stripe
- クレジットカード決済機能をAPI利用できます。
  顧客情報や、クレジットカード情報を自サーバーで持たなくてよいため、セキュアなシステムの構築が可能です。
  また、同様に、決済機能のAPI利用はリスク管理の面からも有効です。

アプリ概要

結合テストの自動化を行わないチームや、手動でのテストを行いたい状況が対象のWebサービスです。
ユーザーをメールアドレスで招待し、チームを結成。
プロジェクトを立ち上げて、テストスイート毎にテストケースを管理・実行が出来ます。

⇓チームの情報を表示するダイアログ

⇓プロジェクト、プロジェクト内のテストスイートの管理を行う画面

⇓テストスイートの情報を表示するダイアログ

⇓テストケースの情報を表示するダイアログ

⇓テストスイート内のテストケースを実行する画面

また、テスト結果一覧表や、テストサマリーレポートも出力可能です。

こだわった箇所

全体的に、明るい色を起用すること

テストという地味な作業は、設計書作成の次に気が滅入り易くなります。
暗い気持ちになってしまわぬよう、明るい色を起用しつつ、
緑や薄めの青色をメインに使う事で、ユーザーのモチベーションを維持します。

アイコンを多用し、直感的な操作を可能にすること

画面にはアイコンを多用して、文字を読まなくても色とアイコンから、ボタンの機能を推測することが可能です。
直感的に操作することが可能で、作業の効率を向上します。

進捗バーをプロジェクトと、テストスイート毎に表示可能にし、一目で状況を確認可能に

色分けされた進捗バーは、ホバーすることでそれぞれのステータスの件数を確認可能です。

チームの管理者が、「現在プロジェクト全体で、どれだけのテストが完了しているのか」を一目で確認することが可能です。

自分独自のアイコンを設定可能にすること

Itamasterは、GitHubのように、OSSのテストをオープンに行う事の出来るプラットフォームを目指します。
アイコンを設定可能にし、画面に多用することで、今後実装するSNS的な機能が違和感なく利用できます。
（Publicなプロジェクトを表示・検索し、運営しているチームとダイレクトにメッセージをやり取りし、テストを世界中のメンバーと共同して行うような）

サービス改善告知

2021/10/17 サービスに、操作ガイドページ・Demoページを追加実装しました！

操作ガイドページでは、サービス内の全てのボタンや、項目の意味、操作方法やユースケースを記述しております。
Demoページでは、実際の画面にモックデーターを流し込んだものを使い、操作感や使用イメージを持っていただくことを目的としています。
どちらも無料でご利用いただける機能ですので、よろしければお楽しみください！

2021/10/20 トップページのレイアウトを変更しました！

旧：

新：

変更にあたって、具体的に意識した点

設計思想をメインコンセプトとして表示
注目線を意識し、印象付けたい文言を左側に配置する

アニメーションが少しだけ配置されているので、実際に見ていただければ、と存じます！

サービスのこれから

トップページのレイアウト改善

とりあえず、第一課題です。
現状注目線があっちこっちに行ってしまっており、とてもわかりにくいページになっています。
デザインを勉強しつつ、わかりやすく、「使ってみたい」と思っていただけるようなトップページにしたいと思っております。

チーム公開機能の実装

public設定のチームをいくつか表示し、興味の出たOSSのテスト等に世界中から参画希望を出せるようにします。
本来の設計思想である、「何故OSSをGitで管理するように、テストを世界中のエンジニアと管理実行するプラットフォームは無いのか」という疑問を解決する機能なので、じっくり作り込みたいと思っています。
現状は、
・Topics
・Search
・Explore
の三画面を開発して、世界中のチームを見られるようにしたいと思っています。

OCIやAWS上のサーバの環境構築

2021-10-20T03:32:37+09:00

1．公開鍵認証方式でssh接続

1-1．キーの作成(おまけ)

Windowsのコマンドプロンプトで，

＞ssh-keygen -b 4096

（4096は任意鍵長）と打つと，~/.sshに公開鍵と秘密鍵が作成される．例えばユーザー名がTanakaさんなら．C:\Users\Tanaka\.sshに作成される．
秘密鍵のファイル名がid_rsaで，公開鍵がid_rsa.pubとなる．

以降の話ではこの節はあまり関係ない．

1-2．OCIでインスタンス作成

sshキーにスポットをあてて話を進める．

1-2-1．キーペアを持っていない場合

[ SSHキーの追加 ]欄で，[キー・ペアを自動で生成 ]を選択し，
[公開キーの保存]→[秘密キーの保存]をクリックすることでキーペア取得できる．
この2つのファイルは大切に保管しましょう．(今後も使いまわせるので)

保存された2つのファイルは，
公開鍵が~.key.pub
秘密鍵が~.key
となっている．

この2つのファイルはどこか好きなディレクトリに格納しとこう．
例：C:\Users\Tanaka\Documents\Oracle

インスタンスを作成．

1-2-2．キーペアを持っている場合

OCIでインスタンスを作成する際，[sshキーの追加]欄がある．
ここで，[公開キー・ファイル(.pub)のアップロード]を選択し，
自身の公開鍵のファイル(~.key.pub)をドラッグ&ドロップでアップロード．
インスタンスを作成．

1-3．ssh接続

sshクライアントを起動してssh接続を試みる．

1-3-1．TeraTermの場合

TeraTermを起動させたら[ ホスト(T) ]にIPアドレスを書いて，
その下の[ TCPポート ]欄に「22」と書く※1．
[ ok ]ボタンを押す．

[ ユーザ名 ]に指定されたユーザ名を記入．
OCIのCentOSの初期ユーザ名は「opc」※2．

[ 認証方式 ]で，[ RSA/DSA/ECDSA/ED25119鍵を使う]を選択し，
1-1節で作成した秘密鍵のパスを指定．
例:

C:\Users\Tanaka\Documents\Oracle\~.key

これで接続できる．

※1：sshのデフォルトのport番号が22．これは後で利用できるport番号内で任意番号に変更可能
※2：AWSのRHEL8の場合は「ec2-user」

1-3-2．PowerShellの場合

これだけ．

> ssh -i [秘密鍵のパス] [ユーザ名]@[IPアドレス]

以上。

２. 環境設定

2-1．パスワード設定

ログインできたら，rootユーザとログインユーザ(今回であればopc)のPassを任意に設定しとく．
まずはroot

$sudo passwd root
(パスワード聞かれるので適当に打つ)
(切り替わるか確かめる)
$ su -

次は別のユーザ

#passwd opc

2-2．ssh接続のconfファイル書き換え

セキュリティの観点から，ssh接続のconfigファイルを書き換える．

$ sudo vi /etc/ssh/sshd_config

とやるといろいろ書き換えられる．
英語読めば何の設定なのか想像つくと思うのでてきとーにやっとく．

Port 11326  (←port番号を22から変更)
PermitRootLogin no (←Rootユーザでログインできないようにする)
PubkeyAuthentication yes  (←公開鍵認証方式）
PasswordAuthentication no (←パスワード認証を無効化)
などなど

これではまだ反映されないので，reloadしてメモリの設定を読み込ませる．
（restartじゃないよ)

$ sudo systemctl reload sshd.service

2-3．タイムゾーンを変更

タイムゾーンを東京に変更しとく．

$ sudo timedatectl set-timezone Asia/Tokyo

2-4．変更確かめ

Windows端末のPowerShellでPortして疎通確認．

> Test-NetConnection [ IPアドレス ] -Port [ Port番号 ]

3．yum

参考：https://access.redhat.com/ja/articles/3221791

/etc/yum.confと/etc/yum.repos.dの二つの領域に分かれる。
※rhel8からはyumは廃止されdnfに置き換わっている。使い方はほぼ同じ。
実際、/etc/をみてみると、

[root@publicpc1 etc]# ll|grep yum
drwxr-xr-x.  2 root               root                   57 Mar 24 12:32 yum
lrwxrwxrwx.  1 root               root                   12 Nov 12 00:18 yum.conf -> dnf/dnf.conf
drwxr-xr-x.  2 root               root                  217 Mar 24 12:39 yum.repos.d

[root@publicpc1 yum]# pwd
/etc/yum
[root@publicpc1 yum]# ll
total 0
lrwxrwxrwx. 1 root root 14 Nov 12 00:18 pluginconf.d -> ../dnf/plugins
lrwxrwxrwx. 1 root root 18 Nov 12 00:18 protected.d -> ../dnf/protected.d
lrwxrwxrwx. 1 root root 11 Nov 12 00:18 vars -> ../dnf/vars

となっている。

3-1. yum.conf(dnf.conf)

[root@publicpc1 etc]# cat yum.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False

[main]はセクション名で、ここに記載されているのはyumのグローバルな設定。

gpgcheck

は署名チェック。1が有効で、0が無効。

3-2. yum.repos.d

[root@publicpc1 yum.repos.d]# ll
total 32
-rw-r--r--. 1 root root  495 May  5  2021 ksplice-ol8.repo
-rw-r--r--. 1 root root  759 Apr 13  2021 mysql-ol8.repo
-rw-r--r--. 1 root root  253 Mar 20  2021 oci-included-ol8.repo
-rw-r--r--. 1 root root  252 Mar 24 12:39 oracle-epel-ol8.repo
-rw-r--r--. 1 root root  694 Mar 24 12:39 oraclelinux-developer-ol8.repo
-rw-r--r--. 1 root root 2740 Mar 24 12:39 oracle-linux-ol8.repo
-rw-r--r--. 1 root root  470 Mar 11 01:09 uek-ol8.repo
-rw-r--r--. 1 root root  243 Mar 11 01:09 virt-ol8.repo

oracle-linux-ol8.repoの中身を見てみると、ダウンロードする際に参照するURLが記載されている。
ここが間違っていると適切にインストールできなくなる。
ただ、ここを編集することはなさそう。

もし社内にあるレポジトリサーバを利用したい場合、対応は２つある。
１つは、 yum.repos.d配下に~.repoファイルを追加する。
２つ目は、yum -y install ～で追加する方法。

１つ目の場合

# vim /etc/ yum.repos.d/test.repo
[test]
name=test
baseurl=http://xxx.xxx/xxx.xxx/xxx
gpgcheck=0

など。

4．踏み台サーバの準備

4-1．キーペアの準備

4-2．scpでファイル転送

4-3．公開鍵認証の読み込みパス指定

https://crieit.net/posts/OCI-CentOS

5. Port ForwardingでRDP接続

5.1 sshトンネリング

6．Pythonインストール

7．OCI CLIの利用方法

公式ドキュメントを参考に進めていくとインストールできる。

7.1 Oracle Linux8でオンラインインストール

参考
OCIのクイックインストール：https://docs.oracle.com/ja-jp/iaas/Content/API/SDKDocs/cliinstall.htm#InstallingCLI__linux_and_unix

7.1.1 dnfでインストール

dnfを使用してCLIをインストール

$ sudo dnf -y install oraclelinux-developer-release-el8
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for opc:
Ksplice for Oracle Linux 8 (x86_64)                             16 MB/s | 1.2 MB     00:00
MySQL 8.0 for Oracle Linux 8 (x86_64)                          9.1 MB/s | 2.4 MB     00:00
MySQL 8.0 Tools Community for Oracle Linux 8 (x86_64)          5.2 MB/s | 308 kB     00:00
MySQL 8.0 Connectors Community for Oracle Linux 8 (x86_64)     214 kB/s |  23 kB     00:00
Oracle Software for OCI users on Oracle Linux 8 (x86_64)        38 MB/s |  46 MB     00:01
Oracle Linux 8 BaseOS Latest (x86_64)                           62 MB/s |  49 MB     00:00
Oracle Linux 8 Application Stream (x86_64)                      48 MB/s |  37 MB     00:00
Oracle Linux 8 Addons (x86_64)                                  21 MB/s | 4.9 MB     00:00
Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linu  63 MB/s |  53 MB     00:00
Package oraclelinux-developer-release-el8-1.0-7.el8.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

続いて、cliをインストール

$ sudo dnf install python36-oci-cli
Last metadata expiration check: 0:00:34 ago on Sat 13 Aug 2022 03:23:12 PM GMT.
Dependencies resolved.
===============================================================================================
 Package                        Arch        Version                Repository             Size
===============================================================================================
Installing:
 python36-oci-cli               noarch      3.14.0-1.el8           ol8_oci_included       14 M
Upgrading:
 python36-oci-sdk               x86_64      2.78.0-1.el8           ol8_oci_included       23 M
Installing dependencies:
 python3-arrow                  noarch      1.1.1-1.el8            ol8_oci_included      119 k
 python3-jmespath               noarch      0.10.0-1.el8           ol8_oci_included       48 k
 python3-prompt-toolkit         noarch      3.0.29-1.0.2.el8       ol8_oci_included      669 k
 python3-terminaltables         noarch      3.1.0-1.0.1.el8        ol8_oci_included       31 k
 python3-typing-extensions      noarch      3.7.4.2-1.el8          ol8_oci_included       47 k
 python3-wcwidth                noarch      0.2.5-3.el8            ol8_oci_included       48 k

Transaction Summary
===============================================================================================
Install  7 Packages
Upgrade  1 Package

Total download size: 38 M
Is this ok [y/N]: y
Downloading Packages:
(1/8): python3-jmespath-0.10.0-1.el8.noarch.rpm                520 kB/s |  48 kB     00:00
(2/8): python3-prompt-toolkit-3.0.29-1.0.2.el8.noarch.rpm      4.2 MB/s | 669 kB     00:00
(3/8): python3-arrow-1.1.1-1.el8.noarch.rpm                    740 kB/s | 119 kB     00:00
(4/8): python3-terminaltables-3.1.0-1.0.1.el8.noarch.rpm       298 kB/s |  31 kB     00:00
(5/8): python3-typing-extensions-3.7.4.2-1.el8.noarch.rpm      739 kB/s |  47 kB     00:00
(6/8): python3-wcwidth-0.2.5-3.el8.noarch.rpm                  711 kB/s |  48 kB     00:00
(7/8): python36-oci-cli-3.14.0-1.el8.noarch.rpm                 46 MB/s |  14 MB     00:00
(8/8): python36-oci-sdk-2.78.0-1.el8.x86_64.rpm                 37 MB/s |  23 MB     00:00
-----------------------------------------------------------------------------------------------
Total                                                           45 MB/s |  38 MB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                       1/1
  Upgrading        : python36-oci-sdk-2.78.0-1.el8.x86_64                                  1/9
  Installing       : python3-wcwidth-0.2.5-3.el8.noarch                                    2/9
  Installing       : python3-prompt-toolkit-3.0.29-1.0.2.el8.noarch                        3/9
  Installing       : python3-typing-extensions-3.7.4.2-1.el8.noarch                        4/9
  Installing       : python3-arrow-1.1.1-1.el8.noarch                                      5/9
  Installing       : python3-terminaltables-3.1.0-1.0.1.el8.noarch                         6/9
  Installing       : python3-jmespath-0.10.0-1.el8.noarch                                  7/9
  Installing       : python36-oci-cli-3.14.0-1.el8.noarch                                  8/9
  Cleanup          : python36-oci-sdk-2.75.1-1.el8.x86_64                                  9/9
  Running scriptlet: python36-oci-sdk-2.75.1-1.el8.x86_64                                  9/9
  Verifying        : python3-arrow-1.1.1-1.el8.noarch                                      1/9
  Verifying        : python3-jmespath-0.10.0-1.el8.noarch                                  2/9
  Verifying        : python3-prompt-toolkit-3.0.29-1.0.2.el8.noarch                        3/9
  Verifying        : python3-terminaltables-3.1.0-1.0.1.el8.noarch                         4/9
  Verifying        : python3-typing-extensions-3.7.4.2-1.el8.noarch                        5/9
  Verifying        : python3-wcwidth-0.2.5-3.el8.noarch                                    6/9
  Verifying        : python36-oci-cli-3.14.0-1.el8.noarch                                  7/9
  Verifying        : python36-oci-sdk-2.78.0-1.el8.x86_64                                  8/9
  Verifying        : python36-oci-sdk-2.75.1-1.el8.x86_64                                  9/9

Upgraded:
  python36-oci-sdk-2.78.0-1.el8.x86_64
Installed:
  python3-arrow-1.1.1-1.el8.noarch               python3-jmespath-0.10.0-1.el8.noarch
  python3-prompt-toolkit-3.0.29-1.0.2.el8.noarch python3-terminaltables-3.1.0-1.0.1.el8.noarch
  python3-typing-extensions-3.7.4.2-1.el8.noarch python3-wcwidth-0.2.5-3.el8.noarch
  python36-oci-cli-3.14.0-1.el8.noarch

Complete!

インストール完了したらバージョン確認。

$ oci --version
3.14.0

7.1.2 構成ファイルの設定

$ oci setup config
    This command provides a walkthrough of creating a valid CLI config file.
    The following links explain where to find the information required by this
    script:
    User API Signing Key, OCID and Tenancy OCID:      https://docs.cloud.oracle.com/Content/API/Concepts/apisigningkey.htm#Other
    Region:
        https://docs.cloud.oracle.com/Content/General/Concepts/regions.htm
    General config documentation:
        https://docs.cloud.oracle.com/Content/API/Concepts/sdkconfig.htm

Enter a location for your config [/home/opc/.oci/config]:特に指定しなくてok
Enter a user OCID: OCIコンソールよりユーザのOCIDをコピペ
Enter a tenancy OCID: OCIコンソールよりコピペ
Enter a region by index or name(e.g.
1: af-johannesburg-1, 2: ap-chiyoda-1, 3: ap-chuncheon-1, 4: ap-dcc-canberra-1, 5: ap-hyderabad-1,
6: ap-ibaraki-1, 7: ap-melbourne-1, 8: ap-mumbai-1, 9: ap-osaka-1, 10: ap-seoul-1,
11: ap-singapore-1, 12: ap-sydney-1, 13: ap-tokyo-1, 14: ca-montreal-1, 15: ca-toronto-1,
16: eu-amsterdam-1, 17: eu-frankfurt-1, 18: eu-marseille-1, 19: eu-milan-1, 20: eu-paris-1,
21: eu-stockholm-1, 22: eu-zurich-1, 23: il-jerusalem-1, 24: me-abudhabi-1, 25: me-dcc-muscat-1,
26: me-dubai-1, 27: me-jeddah-1, 28: mx-queretaro-1, 29: sa-santiago-1, 30: sa-saopaulo-1,
31: sa-vinhedo-1, 32: uk-cardiff-1, 33: uk-gov-cardiff-1, 34: uk-gov-london-1, 35: uk-london-1,
36: us-ashburn-1, 37: us-gov-ashburn-1, 38: us-gov-chicago-1, 39: us-gov-phoenix-1, 40: us-langley-1,
41: us-luke-1, 42: us-phoenix-1, 43: us-sanjose-1): 13（OCIコンソールをブラウザで開いてURLを見るとわかる
Do you want to generate a new API Signing RSA key pair? (If you decline you will be asked to supply the path to an existing key.) [Y/n]: Y
Enter a directory for your keys to be created [/home/opc/.oci]:
Enter a name for your key [oci_api_key]:
Public key written to: /home/opc/.oci/oci_api_key_public.pem
Enter a passphrase for your private key (empty for no passphrase):
Private key written to: /home/opc/.oci/oci_api_key.pem
Fingerprint: ～なんか記載されている～
Config written to /home/opc/.oci/config

完了すると、~/.oci配下にoci_api_key_public.pemが作成されているはず。このキーをOCIコンソールで
アイデンティティ＞ユーザー＞ユーザーの詳細
に行くと、画面サブに「APIキー」があるのでクリックし、oci_api_key_public.pemの中身を張り付ける。

試しに実行してみる。

$ oci compute instance list --all
Usage: oci compute instance list [OPTIONS]
Error: Missing option(s) --compartment-id.

コンパートメントIDをオプションで追記しろとのこと。

$ oci compute instance list --compartment-id ＜OCID貼り付け＞
いっぱい表示された

ただ、毎回コンパートメントIDを打ち込むのは面倒なので、oci_cli_rcファイルに書き込むことでコマンド入力時にオプション付ける必要がないようにする。

$ vi ~/.oci/oci_cli_rc

[DEFAULT]
compartment-id=＜コンパートメントID＞

7.1.3 プライベートサブネットからOCI CLIを実行する方法

OCI CLIでコマンドを実行するとAPIエンドポイントと通信を行う。そのため、プライベートサブネットからAPIを発行してエンドポイントへ到達させるにはいくつかの設定が必要になる。方法は以下３つ。
①NATゲートウェイを利用してインターネットに出ていく。②サービスゲートウェイを使用して、OCI環境内に閉じた通信を行う。③プロキシを使用してインターネットへ出ていくルートを作る。

なずは何も設定しない状態でプライベートサブネットからコマンドを実行してみる。その際、APIの実行履歴を出力させるためにデバックオプション--debug(または-d）をつけて実行する。

$ oci compute instance list --all -d
~省略～
DEBUG:oci.base_client.140243454499864:Endpoint: https://iaas.ap-tokyo-1.oraclecloud.com/20160918
INFO:oci.base_client.140243454499864: 2022-08-14 15:05:12.072064: Request: GET https://iaas.ap-tokyo-1.oraclecloud.com/20160918/instances
INFO:oci.base_client.140243454499864: 2022-08-14 15:05:23.487363: Request: GET https://iaas.ap-tokyo-1.oraclecloud.com/20160918/instances
～つづく～

となり、エンドポイントへの接続を所定の回数試行して失敗すると、以下のようなエラーが返ってくる。

oci.exceptions.ConnectTimeout: (MaxRetryError("OCIConnectionPool(host='iaas.ap-tokyo-1.oraclecloud.com', port=443): Max retries exceeded with url: /20160918/instances?compartmentId=ocid1.compartment.oc1..aaaaaaaantybfae5pn7h77jmgcwgzg2hm27gv6whsiwhmo54ycefc3sxyiwa (Caused by ConnectTimeoutError(, 'Connection to iaas.ap-tokyo-1.oraclecloud.com timed out. (connect timeout=10.0)'))",), 'Request Endpoint: GET https://iaas.ap-tokyo-1.oraclecloud.com/20160918/instances See https://docs.oracle.com/en-us/iaas/Content/API/Concepts/sdk_troubleshooting.htm for help troubleshooting this error, or contact support and provide this full error message.')

実際、エンドポイント（iaas.ap-tokyo-1.oraclecloud.com）にpingを打っても返ってこない。

7.1.3.1 NATゲートウェイの利用

NATゲートウェイを作成して、プライベートサブネットのルート表に追加させる。

まずは、
ネットワーキング＞仮想クラウド・ネットワーク＞仮想クラウド・ネットワークの詳細＞NATゲートウェイ
から「NATゲートウェイの作成」を行う。作成したNATゲートウェイをルート表のルート・ルールに追加する。

追加できたら、まずはエンドポイント（iaas.ap-tokyo-1.oraclecloud.com）にpingを打つ。きっと返ってくるはずだ。
エンドポイントへの疎通が確認できたら、OCIコマンドを実行してみよう。

$ oci compute instance list --all -d

インスタンス情報が出力されたと思う。

7.1.3.2 サービスゲートウェイの利用

社内ルールで、むやみにインターネットに出ていける設定をしてはいけない場合もあるはず。そういった場合には、OCIのVCN内に閉じた環境でエンドポイントへの通信できるサービスゲートウェイを利用するといい。
ネットワーキング＞仮想クラウド・ネットワーク＞仮想クラウド・ネットワークの詳細＞サービス・ゲートウェイ
からサービスゲートウェイを作成する。

作成したら、さきほどと同じようにプライベートサブネットのルート表のルート・ルールに追加する。

$ oci compute instance list --all -d

インスタンス情報が出力されたと思う。

7.1.3.3 プロキシを使用してインターネット経由のルーティング

https通信を行う際にプロキシ経由するように設定をするだけでよい。

$ export HTTPS_PROXY=http://10.1.1.45:3128

設定した後はOCI CLIコマンドを実行すると成功するはずだ。

7.1.4 インスタンスプリンシパルの設定

7.2 インスタンスプリンシパルの設定

さきほどまではAPIを用いてユーザ認証を実行してきた。それとは別に、インスタンスに対して実行権限を付与させる方法がある。それがインスタンスプリンシパル。プリンシパルは操作の実行主体を指す。

7.2.1 別ユーザで実行する

7.3 仮想環境の作成

システム全体にCLIをインストールするのは非推奨。

7.3.1 仮想環境を構成するディレクトリ作成

仮想環境を構成するディレクトリを作成する。
このディレクトリは、仮想環境をアクティブ化する際に打つパスになるので
よく考えてディレクトリ名はつけるように。

[root@publicpc oci]# pwd
/opt/oci

7.3.2 仮想環境作成

まずはPythonのバージョンを確認する。

[opc@publicpc ~]$ python --version
Python 3.6.8

バージョンに応じた仮想環境作成のコマンドを打つ。

python -m venv <仮想環境名>
[root@publicpc oci]# python3.6 -m venv venv1

/opt/oci配下にvenv1という仮想環境が作成される。

7.3.3 仮想環境をアクティブ化

OCI CLIのコマンドを打つときは、仮想環境をアクティブ化したうえで実行させる。
アクティブ化させるコマンドは以下の通り。

[root@publicpc oci]# source /opt/oci/venv1/bin/activate
(venv1) [root@publicpc oci]#

ちなみに、非アクティブ化は以下でできる。

(venv1) [root@publicpc oci]# deactivate
[root@publicpc oci]#

7.4 OCI-CLIのオフラインインストール

会社の社内規則などによってLinuxサーバがインターネット接続できない場合、自分がWindows端末にインストールファイルをダウンロードし、
そのファイルをLinuxサーバに配置して読み込ませることでCLIの実行環境を準備することができる。

Github(https://github.com/oracle/oci-cli/releases)から、oci-cli.zipをローカルにダウンロード。
oci-cli.zipを作Linuxサーバに配置し解凍する。

8．Ansibleのインストール

9．BlockVolumeのパーティション切りとマウント

10．コンテナ

１００万円失いながらハッキングを乗り越え誰でも１分で切り抜きを作れるサービスを公開するまでの失敗と学び

2021-07-13T02:44:33+09:00

先日、誰でも最短1分でYouTubeの切り抜きを作れるウェブサービスを公開しました。

私はプログラミングの勉強を始めて1年半の初学者ですが、個人開発でサービスを公開するまでに、数多くの失敗と苦労をしてきました(そして今もしてます笑)。後ほど詳しく書きますが、以下のような経験をしました。

ハッキングを受けデータを盗まれる
α版をリリースするも作り直しを決意する
巻き返しのため海外フリーランサーを雇うも無駄金となる
公開前に本家が同じ機能を発表し諦めかける
β版をリリースするも使われない

同じようにプログラミングの勉強をし始めたばかりの方や、個人開発でいつかはサービスを公開したいと考えている方の「転ばぬ先の杖」として、私の経験が役に立てばと思っております。

開発したサービス

YouTubeの公式APIを利用してウェブ上で切り抜きを作成・紹介できるウェブサービス「YouClip」を開発しました。

ここから実際に触れます→https://youclip.app

私自身が所属するスポーツチームの動画をYouTubeにアップすることが多くあり、試合やプレーの振り返りをするのにあったら便利だなと思ったのが着想のきっかけです。考えてみると、これはスポーツのプレー分析以外にも色々と用途があるのではないかと思い、プログラミングの学習も兼ねて一般向けのサービスとして開発を始めました。

今までの失敗と学び

１．ハッキングを受けデータを盗まれる

開発を始めて間もないある日、いつものように本番サイトを開こうとするとエラーでページが表示されません。おかしいなと思いサーバ上のDBを確認すると、あったはずのテーブルが全て消えており、見慣れないWARNINGと言う名のテーブルが１つだけありました。そこにはデータが１つだけ入っており、「データを復元して欲しければビットコインを振込め」との脅迫文が書かれていました。

(テーブルに入っていた全文)

To recover your lost databases and avoid leaking it: visit xxxx and enter your unique token xxxx and pay the required amount of Bitcoin to get it back. 
Databases that we have: xxxx, xxxx. Your databases are downloaded and backed up on our servers. 
If we dont receive your payment in the next 9 Days, we will sell your database to the highest bidder or use them otherwise.

(日本語訳)
失ったデータを復元し漏洩したくなければ、xxxxのサイトを訪れ、記載のトークンを入力した上で指定された金額のビットコインを支払え。お前のデータベースはダウンロードし、我々のサーバにバックアップしてある。９日以内に支払いがなければ、誰か高く買ってくれる人に売るか、別の方法で利用するだろう。

そこではじめて何者かがDBをハッキングし、データを人質にビットコインを身代金として要求しているのだと分かりました。幸いまだ開発初期で、ユーザーは身内と知り合い数人しかいなく、個人情報もメールアドレスくらいだったので、彼らにはお詫びをしてデータは諦めることにしました。まさかサーバに上げてすぐにハッキングされるとは思ってもおらず、衝撃でした。

原因は、あまり深く考えずサーバにphpMyAdminを入れていたのですが、アカウント名やパスワードが単純だったためブルートフォースアタック(総当り攻撃)でハッキングされたのだと思います(アホすぎるorz)。セキュリティに無知だった自分が悪いのですが、これが正式なリリース後だったら・・とゾッとしました。リリースする際には十二分にセキュリティ対策をしようと、苦い教訓となりました。(当然現在はphpMyAdminも入れてません)

２．α版をリリースするも作り直しを決意する

当初作ろうと思っていた機能とデザインを一通り実装し終えたので、α版として身近な友人や親戚に使ってもらうことにしました。Adobe XDでUI案を作った段階で友人などからフィードバックはもらっていたし、自分でも使いやすく作ったつもりだったので、それほど大きな問題はないだろうと思ってました。しかし、いざ使ってもらうと肝心の切り抜き機能が使いづらいと感じる人が多いことが分かりました。そのため、切り抜き機能のフローやUIを抜本的に見直すことを決意し、その影響はサービス全体にも及んで結果として大改修をする羽目になりました。

Adobe XDでUI案を作った段階で友人からフィードバックをもらっていたのですが、それでも今回の問題に気付けなかったのは、２つ陥りがちな罠にはまっていたと思います。

画面デザインを見せて意見を聞くだけで、ユーザーが操作しているところを観察しなかった
元からサービスの内容を知っている友人に意見を聞くだけで、完全に初見の人からフィードバックをもらわなかった

やはり実際に操作するのを見て初めて気が付くことが多くあり、XDの画面デザインを見せるだけでなく、プロトタイプ機能を使って模擬的に操作してもらうべきでした。また、サービスの前提知識がある人やITリテラシーが高い人だと、多少分かりにくくても使いこなせてしまいます。実際にこれから使うターゲットユーザーに合わせ、初見でITリテラシーもそこまで高くない人からもフィードバックをもらうべきでした

３．巻き返しのため海外フリーランサーを雇うも無駄金となる

３−１．Crowdworks経由で中国人のエンジニアと働く

大改修により、当初の予定よりだいぶリリース時期が遅れることが見込まれたため、巻き返しにスポットで外部のエンジニアを雇えないか考えました。知り合いをはじめ、Twitterや、クラウドワークス、ランサーズなどのクラウドソーシングサイトを利用して、フリーランスエンジニアの方々に連絡してみましたが、いいなと思う人はやはり時給にすると5,000円以上といった感じでした。自腹を切る上に、どれぐらい開発に時間がかかるかも読み切れない中で、言い方は悪いですが少しでもコストパフォーマンスの良さそうな人を必死に探しました。

そんな中、クラウドワークスに登録していたエンジニアの1人が、技術スタックや経験、公開しているポートフォリオの観点からも良さそうで、かつ時給3,000円程度のオファーだったので、その人にお願いしてみることにしました。やりとりしている段階で気が付きましたが、登録してある情報は日本語でしたが実際には彼は中国人で、英語と中国語しか使えないようでした。私自身は留学経験もあり、英語でやりとりするのに抵抗はなかったのでそのまま彼と契約することにしました。

彼とは作業時間に応じて支払いをする形(プロジェクト形式)で、途中休暇を挟みながらも足掛け2ヶ月程度リモートで一緒に働いたのですが、完成前に契約を打ち切りました。今も使っている有用なライブラリを紹介してくれたり、技術力はある程度期待通りだったのですが、次第に胡散臭いところや、面倒な交渉が多く発生するようになったのが原因です。

例えば、タスク量はそれほど変わっていないはずなのに、後半になるにつれ作業時間がなぜか右肩上がりで増えていました。また、兄弟がコロナにかかって重症で大変なのでボーナスをくれないかと交渉されたり、契約の終わりの方には次のクライアントを見つけるのに海外のフリーランスサイトに登録したいが出来ないので、アカウントを貸してくれないかとお願いされたりしました。このようなことが積み重なって、次第に信用できなくなっていきました。

３−２．海外のクラウドソーシングサイトでインド人・ウクライナ人・スペイン人と働く

ただ、作業自体はある程度スピードアップしたのは確かだったので、もう少し試してみようと、今度は直接海外のクラウドソーシングサイトを利用してみることにしました。前回の反省を活かして、数時間で出来る小さいタスクに対するコンペ方式で支払いを抑えつつ、何人か試してみていい人がいたら継続しようと考えました。

海外のクラウドソーシングサイトで有名なFreelancer.comやUpworkを使って、インド人、ウクライナ人、スペイン人と働いてみることにしました。確かに金額的には日本よりだいぶ低く抑えられましたが、お願いした仕様と全く違うものを作ってきたり、その多くが自分でやり直さなければいけないことになりました。

結局トータル１００万円近く掛けましたが、果たしてその価値があったかと聞かれると「はい」とは素直に言えない感じになりました。日本のフリーランスの方と働いたことがないため一概には言えないものの、(中国・インド等の)海外エンジニアだからコスパ的に良いといったことはないというのが今回の感想です。

４．公開前に本家が同じ機能を発表し諦めかける

改修も終えそろそろリリースできそうだなと考えていたある日、YouTube本家が動画の一部を切り取ってSNSでシェアできるクリップと言う機能を実験的に米国で開始したと言うニュースが流れてきました。

本家が、名前もほぼそのまま、同等の機能を出してくるとは思ってもおらず、リリースしても本家に勝てるはずがないと諦めかけました。しかし少し冷静になって考えてみると、まだ実験的な位置付けで本当に追加されるかもわからないことに加え、そもそも本家は１つの場面しか切り抜けないが、YouClipは複数の場面を切り抜いて繋げられることなど、機能面でも違いがありました。

そこで、この機能面の違いに目を向ければ、特定のユースケースでYouClipにも需要がまだあるのではないかと考え直し、そのユースケースに集中しようと考え直しました。具体的には、複数の場面を切り抜いて繋げる必要があるような、長時間のライブ配信がメインのVTuber動画や、ゲーム実況配信にサービスの主眼を置くことにしました。

５．β版をリリースするも使われない

そうやって何とかβ版のリリースに漕ぎ着け、知り合いやTwitter経由でユーザーを集め始めたのですが、一度はサイトに訪問してくれるものの、そのまま何もせずに帰ってしまう人がほとんどでした。Google Analyticsで見てみると、ホーム画面や再生画面の直帰率が70%近くあり、全く以て穴の開いたバケツのような状態であることがわかりました。

そこからは直接ユーザーに意見を聞いたり、Analyticsで取れる各種KPIやMicrosoft Clarity(※)の画面レコーディングデータを見つつ、仮説を立てて離脱率が下がるよう改善を繰り返しました。

例えば、再生画面の画面レコーディングを見ると、ミュート解除ボタンに気づかず、そのままミュート状態で見続けているユーザーが多くいることに気づきました。ミュート状態だと面白さは半減するため、ミュート解除ボタンをより目立つ位置と見た目に変えることで、再生画面の離脱率を10pt%近く下げることができました。

まだまだ十分とは全く言えない状態ですが、このような小さな改善を繰り返すことで、バケツの穴を少しずつ塞いでいっています。

（※）Microsoftの無料ヒートマップツール「Clarity」について
Clarityは、ユーザーの行動を無料で把握できる分析ツールで、匿名化されたユーザーの画面操作記録を見ることが出来ます。

詳しくは以下のサイトなどを見てもらうと良いと思いますが、実際にユーザーがどんな風にサービスを使っているのかを知るのにとても役立ちます！
https://sogyotecho.jp/clarity/

最後に

このようにたくさん失敗をし、正直こんなことやって意味あるのか自問自答することもありましたが、長年やってみたいと思っていた個人開発でサービスを作れた事は楽しかったし良い経験となりました。

こんなこと出来ないかと空想することから始まり、そこからどうやったら実現出来るか1つずつ考え・調べて・学びながら実装していく作業はとても楽しかったです。そうやって苦労して作ったサービスが誰かに使われているのを見るのはとても嬉しく、新しく投稿があると思わず全部いいねしてしまいます笑

また、当然サービスをリリースしても知ってもらわなければ意味がないので、苦手なSNSの運用やマーケティングについても現在進行系で試行錯誤しながら学んでいます。(こちらも現在進行系で失敗?!しているので、いつか振り返りたい)

以上が個人開発でサービスを公開するまでの私の失敗と学びです。
何かしら個人開発をしている人、これからしたい人の参考になれば嬉しいです！

DynamoDBの多対多で隣接リストやった時の冗長性対策どうしよう

2021-06-12T18:01:20+09:00

DynamoDBウキウキで初めて早速引っかかる問題の一つが多対多とn+1問題だと思うんだが、これについてはAWSのドキュメントに一応解決方法が乗っている。それについて書いた記事がこれ→「DynamoDBで多対多のテーブル設計 – 或る阿呆の記」。

隣接リストというデザインパターンで、初めて見た時はギョッとしたけど、実際やってみるとたしかに効率的にクエリが書ける。テーブルの構造についても、ああつまりRDBの中間テーブルに要素をもたせるとこうなるのか、ということで、個人的には納得もした。

ただこの方式は、冗長である。したがって、同一であるべきアイテムの情報に不整合が発生する可能性がある。それについて、どう対応したもんなんだろうか。

トランザクション処理

真っ先に思い浮かぶのはトランザクション処理だ。進化を続けるDynamoDBは、一定の制約はあるもののトランザクション処理もサポートするようになった。試しに使ってみたのが「DynamoDBにboto3でトランザクションな書き込み – 或る阿呆の記」の記事。

ただ数的な制約とか、boto3.resource()だと使えなくて低レベルなboto3.client()を使う必要があったとか、Lambda関数のboto3が古くてzipあげる謎工程が必要だったとか（さすがにこれはもう解決しているだろうが）あって、結局実際には使わなかった。

トランザクション処理はDynamoDBにおいては最終手段の気もする。

バッチによる定期メンテ

次に思い浮かぶのは、不整合を確認するバッチによる定期メンテだ。一日に一回くらいテーブルをフルスキャンして、おかしなところがないか確認する。

というとなんか阿呆っぽいんだけれど、実際こういうバッチを走らせてなんとかしているシステム世の中たくさんあると思う。。。

リアルタイム性を犠牲にできるユースケースであれば、なんだかんだでこれが一番ラクな気がする。しかしそうやって謎のバッチスクリプトがあちこちで走り始めると、何がなんだかわからなくなってくるので、管理の問題は別途出てくるけど……。

ほっといてもそのうち直る仕組み

このケースはけっこうある。たとえば最新値などがそうで、最新値は常に変わり続けるから、たとえ1回ミスって不整合があっても、ほっといたら再更新かかるのでなおっている。それだったらわざわざコストかけて面倒見るより、あえて放っておく、で十分だったりする。

結局……

ということで、自分はといえば、結局

リアルタイム性が必要→更新が多いはず→対応しない。ほっといたらまぁだいたい合ってるでしょって感じ
リアルタイム性はそんなでもない→あんまり更新もない→バッチで確認したら十分

のあわせ技でなんとかしている感じ。とはいえ、実際不整合はほとんど発生していなくて、たまに見つかるとだいたいアプリケーションのロジックがそもそもポカしていたりするので、まぁこれくらいでいいのかなぁと思いつつ、みんなどうしているんだろうというのは気になっている。

【メモ】AWSでEC2を立ててDockerを起動してみる。

2021-06-07T23:51:13+09:00

AWSで、EC2（仮想サーバー）を立てて、その上でDocker（ドッカー）を起動してみる。

ブラウザからEC2のIPアドレスにアクセスして「Hello from Docker!!!」を表示させる手順。

VPCを作成する。
サブネットを作る。
インターネットゲートウェイをくっつける。（VPCにアタッチする）
サーバー（EC2）を立てる。
（インスタンス作成でVPCとサブネットを紐付け、自動割り当てパブリックIPを有効にする）
ファイアウォールを設定する。（セキュリティグループの設定（ポート:SSH=22とhttp=80））
ルーティングを設定する。（VPC→ルートテーブル→ルートの編集→サブネットの関連付け）
SSHでサーバーにアクセスする。（Tera Termを使った）

ssh://[email protected]（パブリックIPv4アドレスと予めDLしておいたキーペア）

Dockerをインストールする。

sudo yum -y update　（パッケージ更新）
sudo yum -y install docker　（Dockerインストール）
sudo service docker start　（Docker起動）
sudo docker info　（Docker状態）
mkdir hello-docker　（作業用フォルダ作成）
cd hello-docker　（作業用フォルダ移動）
vi hello-docker.html　（表示用HTML作成）
Hello from Docker !!
vi Dockerfile　（dockerのイメージを作成）
FROM nginx
COPY ./hello-docker.html /usr/share/nging/html/　（/usr/share/nging/html/直下が初期表示らしい）
sudo docker build -t hello-docker-ec2 .　（tオプションで名前を付けれる。最後の「.」を忘れない）
sudo docker run --rm -d -p 80:80 hello-docker-ec2　（イメージを元にdockerのコンテナを起動）
※--rm（コンテナ停止と同時にコンテナ削除）-d（バックグラウンド起動）-p（どのポート使うか）
sudo docker ps　（dockerが起動しているか確認）

EC2にアクセスして「Hello from Docker!!」を表示させる。
（http://52.15.152.1xx/hello-docker.html）

Lambda関数でDeadLetterQueue(DLQ)を試す

2021-05-13T23:16:42+09:00

AWSのLambda関数をイベントで起動した時、複数回エラーを起こしたら、DeadLetterQueue、すなわちDLQを飛ばしたい。DLQを試すもの。Cloudformation使う。DLQはSNSとSQSが指定できるが、今回はSNSを使う。

系

以下の系を試す。

CloudWatch -> Lambda -(error)-> SNS -> Email

やってみる

CloudWatchで1分ごとにLambda関数を起動するようなものを、Cloudformationｗと使って用意する。SNS Topicについては、コンソールから作成する。

SNS Topicを作る

コンソールからSNS Topicを作成する。名前は仮に DeadLetterQueueTopicとする。とりあえずEメールに飛ばすようにしておくと、確認しやすいと思う。

ディレクトリ構成

ディレクトリ構成は以下。__init__.pyは空。

.
├── __init__.py
├── hello_world_function
│   ├── __init__.py
│   ├── hello_world
│   │   ├── __init__.py
│   │   └── app.py
│   └── requirements.txt
├── samconfig.toml
└── template.yaml

という構成でやってみる。

template.yaml

TargetArn に SNS Topic のARNを入れる。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  sam-app

  Sample SAM Template for sam-app


Globals:
  Function:
    Timeout: 3

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world_function
      Handler: hello_world/app.lambda_handler
      Runtime: python3.8
      Policies:
        - AWSLambdaBasicExecutionRole
        - arn:aws:iam::aws:policy/AmazonSNSFullAccess
      Events:
        HelloWorld:
          Type: Schedule
          Properties:
            Schedule: rate(1 minute)
      DeadLetterQueue:
        Type: SNS
        TargetArn: arn:aws:sns:xxxxxxxxxxxxxxxxxx:DeadLetterQueueTopic

samconfig.toml

sam build –use-container の後に sam deploy –guided で作るとよい。以下のようになる。

version = 0.1
[default]
[default.deploy]
[default.deploy.parameters]
stack_name = "sam-app"
s3_bucket = "aws-sam-cli-managed-default-samclisourcebucket-1miie23rwqpqg"
s3_prefix = "sam-app"
region = "ap-northeast-1"
capabilities = "CAPABILITY_IAM"

requirement.txt

空でもいいけど。

requests
six
regex

hello_world/app.py

def lambda_handler(event, context):


    return True

DLQ

sam build --use-container

sam deploy

デプロイすると、1分間にLambda関数が起動する。で、このままだと正常に終了してDLQが飛ばないので、わざとエラーを起こす。そのためには、上記コードの raise Exception のエラーを外してデプロイする。しばらく待っていたら、DLQがSNSに飛ぶ。SNSのSubscriberにEmailを用意しておけば、すぐに確認できる。

後片付け

SNSのトピックは手動で作成したので、手動で消す。

忘れずにスタックを消す。消し忘れると延々とLambda関数が起動し続けることになってしまうので注意。
aws cloudformation delete-stack --stack-name sam-app

DLQ -> SNS -> Lambdaにした時のproperty

Slackとかに飛ばしたい時は、DLQのSNS経由でLambda関数に飛ばすことになる。Lambda関数のeventのpropertyをメモしておく。

{
  "Records": [
    {
      "EventSource": "aws:sns",
      "EventVersion": "1.0",
      "EventSubscriptionArn": "xxxxx",
      "Sns": {
        "Type": "Notification",
        "MessageId": "xxxx",
        "TopicArn": "xxxx"
        "Subject": None,
        "Message": "xxxxxxx",
        "Timestamp": "2021-05-13T03:02:52.129Z",
        "SignatureVersion": "1",
        "Signature": "xxxx",
        "SigningCertUrl": "xxxx",
        "UnsubscribeUrl": "xxxx",
        "MessageAttributes": {
          "RequestID": {
            "Type": "String",
            "Value": "xxxx",
          },
          "ErrorCode": {
            "Type": "String",
            "Value": "200"
          }
        }
      }
    }
  ]
}

気になるのは event.Sns.Message だが、これはシリアライズされたJSON。json.loads()でデシリアライズすると以下のようになる。

{
"version": "0",
"id": "xxxx",
"detail-type": "Scheduled Event",
"source": "aws.events",
"account": "xxxx",
"time": "2021-05-13T02:47:42Z",
"region": "xxxx",
"resources": [
"xxxx",
],
"detail": {}
}

resourcesとidから、エラーを起こした元のLambda関数を辿ることができる。

参考URL

ありがとうございました。

AWS導入支援

2021-03-22T15:13:28+09:00

AWSとは
AWS(Amazon Web Services)はAmazon.comが提供するクラウドサービスとして、企業や組織のより迅速な活動やITコスト削減、アプリケーション拡張を実現するために役立つ幅広いコンピューティング、ストレージ、データベース、分析ツール、アプリケーション、デプロイサービスです。提供されているサービスは165以上となり、コンピューティング、ストレージ、データベース、分析、ネットワーキングや管理ツール、IoT、AI、セキュリティなどの幅広いクラウドベースの製品を利用できます。
AWS導入のメリット
初期コストの削減
ハードウェアやソフトウェアの購入が不要なため、初期の調達コストを大幅に削減できます。
セキュリティと法規制対応
AWSのクラウドサービスは、ISO 27001、SOC、PCI DSSなど世界中の様々なセキュリティ標準の要件を満たしています。
スピードと高い伸縮性
ハードウェア機器などの調達が不要なため、迅速に利用開始できます。
リソースが必要になれば必要な分だけ、サーバのリソースを増強可能です。また、不要になったリソースの縮小もできます。
BCP(事業継続計画)対策
AWSクラウドの活用により、自然災害などに罹災した際のリスクを軽減できます。インターネットに接続できれば、AWSにある保管データやサービス提供を活用することで、事業継続が可能です。
AWSは165以上のサービスを提供しており、それで、AWS導入を検討するなら、導入や移行には幅広い知識と豊富な経験を持っている会社を探してください。

AWS Lambdaのロギングを考える

2021-01-26T03:25:25+09:00

ロギングをどうするかで困っていた。AWS Lambdaでは、プリント出力したものがCloudWatchに保存されてとても便利なのだが、考えもなしにとりあえずポンポン入れていたところ、確かに情報はあるので追えないことはないんだが、地道に時間にあたりをつけて検索するなど、非常に泥臭い作業が要求され、なにかとつらかった。

APIのコール回数など集計したいという要件も出てきて、重い腰をあげてロギングについて頑張って考えました、という話。

ユースケースを考える

AWS Lambdaで、何も考えずにとにかく必要そうなのをログ出力しているが、フォーマットも何も整っていないため、ほしい情報を探し当てるのも一苦労だ。

ログをjson形式に構造化させてやると、CloudWatch Insightsでクエリを投げて検索・集計することができる。ということで、ユースケースに対応できるように、ログ出力について考えたい。

ユースケースとして以下を考慮。

ERRORだけ抜き出す
ユーザー別に叩いたAPIについて集計する
詳細な検索ができるように、ハンドラに渡された情報は全部取っておく

前提条件として、node.jsを使っていたりPythonを使っていたりする。そのため、特定の言語のライブラリに依存した解決はあまり好ましくない。

結果

以上の条件を考えて色々調査し、必要なことを考えた結果、以下のような感じになった。

{
  "msg": string // フィルタリングできるような固有のメッセージ
  "funcName": string // 実行関数
  "dateTime": string // ログ出力した時刻 RFC3339 に則る(jsならDateオブジェクトをconsole出力すればよい)
  "level": INFO | WARN | ERROR,
  "event": object // Lambda関数のeventパラメータをそのまま
  "input": object // 必要なやつ
}

levelでログレベルを設定。inputとmsgでフィルタリング、集計を容易に。困ったらeventとfuncNameで頑張って追えるようにしておいた。また、独自フォーマットなので言語やライブラリに依存しない。

このフォーマットはほとんど「AWS Lambda Logging: An Intro How-To and Best Practices | Scalyr」を参考にしています。

以下のような使い方を想定（node.js）。

function logging(msg, funcName, event, level, inputValues) {
  const logMsg = {
    msg: msg,
    funcName: funcName,
    dateTime: new Date(),
    level: level,
    event: event,
    input: inputValues
  }
  if (level === "INFO") {
    console.info(JSON.stringify(logMsg))
  } else if (level === "WARN") {
    console.warn(JSON.stringify(logMsg))
  } else if (level === "ERROR") {
    console.error(JSON.stringify(logMsg))
  } else {
    console.log(JSON.stringify(logMsg))
  }
}

exports.handler = async (event, context, callback) => {
  logging("CallApi", "functions/users/app.handler", event, "INFO", {userId: "testUser"});
}

で、CloudWatch Insightsを使うとたとえば以下のようなクエリを投げて集計できるわけだ。

filter msg like /CallApi/
| stats count(input.userId) by input.userId

運用を通じてブラッシュアップしていきたい。

参考リンク

この記事は、開発中のWebサービスQnQで草稿を作りました。よかったら見ていってね（宣伝）。

Lambda関数のロギング設計を考える | QnQ

その他、参考にさせていただいた記事です。ありがとうございました。

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 のほうが良いなと現時点では感じてしまいました。

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

参考リンク

📝 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 関数の実行結果が正しいことも確認する

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

個人開発者をもっと知りたい。YouDevをリリースしました。

2020-05-14T10:35:03+09:00

YouDevをリリースしました。 2020.5.01

YouDevは個人開発者にスポットを当てて、個人開発者をもっと知ってもらう(僕自身が知りたい。。)サービスです。

サービスは認知されていても開発者にはスポットが当たってないなと思い、個人開発者は自分がリリースしたサービスをサービスだけでなく開発者自身をもっとアピールしてもいいんじゃないかな？と思い作成しました。

常に個人開発者を募集してるので、自分は個人開発者だ！って思う人は登録お願いします！

なお、改善点もできる、できないに関わらず受け付けております！

僕のスペック

・へっぽこエンジニア
・開発歴：３年
・個人開発歴:半年(2020.01に今年は個人開発をやる！と決めた。)
・開発言語：python(半年)
・デザインセンス：皆無 (フレームワーク使わずにデザインは、まじ無理。 )
・昨今の新技術のスピードにはついていけてない。
・pythonって熱いんじゃね！？ってただ思ってるにわか。
・個人開発始めた時にQitaに投稿してこう！と思ったが、なんか雰囲気が違った。(へっぽこエンジニアの出る幕なさそう。。)
・QitaってMarkDownでしか書けないの！？なにそれ無理！

YouDevの目指すもの

とにかく個人開発者ってのを知りたくなった。

個人開発者ってどんな人がいてどんな活動してるんだろう？って思った時に役立つようなサービス

個人開発者にとって有益な認知拡大の活動の場を目指す。

本番環境

こんな感じ。

DBはPostgresSQLをあまり利用したことがなかったのでMySQLを利用。
本当はAWSのRDSを利用したかったが、収益化してるサービスでも無いのでEC2の中に大人しくインストールしました。
でも、やっぱりRDS使ってみたい。。

S3もできれば利用を避けたかったが、ユーザが登録する画像データもあるので、S3を使うことにしました。
そもそもEC2のストレージ容量が8GBしか無いのでここもでも大人しくS3にしました。

ただ、サービス内で共通して利用する画像データやCSS,スクリプト系はEC2側にstaticフォルダを新規で作成してそこから配信してます。(最悪、壊れても良いファイルなので。)

ソースコードはprivateのgithubで管理してます。

DjangoでAmazon S3を使う

僕は本番環境稼働直後はmediaファイルをEC2のstaticと同じディレクトリで運用していたのでまずはそれらをS3へ移行しなくてはならない。。

S3バケットの作成

まじはS3のバケット作成をする。

ここは基本的につまずきポイントは無かったです。

1.バケットの作成
2.IAMユーザの追加(ここでアクセスキーはコピーしといたほうがいいかも。)
3.グループの作成(ポリシーはAmazonS3FullAccessを適用)
4.2で作成したユーザを3で作成したグループに追加
5.バケットのユーザに2で作成したユーザを追加

S3への移行

まずは以下で認証の確認

$ aws configure list

      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                             None    None
access_key                             None    None
secret_key                             None    None
    region                             None    None

設定がされてないと、S3に接続できないので、先ほど作成したユーザのアクセスキーとシークレットキーを設定する

$ aws configure

AWS Access Key ID [None]: <アクセスキー>
AWS Secret Access Key [None]:<シークレットキー>
Default region name [None]: <なにも入力してない>
Default output format [None]:<なにも入力してない>

これでS3に接続できるようになるのでいざ、アップロード！


$ cd /usr/share/nginx/html/media/ #ここは移行したいファイルがあるディレクトリ

$ aws s3 cp --recursive uploads s3://<バケット名>/<フォルダ名>

これでいけました！

ちなみに
・--recursive をつけるとディレクトリが対象になります。
・cp ではなくsyncを使用した場合はコピーではなく同期になります。

Django側の設定

Django側でmediaファイルのアップロード、参照先をS3に向くように変更して上げなければいけない。

DjangoでS3を利用するには以下のモジュールが必要なのでインストール

```python:インストール
$ pip install django-storages
$ pip install boto3


settingに以下を追加する

```python:settings.py

INSTALLED_APPS = [
    ...
    'storages', #追加
]

...

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
                'social_django.context_processors.backends',
                'social_django.context_processors.login_redirect',

                'django.template.context_processors.media', #追加
                #これを追加してあげることでtemplateから{{MEDIA_URL}}でS3を参照できるようになります。
            ],
        },
    },
]

...

# MEDIA_URL = '/media/'
AWS_ACCESS_KEY_ID = '<アクセスキー>'
AWS_SECRET_ACCESS_KEY = '<シークレットキー>'
AWS_STORAGE_BUCKET_NAME = '<バケット名>'

AWS_S3_CUSTOM_DOMAIN = '%s.s3.amazonaws.com' % AWS_STORAGE_BUCKET_NAME
AWS_LOCATION = 'media'
DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
MEDIA_URL = "https://%s/%s/" % (AWS_S3_CUSTOM_DOMAIN, AWS_LOCATION)

これだけでS3へのアップロードおよびS3の参照ができるようになります。

使用したライブラリ系

Djangoで作成したサービスにソーシャル系サービス(twitter,google,facebook等)でログインできるようにするライブラリです。

twitterアカウントでの認証設定

```python:インストール
$ pip install social-auth-app-django


```python:settings.py
INSTALLED_APPS = [
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'social_django', #ここを追加
]
...

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
                'social_django.context_processors.backends',#ここを追加
                'social_django.context_processors.login_redirect',#ここを追加
            ],
        },
    },
]

...

SOCIAL_AUTH_URL_NAMESPACE = 'social' 

#AUTHENTICATION_BACKENDSを追加
AUTHENTICATION_BACKENDS = [
    'social_core.backends.twitter.TwitterOAuth',
    'django.contrib.auth.backends.ModelBackend',
]

#以下は本番環境では環境変数に設定すること！
SOCIAL_AUTH_TWITTER_KEY = 'xxxxxxxx' # Consumer Key (API Key)
SOCIAL_AUTH_TWITTER_SECRET = 'xxxxxxxxx'# Consumer Secret (API Secret)
SOCIAL_AUTH_LOGIN_REDIRECT_URL = '' # ログイン時のリダイレクトURL
LOGOUT_REDIRECT_URL = '' #ログアウト時のリダイレクトURL

```python:project/urls.py
urlpatterns = [
...
path('', include('social_django.urls')), #追加#
#↑を追加することでアプリ側から以下URLにアクセスすることで各処理が可能になります。
#ログイン:/login/twitter
#ログアウト:/disconnect/twitter/
#complete:/complete/twitter/
...
]

/complete/twitter/はtwitterAPIのCallbackのURLになります。
例)
![スクリーンショット 2020-05-12 22.04.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/634341/9372ed3a-53ce-966f-9242-fad1e712c676.png)

あとはmigrateすることで利用ができるようになります

```python:migrate
$ python manage.py makemigrations social_django
$ python manage.py migrate

requests-oauthlib

これはTwitterAPI利用の際のOAuthを数コードで実装できるようになるライブラリです。

```python:インストール
$ pip install requests requests_oauthlib



```python:settings.py

TWITTER_ACCESS_TOKEN = 'XXXXXX' #追加
TWITTER_ACCESS_TOKEN_SECRET='XXXXX' #追加

ここでは例として、ユーザ情報を取得する方法を記載します。

上記をsettings.pyの任意の場所に記入します。

```python:views.py

CK = settings.SOCIAL_AUTH_TWITTER_KEY
CS = settings.SOCIAL_AUTH_TWITTER_SECRET
AT = settings.TWITTER_ACCESS_TOKEN
ATS = settings.TWITTER_ACCESS_TOKEN_SECRET

def getAccount(request,screen_name):
url = "https://api.twitter.com/1.1/users/show.json" #エンドポイントは公式のドキュメント参照
params = {
'screen_name':screen_name
}
req = twitter.get(url, params = params)

if req.status_code == 200:
    res = json.loads(req.text)

else:
    res=""
    print("Failed: %d" % req.status_code)

return res


###MaterializeCSS(デザイン)

[公式ドキュメント](https://materializecss.com/)

冒頭で述べたとおり、ライブラリ使わなきゃCSSなんてやってられないです。。。
scssもインストールできるので気に入らなければメインカラー等は一括で変更できます。

**※注意:セレクトボックスは不具合があり、セレクトの選択欄が下のセレクトボックスに重なる場合
正しく選択できない不具合がありました。**

絶望していましたが、以下のgithubに改修コードが上がっていたのでこれを利用すれば解消します！

[改修版git hub](https://github.com/Dogfalo/materialize/issues/6444)


###cropper.js

画像をトリミングしてくれるライブラリです。
もちろん、僕が自前でトリミングの処理を実装できるわけもないので利用しました。

何回、ドキュメント読んでも実装方法が謎でしたが、数十回目を通してようやく理解できたのが以下のサイトです。

[へっぽこでも数十回目を通せばわかるはず！](https://simpleisbetterthancomplex.com/tutorial/2017/03/02/how-to-crop-images-in-a-django-application.html)

だいたい以上が使用したライブラリです。

#つまずいた

###mysqlのバージョン
 Django3.0からはmysqlへ接続するドライバはmysqlclient推奨と公式ドキュメントに書いてあるもんだから、大人しくインストールしてみたがエラー。。

```python:
$ pip install mysqlclient

> ~
 check the manual that corresponds to your MySQL server version for the right syntax to use near 'rsion' at line 1
 ~

謎のエラー

原因：mysqlのバージョンが古いことに起因してるみたい

開発環境はAWSのCloud9を利用しているんですが、cloud9だと初期状態でmysqlがインストールされている。

が、バージョンが5.5でmysqlclientは5.7からしか使えないみたいだったので、5.5を削除して5.7をインストールしました。

 sudo yum remove mysql* #mysqlの削除
 #(慎重な方はsudo yum -y remove mysql-config mysql55-server mysql55-libs mysql55)

 sudo yum -y install mysql57-server mysql57
 sudo yum -y install mysql-devel

絵文字をmysqlへ登録

もともとcharsetをutf-8にしていたので絵文字が登録できなかった。

設定ファイルの変更

```/etc/my.cnf
[mysqld]
character-set-server=utf8mb4

[client]
default-character-set=utf8mb4


mysqlの再起動

```/etc/my.cnf
sudo service mysqld restart

すでにテーブルがutf-8で作成済みだったので変更

ALTER TABLE targettable CONVERT TO CHARACTER SET utf8mb4;

Djangoの場合、Django側にも設定が必要

python:settings.py DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'xxx', 'USER': 'xxx', 'PASSWORD': 'xxx', 'HOST': '', 'PORT': '', #OPTIONSを追加 'OPTIONS': { 'charset': 'utf8mb4', }, } }

これで絵文字の出力、登録ができるようになりました！

さいごに　！

今後も色々、頑張って機能追加して行きますので是非とも登録お願いします！Youdev

AWS Lambdaでcx_Oracleを使ってOracleDBへ接続する

2020-04-21T13:51:26+09:00

前書き

Pythonで書かれた Lambdaファンクションから、OracleDBへ接続する方法を記載します。

LambdaファンクションからMySQLへの接続はたくさん記事があるんだけど、OracleDBへの接続はあまり記事がなく、実現まで結構時間がかかったので、自分用の備忘録に。

結論

LambdaファンクションからOracleDBに接続する時には、cx_Oracleのモジュールだけではなく、Oracle Instant Clientのモジュールも、デプロイパッケージに入れてあげる必要がある。
すべてのモジュールを一つのデプロイパッケージに入れると、大きすぎてAWS Lambdaのインラインエディタで編集できなくなる。なので、cx_OracleとOracle Instant Clientのモジュールはレイヤに分けると良い。

手順

前提

2020年4月時点で、使用した環境は下記の通りです。
python3のインストールまで完了している状態で、後続の作業を開始します。

Amazon Linux 2（AWS EC2上で作業）
python3.7
cx_Oracle7.3
Oracle Instant Client 19.6

手順の流れ

必要なモジュールをインストールする
デプロイパッケージを作る
Lambdaファンクションを作成する
レイヤ用のデプロイパッケージを作成する
Lambdaファンクションにレイヤを適用する

1. 必要なモジュールをインストールする

Oracle Instant Client

まずは、Oracle Instant Client から。
最新版のOracle Instant Clientを公式サイトからダウンロードします。作業環境が Amazon Linux 2 なので、Linux用の64ビット版を使います。
* Oracle Instant Client
* Instant Client Downloads for Linux x86-64 (64-bit)

インストールしたのは、とりあえずbasicとsqlplusのふたつだけ。LambdaファンクションからのDB接続だけを考えるなら、sqlplusは不要かも。

$ sudo yum -y localinstall ./oracle-instantclient19.6-basic-19.6.0.0.0-1.x86_64.rpm
$ sudo yum -y localinstall ./oracle-instantclient19.6-sqlplus-19.6.0.0.0-1.x86_64.rpm

インストール完了後、SQL*PLUSでDBに接続できることを確認しておきます。
なお、Oracle Instant Clientを使用する分には、ORACLE_HOMEなどの設定は不要らしいです。

$ sqlplus /@:/
SQL*Plus: Release 19.0.0.0.0 - Production on xxx xxx xx xx:xx:xx xxxx
Version 19.6.0.0.0
Copyright (c) 1982, 2019, Oracle.  All rights reserved.
Last Successful login time: xxx xxx xx xxxx xx:xx:xx +09:00
Connected to:
Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit Production

SQL> select TNAME from tab;
TNAME
--------------------------------------------------------------------------------
SAMPLE_EMP

SQL> select * from SAMPLE_EMP;
EMPNO      EMPNAME                                              GENDER_F
---------- -------------------------------------------------- ----------
0000000001 EMP_A                                                       1
0000000002 EMP_B                                                       2
0000000003 EMP_C                                                       1

SQL> quit
Disconnected from Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit Production

サンプルで作っておいたテーブルの中身が見えており、Oracle Instant Clientのインストールは完了です。

cx_Oracle

PythonでOracleDBに接続するために、cx_Oracleもインストールしておきます。

$ sudo pip3 install cx_oracle

EC2からcx_Oracleを使ってOracleDBへ接続する

ここまで完了したら、pythonでOracleDBへ接続できるようになっているはずなので、簡単なサンプルでOracleDBに接続できるか確認します。例えば下記のような感じ。ファイル名はdbconnect_oracle.pyとします。

import json
import cx_Oracle

def lambda_handler(event, context):
    # TODO implement

    # cx_oracleバージョン確認
    verOraCli = cx_Oracle.clientversion()
    print( verOraCli )

    # oracle接続
    print( "DB connect" )
    connection = cx_Oracle.connect("", "", "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=) (PORT=))(CONNECT_DATA=(SID=)))")

    # select実行
    print( "select execute" )
    try:
        cursor = connection.cursor()

        sql = "select * from sample_emp"
        cursor.execute( sql )

        result = cursor.fetchall()
        print( result )

    finally:
        cursor.close()
        connection.close()

    return {
        'statusCode': 200,
        'body': json.dumps( 'cx_oracle clientversion = ' + str(verOraCli) )
    }

本来はハンドラの中でDB接続処理を行わない方が良いけど、まあとりあえずということでひとつ。早速実行してみます。

$ python3 -c "import dbconnect_oracle; dbconnect_oracle.lambda_handler(0,0)"
(19, 6, 0, 0, 0)
DB connect
select execute
[('0000000001', 'EMP_A', 1), ('0000000002', 'EMP_B', 2), ('0000000003', 'EMP_C', 1)]

Oracle Instant Client 19.6 を使用してOracleDBでselectを実行できていることが確認できました。

2. デプロイパッケージを作る

EC2上での動作は確認できたので、AWS Lambdaの関数として定義するためにデプロイパッケージを作成します。

デプロイパッケージ構成

Lambdaファンクションで外部ライブラリのimportを行う場合、外部ライブラリを含んだデプロイパッケージを作る必要があります。今回はさらに、cx_OracleがOracle Instant Clientを利用するので、Oracle Instant Clinentもデプロイパッケージに含める必要があります。

というわけで、目指すべき構成は下記の形。作業ディレクトリは/tmp/dbconnect_oracle_packとします。

/tmp/dbconnect_oracle_pack
 ├ dbconnect_oracle.py
 ├ cx_Oracle.cpython-37m-x86_64-linux-gnu.so
 ├ cx_Oracle-7.3.0.dist-info
 │  ├ INSTALLER
 │  ├ METADATA
 │  ├ RECORD
 │  ├ WHEEL
 │  └ top_level.txt
 └ lib
    ├ libaio.so -> ./libaio.so.1
    ├ libaio.so.1
    ├ libclntsh.so -> ./libclntsh.so.19.1
    ├ libclntsh.so.19.1
    ├ libclntshcore.so -> ./libclntshcore.so.19.1
    ├ libclntshcore.so.19.1
    ├ libipc1.so
    ├ libmql1.so
    ├ libnnz19.so
    ├ libocci.so -> ./libocci.so.19.1
    ├ libocci.so.19.1
    └ libociei.so

デプロイパッケージ作成

デプロイパッケージにcx_Oracleを含めるため、作業ディレクトリへcx_Oracleを持ってきます。作業ディレクトリへのインストールなので、今回はsudoは不要です。

$ pip3 install cx_Oracle -t /tmp/dbconnect_oracle_pack

Oracle Instant Clientのモジュールは、インストール先からコピーします。libaio.so.1だけは、/usr/lib64/から持ってきます。

なお、記事を書く際に再度確認したら、libaio.so.1はシンボリックリンクで、実体はlibaio.so.1.0.1でした。
下記の通りでも動作はしますが、気になる方は、libaio.so.1.0.1をコピーしてそこからシンボリックリンクを作成する方が良いかもしれません。

$ mkdir /tmp/dbconnect_oracle_pack
$ cp /usr/lib/oracle/19.6/client64/lib/libclntsh.so.19.1 /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libclntshcore.so.19.1 /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libipc1.so /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libmql1.so /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libnnz19.so /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libocci.so.19.1 /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libociei.so /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib64/libaio.so.1 /tmp/dbconnect_oracle_pack/lib

最初に挙げたデプロイパッケージ構成に不足している部分を、シンボリックリンクで作成します。
デプロイパッケージのサイズ上限は250MBのため、絞れるところは絞りましょう。

$ cd /tmp/dbconnect_oracle_pack
$ ln -s ./libaio.so.1 libaio.so
$ ln -s ./libclntsh.so.19.1 libclntsh.so
$ ln -s ./libclntshcore.so.19.1 libclntshcore.so
$ ln -s ./libocci.so.19.1 libocci.so

ここまで完了すると、デプロイパッケージ構成通りの状態となっているはずです。zip圧縮して、デプロイパッケージを作成します。圧縮後のファイルは70MB弱くらいになると思います。
シンボリックリンクを含んでいるので、--symlinksオプションを忘れないように。また、圧縮対象は/tmp/dbconnect_oracle_packディレクトリではなく、その配下であることに注意してください。

$ cd /tmp/dbconnect_oracle_pack
$ zip -r --symlinks dbconnect_oracle_sample.zip ./dbconnect_oracle.py ./cx_Oracle.cpython-37m-x86_64-linux-gnu.so ./cx_Oracle-7.3.0.dist-info ./lib

3. Lambdaファンクションを作成する

完成したデプロイパッケージ元にLambdaファンクションを作成します。

ですが、作成したデプロイパッケージが50MBを超えているため、Lambdaファンクションとして直接アップロードを行う事ができません。一旦S3上にアップロードした後、LambdaファンクションにS3からアップロードする形になります。なお、Lambdaファンクションのサイズ上限は諸々含めて250MB。cx_OracleとOracle Instant Client だけで200MBを超えていて、結構カツカツです。

Lambdaファンクションとしてのアップロードが完了すると、インラインエディタで確認ができる…のが通常なのですが、サイズが大きすぎてインラインエディタでは編集できない旨の警告が表示されます。実行はできるようなので、良しとしておきます。

OracleDBに限らず、DBに接続するLambdaファンクションにはIPアドレスの付与が必要です。VPC設定を行い、VPC設定、サブネット、セキュリティグループを指定します。

また、初回実行に限り、そこそこの時間がかかります。デフォルトのタイムアウト値は3秒となっていますが、10秒程度に増やしておいたほうがよいでしょう。

上記の設定を完了したら、テスト実行を行います。サンプルは引数不要のイベントハンドラなので、空のテストイベントを作成してテストを行いましょう。

ヨシ！　ちゃんと、Oracle Instant Client 19.6が使われているようです。
初回は時間がかかりましたが、2回目からは1秒かからずに実行されます。時間がかかるのは、IP付与によるものかしら。

4. レイヤ用のデプロイパッケージを作成する

当初の目的である、cx_Oracleを使ってOracleDBへ接続するLambdaファンクションの作成は、ここまでで実現できました。

ただ、インラインエディタでの編集ができないのはちょっといただけません。サイズが大きい原因はcx_OracleとOracle Instant Clientなので、この部分をcx_Oracleレイヤとして切り出せば良いのではないか？

cx_Oracleレイヤ用のデプロイパッケージ構成

AWS Lambda レイヤー

関数コードからランタイム依存関係を移動するには、それらをレイヤーに配置します。Lambda ランタイムには、関数コードを使用して、レイヤーに含まれるライブラリにアクセスできることを確認する、/optディレクトリのパスが含まれます。

ライブラリをレイヤーに含めるには、ランタイムでサポートされているいずれかのフォルダにそれらを配置します。
* Python – python、python/lib/python3.8/site-packages（サイトディレクトリ）

レイヤ用のデプロイパッケージを作る場合、pyhon関連のライブラリはpython配下に、配置します。なので、cx_Oracle関連のモジュールはこちらに置きます。

AWS Lambda 環境変数の使用

予約されていない環境変数
(略)
LD_LIBRARY_PATH – システムライブラリのパス
(/lib64:/usr/lib64:$LAMBDA_RUNTIME_DIR:$LAMBDA_RUNTIME_DIR/lib:$LAMBDA_TASK_ROOT:$LAMBDA_TASK_ROOT/lib:/opt/lib)。

Oracle Instant Clientのモジュールについては、LD_LIBRARY_PATHで指定されたパスに配置する必要があります。Lambdaファンクションの設定で編集しても良いのですが、デフォルトで指定されたパス/opt/libがあるので、そちらを使いましょう。レイヤに含まれるライブラリは/opt配下に配置されるとのことなので、lib配下です。

というわけで、レイヤ用デプロイパッケージの構成は下記の通りになります。作業ディレクトリは/tmp/dbconnect_oracle_pack/layerとします。

/tmp/dbconnect_oracle_pack/layer
 ├ python
 │ ├ cx_Oracle.cpython-37m-x86_64-linux-gnu.so
 │ └ cx_Oracle-7.3.0.dist-info
 │     ├ INSTALLER
 │     ├ METADATA
 │     ├ RECORD
 │     ├ WHEEL
 │     └ top_level.txt
 └ lib
    ├ libaio.so -> ./libaio.so.1
    ├ libaio.so.1
    ├ libclntsh.so -> ./libclntsh.so.19.1
    ├ libclntsh.so.19.1
    ├ libclntshcore.so -> ./libclntshcore.so.19.1
    ├ libclntshcore.so.19.1
    ├ libipc1.so
    ├ libmql1.so
    ├ libnnz19.so
    ├ libocci.so -> ./libocci.so.19.1
    ├ libocci.so.19.1
    └ libociei.so

レイヤ用デプロイパッケージ作成

配置ができたらzip圧縮し、レイヤ用デプロイパッケージを作成します。ファイル名は何でも良いですが、oraclelib.zipとしてみました。

$ cd /tmp/dbconnect_oracle_pack/layer
$ zip -r --symlinks oraclelib.zip ./python ./lib

5. Lambdaファンクションにレイヤを適用する

レイヤを作るため、AWS Lambdaの左側メニューから「レイヤー」を選択し、レイヤの作成を行います。

先程と同様に、S3経由でアップロードする形になります。また、「互換性のあるランタイム」には、作業環境であるAmazon Linux 2にインストールしたのと同じ Python3.7 を指定します。

レイヤの作成が完了したら、Lambdaファンクションにレイヤを適用します。

作成したLambdaファンクションの画面から「レイヤーの追加」を行う事ができます。
Lambdaファンクションのランタイムを「Python3.7」にした上で、「レイヤーの追加」を行ってください。

選択できるレイヤーは、Lambdaファンクションで設定しているランタイムを「互換性のあるランタイム」で指定したレイヤーだけです。

こうしておくと、Lambdaファンクションそのものは、今回のサンプルのdbconnect_oracle.pyだけにしても大丈夫です。インラインコード編集も可能となります。

動作も問題ありません。

後書き

一番わからなかったのは、Oracle Instant Client 19 だとどのlibをデプロイパッケージに含めればよいのか、ということです。今回記事に残そうとしたのも、それが要因です。

それにしても、Oracle Instant Client だけで200MBオーバーなんだけど、そのうちOracle Instant ClientだけでLambdaのサイズ制限を超えてしまうのではないだろうか。

参考サイト

Lambda から RDS にアクセスする方法 (python)
AWS Lambda (Node.js-v4.3.2)からOracleに接続する(ORA-21561への対応)
Lambda, Python, and Oracle

その他、検索に引っかかったフォーラムの記事とか色々参考にしました。

AWSのELB(ALB)におけるSocket.IOのwebsocket接続と負荷分散 - Stickiness(Sticky session)の活用

2019-06-07T01:07:02+09:00

AWSではELB(Elastic Load Balancing)を活用し、アクセスの振り分けや負荷分散を行なうのがメジャーです。
ロードバランサーを使った構成は、通常のWebシステムではごくごく一般的です。

ただしSocket.IOを使ったウェブソケット(websocket)接続では、問題となる場合があります。
これには理由がありまして、私も調査に苦労しました。

まずは前提となる知識を共有しつつ、備忘録を兼ねて解説します。

Socket.ioの仕組みをざっくりと理解する

websocketのライブラリでSocket.ioが多用されているのは、いくつか理由があります。

その大きな理由のひとつに「HTTPの仕組みを使っているため、企業のファイアウォールやセキュリティーソフトのブロックに対して耐性がある」という点が挙げられます。

[https://socket.io/:embed:cite]

ロングポーリング(polling)

Socket.ioでは、まずロングポーリングを使ってサーバーと接続します。
ロングポーリングは、初期のLINEアプリでも採用されていた実績のある方式です。

ひとことで言ってしまえば、「通常のHTTPリクエストに対するレスポンスを引き伸ばすことで、長時間の接続を維持する」のがロングポーリングです。
サーバーはHTTPリクエストのレスポンスをすぐに終わらせず留保するため、クライアントとのコネクションを維持します。

Socket.ioとは何か?リアルタイムWebアプリケーションを実現する技術をまとめてみた #JavaScript - Qiita

ロングポーリングは、一般的なHTTPリクエストの延長線上にある技術です。
そのためセキュリティー制約の強い企業のファイアウォールや、セキュリティーソフトのブロックに対して強みがあります。

ロングポーリングからウェブソケット(websocket)へ

次にSocket.ioが実施するのは、プロトコルの昇格です。

ロングポーリングは素晴らしい仕組みですが、基本的にHTTPの接続を維持できる時間には限界があります。
もちろん接続が切れてしまったら再接続すれば良いのですが、これでは一定間隔で切れ目が生じてしまいます。

そこで登場するのがwebsocketです。
Socket.ioは「ロングポーリングからwebsocketへプロトコルを昇格(Upgrade)」しようと試みます。

Once all the buffers of the existing transport (XHR polling) are flushed, an upgrade gets tested on the side by sending a probe.

引用：https://socket.io/docs/internals/#Upgrade

Connection: Upgrade

HTTP/1.1にはConnectionというヘッダーがあり、コネクションのプロトコルをアップグレードすることができます。

Upgrade: websocket
Connection: Upgrade
引用：http://jxck.hatenablog.com/entry/20120725/1343174392

もしコネクションのアップグレードに成功したならば、Socket.ioはウェブソケットでの通信を開始します。
一方でwebsocket接続に失敗したとしても、ロングポーリングでの接続を継続することができます。

このプロトコル選択の柔軟性が、Socket.ioのすごいところです。
websocketが使える環境下ではwebsocketを利用し、そうでない環境下でもロングポーリングで接続を維持できます。

ロードバランスされるとセッション(sid)が引き継げない問題

socket.ioがウェブソケット接続を開始する場合、以下のようなリクエストを送信します。
ここで注意してほしいのが「sid」という名のパラメーターです。

GET wss://myhost.com/socket.io/?EIO=3&transport=websocket&sid=36Yib8-rSutGQYLfAAAD  
with:  
  "EIO=3"                     # again, the current version of the Engine.IO protocol  
  "transport=websocket"       # the new transport being probed  
  "sid=36Yib8-rSutGQYLfAAAD"  # the unique session id

https://socket.io/docs/internals/#Upgrade

「sid」とはセッションIDのことですが、ここに大きな問題があります。
最初にアクセスしたサーバーと違うサーバーに振り分けられてしまった場合、発行されたセッションが見つからなくなってしまうのです。

その際は「Session ID unknown」のようなエラーが発生します。

つまり最初にリクエストを送信してからウェブソケットの接続を確立するまで、常に同じサーバーにロードバランスされないと困ってしまうのです。

Redisによるセッションの共有

Socket.ioのセッション情報を引き継げない問題でよく選択されてきた対応策は、インメモリデータベースのRedisによるセッション情報の共有です。
AWSで言うならば、Redis用のElastiCacheを使ってセッション情報を保存します。

複数立っているsocket.ioサーバのセッション情報をRedisを介して共有することができるようなので、そうすれば複数のリクエストが異なるサーバに繋がっても問題なくなります。
引用：https://qiita.com/shunjikonishi/items/526e6181efecf83a5f5b

「socket.io-redis」というRedis向けのライブラリがあり、これを使います。
2年ほど前の話ではありますが、実際に試してみたところ確かに問題ありませんでした。

socketio/socket.io-redis
https://github.com/socketio/socket.io-redis

ElastiCacheでなく自前でRedisを用意しても構わないですが、兎にも角にもRedisが必要です。

Application Load Balancer

さてAWSには、Application Load BalancerというL7のロードバランサーがあります。
単なるELBとの違いがややこしいですが、OSI参照モデルで言えば最上位の第7層(アプリケーション層)でリクエストを振り分けることが可能です。

Stickiness(Sticky session)

ここで登場するのが、Stickiness(Sticky session)というALBの仕組みです。
スティッキーセッションを使うと、ロードバランサーのアクセスの振り分けを固定することができます。

具体的な手順として、ELB(ALB)経由でサーバーにアクセスすると、HTTPレスポンスに「AWSELB」という名前のCookieが追加されます。
このクッキーはALBが自動に付与する設定もできますし、手動でサーバーから追加する選択肢も可能です。

ELBのスティッキーセッションはELBがサーバにリクエスト振り分ける際、特定のCookieを確認することで、特定のクライアントからのリクエストを特定のサーバに紐付けることが出来る機能です。
ELBのスティッキーセッションの設定は以下3つのパターンが選択出来ますので、それぞれどのような動作となるか確認してみます。

維持無し

ELBによって生成されたCookieの維持

アプリケーションによって生成されたCookieの維持

引用： http://blog.serverworks.co.jp/tech/2017/01/05/elb-sticky/

HTTPレベルの仕組みであるCookieを読み取ってアクセスを振り分けるため、高機能なアプリケーション層レベルのL7ロードバランサーであると言えます。

なお私は、実際のスティッキーセッションを使ったsocket.ioのアクセスの振り分けは、uorat様のブログ記事を参考に行ないました。
(注釈：ものすごく参考になりました。ありがとうございます)

WebSocket対応した噂のALB (Application Load Balancer) を試してみた - tail my trail

ELB(ALB)のwebsocket対応

従来のELBには、websocket接続できない欠点がありました。
そのためsocket.ioでwebsocket接続してるのかと思いきや、実際はロングポーリングでしたという事態が発生します。

これを解消したのが、2016年8月の新機能です。なんとwebsocket対応が追加されました。
これによりELBの負荷分散の恩恵を受けつつ、よりリアルタイム性の高い接続を維持することができるようになりました。

WebSocketサポート：WebSocketのリクエストを受けられるようになりました。
引用：【新機能】新しいロードバランサー Application Load Balancer（ALB）が発表されました | DevelopersIO

さいごに

Stickiness(Sticky session)の活用とELB(ALB)のwebsocket対応により、Socket.ioでも通常のWebシステムと同じようにロードバランスすることができます。

Cookieを使ってクライアント毎にロードバランサーの振り分け先を固定すれば良いなんて、当初は思いもしませんでした。
とても便利な機能なので、今後も活用していきたいです！

湊川あいさんのマンガでわかるDocker3 〜AWS編〜を読みました & 寄稿しました

2019-03-10T12:46:46+09:00

湊川あいさんの「マンガでわかるDocker3 〜AWS編〜」を読みましたので、簡単な概要と感想を書くことにしました。

#マンガでわかるDocker ③ 〜AWS編〜【ダウンロード版】#jawsdays #技術書典 - 湊川あいの、わかば家。 #技術書典 #わかばちゃんと学ぶシリーズ - BOOTH

執筆が忙しいのでさらっとしか読めてないのですが、マンガやイメージ図で概要を理解した後に、実際に構築をチャレンジしてみる本格派です。

余談ですが、この本はRe:VIEWで書かれていると一瞬で判別できるくらいには、技術同人誌に習熟した気がします。
「マンガでわかるDocker3」は、おそらく「TechBoosterのReVIEW-Template」で書かれている！

本の概要

次に書いてあるような内容を、ひととおり学べます。
どんどん「わかばちゃん」が賢くなってきている！

AWS CLIのインストール

まず初めに行なうのは、AWS CLIのインストールです。画面からだけではなく、ターミナルからも操作できるとやっぱり便利です。

請求アラートの設定

AWSは従量課金制なので、ガラケー時代で言うパケ死のような状況が起こり得ます。
なので、真っ先に請求アラートを設定しましょう。本書でもそうしてます。

オンプレミスのサーバーではあまり発生しないので、この辺りはクラウドならではかもしれません。

IAMによるアクセス制御

何でもできるユーザーでAWSにアクセスしてしまうと、誤操作によるトラブルが起こり得ます。
そこで、できることを制限したAWSユーザーを作成することが望ましいです。

AWSのIAMは設定できる項目が多すぎて、個人的に挫折ポイントだと思います。
なので、こうやってIAMを学べる機会は貴重です！

ECRへのイメージデプロイからECSへ！

ローカル上で作成したDockerイメージを、AWS上へとアップロードします。
なお、イメージをアップロードする先は「ECR(EC2 Container Registry)」です。

アップロードしたDockerイメージが実際に稼働するのは「ECS(EC2 Container Service)」で、ECSを管理することでサービスを稼働させます。

いろいろな現場でのDocker活⽤事例

私がYYPHPでもお世話になっている、株式会社クラフトマンソフトウェアの@reoringさんの事例などが載ってました。
イメージをアップロードするだけのDockerは、やっぱりお手軽なので私ももっと活用したいです。

私（このすみ）の活用事例も載ってます

本のサンプルコードの動作確認でDockerを使っているので、そのことについて寄稿しました。

ちなみに私は、技術同人誌の執筆はすべてDockerに統一しています。
Windowsで書いているときも、Macで書いている時も、Dockerを使って同じ手順でPDFを生成できるので便利です。

他の方の採用事例よりもライトな内容ですので、ぜひ気楽な気持ちでお読みいただけますと幸いです。
Dockerは実際のサービスでも役に立ちますが、手元の環境を汚さなくて済むので、日常的に活用していくと真価を発揮するような気がしています。

さいごに：賢くなるわかばちゃん

ECS用のタスク定義でJSONファイルを扱い始めたりと、わかばちゃんが多方面に賢くなり始めています（笑）。

私はどちらかと言うとアプリケーション側が得意なエンジニアなので、こうやってインフラをわかりやすく学べる機会は貴重だと思ってます。
お値段もお手頃ですので、オススメではないでしょうか。今よりインフラ力を上げたないなぁ。

#マンガでわかるDocker ③ 〜AWS編〜【ダウンロード版】#jawsdays #技術書典 - 湊川あいの、わかば家。 #技術書典 #わかばちゃんと学ぶシリーズ - BOOTH

おまけ：湊川さん関連の過去記事

「しがないラジオ」に湊川さんが出演された回の感想と「初心者系VTuberわかばちゃん」の配信を観たときの話を過去に書きました！

スキルを組み合わせてオンリーワンへ湊川あいさん(しがないラジオsp.7a) - このすみノート

[https://www.konosumi.net/entry/2018/08/27/020415:embed:cite]

Puppeteer on AWS Lambda のスクリーンショットで文字が豆腐になるので、ウェブフォントと絵文字フォントをインストール

2018-12-28T19:11:14+09:00

状況

現在開発中の https://poiit.me で puppeteer のスクリーンショットを使って動的OGPをつくっています。
CSSで動的な画像をデザインできるし、一つ lambda 関数を作っておけば、いろんなところで応用ができるのでいいですね。

が、今回は絵文字が、豆腐になってしまったのでその対処法。

参考記事

ベースはこちらの記事を参考にしました。
https://qiita.com/zyyx-matsushita/items/c33f79e33f242395019e

基本は参考Qiita をベースに対応できましたが、絵文字フォントがどこにあるのか結構探したので、備忘録的にメモ。

絵文字フォントダウンロードと設置

Google の Noto Color Emoji はこちらからダウンロードできました。
https://www.google.com/get/noto/#noto-emoji-zsye-color

他のダウンロード可能な絵文字フォントを知っていたら、是非ダウンロード場所教えてください！

で、ダウンロードしたファイルを解答し /.font/NotoColorEmoji.ttf に設置

WEBフォント

こちらは絵文字以外のフォントについては、WEBフォントをつかっています。

screenshot を撮る前に head に追加してやれば反映されるはず。

        await page.evaluate(() => {
            var style = document.createElement('style')
            style.textContent = `
                @import url('//fonts.googleapis.com/css?family=M+PLUS+Rounded+1c|Roboto:300,400,500,700|Material+Icons');
                div, input, a, p{ font-family: "M PLUS Rounded 1c", sans-serif; };`
            document.head.appendChild(style);
            document.body.style.fontFamily = "'M PLUS Rounded 1c', sans-serif";     
        })

その後、長めに wait させたないとフォントが反映されていないことがあるので注意

        await page.waitFor(3000);

こちらの記事を参考にしています。
https://qiita.com/chimame/items/04c9b45d8467cf32892f

関数実行

lambada で呼び出す関数で、フォントをサーバーにインストールする fc-cache コマンド実行してから、
puppeteer の screenshot などを実行すれば、ちゃんと絵文字が反映されているはずです。

アップロードすれば終了です。

めでたし！

serverless を使ったベーシックな puppeteer on lambda は github に置いてあるので必要あれば。
https://github.com/yahsan2/puppeteer-example-on-serverless-lambda

この記事のフォント反映バージョンも要望あればで公開しますので、コメントください〜！

poiit というサービスつくっています！

この記事がもし参考になれば、50円からサポートお願いします〜！

https://poiit.me/yahsan2/

Lambda@Edgeで画像をリアルタイムにリサイズできる仕組みを作った

2018-12-26T14:22:38+09:00

今作成中のサービスで画像をリアルタイム変換できる仕組みを AWS の Lambda@Edge を用いて実現してみたので紹介します。

参考：https://aws.amazon.com/jp/blogs/news/resizing-images-with-amazon-cloudfront-lambdaedge-aws-cdn-blog/

Lambda@Edge とは

Lambda@Edge とは、一言で言うと CloudFront (CDN) の HTTP リクエスト・レスポンスを操作できる Lambda 関数です。

下記のタイミングで CloudFront リクエスト・レスポンスを変更することができます。
* CloudFront がビューワーからリクエストを受信した後 (ビューワーリクエスト)
* CloudFront がリクエストをオリジンサーバーに転送する前 (オリジンリクエスト)
* CloudFront がオリジンからレスポンスを受信した後 (オリジンレスポンス)
* CloudFront がビューワーにレスポンスを転送する前 (ビューワーレスポンス)

作った仕組み

CloudFront のオリジンサーバーに S3 を指定し、S3 からの画像レスポンスを Lambda@Edge で変換する仕組みを構築しました。

URLのパラメータを変えることでリサイズされた画像を取得できます。
例えば下記のように幅と高さを指定してリクエストするとそれぞれのサイズの画像が返却されるようにしています。

・https://cdn.example.com/images/user/1234/avatar/001.jpg?d=100x100　→ 100x100の画像
・https://cdn.example.com/images/user/1234/avatar/001.jpg?d=300x300　→ 300x300の画像
・https://cdn.example.com/images/user/1234/avatar/001.jpg?d=1000x1000　→ 許可しないサイズはエラー

コード

いろいろ説明をはしょってコードだけ貼っときます。。

ビューワーリクエスト

'use strict';

const querystring = require('querystring');

const allowedDimensions = [ {w: 100, h: 100}, {w: 300, h: 300} ];

exports.handler = (event, context, callback) => {
  const request = event.Records[0].cf.request;
  const headers = request.headers;

  // URIが特定の画像パスに一致するかチェック（特定の画像以外はクエリストリングを削除してリクエスト）
  const match = request.uri.match(/\/images\/user\/\d+\/avatar\/\d+\.jpg/);
  if (match == null) {
    request.querystring = '';
    callback(null, request);
    return;
  }

  // クエリストリングを key-value のペアにパース
  const params = querystring.parse(request.querystring);

  // dimensionパラメータがない場合、クエリストリングを削除してリクエスト
  if (!params.d) {
    request.querystring = '';
    callback(null, request);
    return;
  }

  // dimensionパラメータを'x'で分割
  const dimensionMatch = params.d.split('x');
  const width = dimensionMatch[0];
  const height = dimensionMatch[1];

  // dimensionパラメータが、許可リストに一致するかチェック
  let matchFound = false;
  for (let dimension of allowedDimensions) {
    if (width == dimension.w && height == dimension.h) {
      matchFound = true;
      break;
    }
  }
  // 許可リストにない場合、クエリストリングを削除してリクエスト
  if (!matchFound) {
    request.querystring = '';
    callback(null, request);
    return;
  }

  // クエリストリングにd={width}x{height}を設定してリクエスト
  request.querystring = querystring.stringify({ d: width + 'x' + height });
  callback(null, request);
};

オリジンレスポンス

'use strict';

const querystring = require('querystring');
const AWS = require('aws-sdk');
const S3 = new AWS.S3();
const Sharp = require('sharp');

const BUCKET = 'XXXXXXXX';

exports.handler = (event, context, callback) => {
  let response = event.Records[0].cf.response;

  if (response.status == 200) {
    const request = event.Records[0].cf.request;

    // クエリストリングを key-value のペアにパース
    const params = querystring.parse(request.querystring);

    // dimensionパラメータがない場合、そのままレスポンスを返す
    if (!params.d) {
      callback(null, response);
      return;
    }

    // S3キー用にuriの最初のスラッシュを除いた文字列を取得
    const key = request.uri.substring(1);

    // dimensionパラメータを'x'で分割
    const dimensionMatch = params.d.split("x");
    const width = parseInt(dimensionMatch[0], 10);
    const height = parseInt(dimensionMatch[1], 10);

    // S3から画像を読み込み
    S3.getObject({ Bucket: BUCKET, Key: key }).promise()
      // リサイズ
      .then(data => Sharp(data.Body)
        .resize(width, height)
        .toBuffer()
      )
      .then(buffer => {
        // レスポンスを生成
        response.status = 200;
        response.body = buffer.toString('base64');
        response.bodyEncoding = 'base64';
        response.headers['content-type'] = [{ key: 'Content-Type', value: 'image/jpeg' }];
        callback(null, response);
      })
      .catch( err => {
        callback(null, response);
      });
  } else {
    // 200以外のステータスコードの場合、そのままレスポンスを返す
    callback(null, response);
  }
};

なぜ作ったか

普通なら「非同期ジョブでリサイズ処理してS3に複数サイズ保存」とかで事足りるのではと思います。

今回は、
* アップロード時間を短くしたい（アップロード時はバリデートのみで変換処理しない）
* 画像をアップロードした直後の画面でリサイズされた画像を表示したい
* リサイズ画像をキャッシュしたい
* 画像サイズあとで変えたいかも

といった理由で、CDNを通してリアルタイム変換という選択肢を選びました。

感想

AWS Lambda 自体初めて触りましたが、サーバレスは便利だな〜と感じました。
ただ、Lambdaの開発やテストやデプロイをどうやるのが正解なのかよくわからず、追加開発があるような比較的規模の大きいプロジェクトだとLambdaは大変そう(？)と思いました。

今回は画像リサイズだけでしたが、透かしを入れたり合成したり、画像以外にも動的にキャッシュできるので、いろいろ使い所ありそうです。

早くサービスリリースできるよう頑張ります。。