革命のブログ

フレボワークスの社員がブログを通じて情報発信します。

AWS Fargateを使って、マイクロサービス環境を実現する

どうも、小野です。 今回はAWS Fargateを使って、下図のような構成で作っていきます。

AWS Fargate

AWS Fargateは元々あるECSからEC2の管理を除外したサービスになります。 つまり、ECSをよりマネージドにしたものです。

Fargateについて知りたい方は公式サイトを確認してください。 aws.amazon.com

説明するにあたりAWSコンソールでもよいのですが、UIが頻繁に変わったりするので、今回はCLIベースで説明していきます。

※動作確認を行うターミナルは、コマンド実行時に変数を利用している関係上、最後まで閉じないようにしてください。

動作環境

  • Mac maxOS Mojave

前提

  • AWS CLIがインストール済み、かつバージョンが最新であること。
  • aws configreが設定済みであること。
  • Dockerコマンドが利用できること。
  • jqコマンドが利用できること。

準備

ロールの作成

assume-role-policy.json

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Principal": { "AWS": "arn:aws:iam::<アカウントID>:root" },
        "Action": "sts:AssumeRole"
    }
} 
ROLE_ARN=$(aws iam create-role --role-name fargate-helloworld-role --assume-role-policy-document file://./assume-role-policy.json | jq -r '.Role.Arn')
aws iam attach-role-policy --role-name fargate-helloworld-role --policy-arn "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"

コンテナイメージのリポジトリ作成

コンテナのリポジトリはDockerHubなどがありますが、今回はAWSのECRを使います。

HELLO_REPO_URI=$(aws ecr create-repository --repository-name helloworld/hello | jq -r '. repository. repositoryUri')
WORLD_REPO_URI=$(aws ecr create-repository --repository-name helloworld/world | jq -r '. repository. repositoryUri')
NGINX_REPO_URI=$(aws ecr create-repository --repository-name helloworld/nginx | jq -r '. repository. repositoryUri')

ECRにログインしておく

$(aws ecr get-login --no-include-email --region ap-northeast-1)

Webサーバのコンテナ作成

Webサーバにはnginxを使います。 nginxはALBからリクエストを受けて、サービスディスカバリを利用してアプリケーションにリクエストをします。

mkdir helloworld-nginx
cd helloworld-nginx

nginxの設定

default.confを作成します。

server {
    
    listen       80;
    server_name  localhost;
    
    proxy_set_header    Host    $host;
    proxy_set_header    X-Real-IP    $remote_addr;
    proxy_set_header    X-Forwarded-Host       $host;
    proxy_set_header    X-Forwarded-Server    $host;
    proxy_set_header    X-Forwarded-For    $proxy_add_x_forwarded_for;
    
    location ^~ /hello/ {
        # パスの先頭が「/hello/」の場合に helloアプリケーションにリクエスト
        proxy_pass    http://hello.helloworld:8080/hello/; 
    }

    location ^~ /world/ {
        # パスの先頭が「/world/」の場合に worldアプリケーションにリクエスト
        proxy_pass    http://world.helloworld:8080/world/;
    }

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

「hello.helloworld」、「world.helloworld」はサービスディスカバリの機能によってDNS解決されます。

Dockerfileを作成

FROM nginx

# 作成したdefault.confをnginxサーバに置きます
ADD "default.conf" "/etc/nginx/conf.d/"

Dockerリポジトリにプッシュ

docker build -t helloworld-nginx .
docker tag helloworld/nginx:latest ${NGINX_REPO_URI}:latest
docker push ${NGINX_REPO_URI}:latest

アプリケーションのコンテナ作成

今回作成するアプリケーションは、JavaEE + Payara Microで作ります。 アプリケーションは、Hello、Worldの2つ作ります。

Helloサービス

@Path("hello")
public class HelloResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String getText() {
        // Worldサービスのホストは環境変数から取得
        String host = System.getenv("WORLD_HOST");

        String url = "http://" + host + ":8080/world/webresources";

        // Worldアプリケーションから文字列を受け取り、Helloと結合して返却する
        return "Hello " + ClientBuilder.newClient()
                .target(url)
                .path("world")
                .request()
                .get(String.class);
    }
}

pom.xmlの編集

buildタグ内に追加

<build>
  <finalName>hello</finalName> ←追加

Dockerファイルを作成する。

FROM payara/micro

# curlをインストールするため一時的にrootユーザに変更
USER root
RUN apk add --no-cache curl
USER payara
ADD "target/hello.war" "/tmp/"
ENTRYPOINT ["java", "-jar", "payara-micro.jar","--deploy","/tmp/hello.war"]

Dockerリポジトリにプッシュ

mvn clean package
docker build -t helloworld-hello .
docker tag helloworld/hello:latest ${HELLO_REPO_URI}:latest
docker push ${HELLO_REPO_URI}:latest

Worldサービス

@Path("world")
public class WorldResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String getText() {
        return "World!";
    }
}

pom.xmlの編集

<build>
  <finalName>world</finalName> ←追加

Dockerfileの作成

FROM payara/micro

# curlをインストールするため一時的にrootユーザに変更
USER root
RUN apk add --no-cache curl
USER payara
ADD "target/world.war" "/tmp/"
ENTRYPOINT ["java", "-jar", "payara-micro.jar","--deploy","/tmp/world.war"]

Dockerリポジトリにプッシュ

mvn clean package
docker build -t helloworld-world .
docker tag helloworld/world:latest ${WORLD_REPO_URI}:latest
docker push ${WORLD_REPO_URI}:latest

タスク定義の設定

タスク定義の登録をCLIで実行する際に、オプション値にjsonで渡すものがあり、シンタックスベースの場合ダブルクォートのエスケープが必要になるので、JSONで設定します。

サービスのコンテナは、内部でヘルスチェックを行うようにします。

Helloサービス

task-hello.jsonの作成

{
    "family": "helloworld-hello", 
    "networkMode": "awsvpc", 
    "taskRoleArn": "<ROLE_ARN>",
    "executionRoleArn": "<ROLE_ARN>",
    "containerDefinitions": [
        {
            "name": "helloworld-hello", 
            "image": "<リポジトリURI>", 
            "portMappings": [
                {
                    "containerPort": 8080, 
                    "hostPort": 8080, 
                    "protocol": "tcp"
                }
            ], 
            "essential": true,
            "healthCheck": {
              "retries": 3,
              "command": [
                "CMD-SHELL",
                "curl http://localhost:8080/hello/index.html || exit 1"
              ],
              "timeout": 5,
              "interval": 30,
              "startPeriod": 120
            },
            "environment": [
              {
                "name": "WORLD_HOST",
                "value": "world.helloworld"
              }
            ]
        }
    ], 
    "requiresCompatibilities": [
        "FARGATE"
    ], 
    "cpu": "512", 
    "memory": "1024"
}

Worldサービス

task-world.jsonの作成

{
    "family": "helloworld-world", 
    "networkMode": "awsvpc", 
    "taskRoleArn": "<ROLE_ARN>",
    "executionRoleArn": "<ROLE_ARN>",
    "containerDefinitions": [
        {
            "name": "helloworld-world", 
            "image": "<リポジトリURI>", 
            "portMappings": [
                {
                    "containerPort": 8080, 
                    "hostPort": 8080, 
                    "protocol": "tcp"
                }
            ], 
            "essential": true,
            "healthCheck": {
              "retries": 3,
              "command": [
                "CMD-SHELL",
                "curl http://localhost:8080/world/index.html || exit 1"
              ],
              "timeout": 5,
              "interval": 30,
              "startPeriod": 120
            }
        }
    ], 
    "requiresCompatibilities": [
        "FARGATE"
    ], 
    "cpu": "512", 
    "memory": "1024"
}

Nginx

task-nginx.jsonの作成

{
    "family": "helloworld-nginx", 
    "networkMode": "awsvpc", 
    "taskRoleArn": "<ROLE_ARN>",
    "executionRoleArn": "<ROLE_ARN>",
    "containerDefinitions": [
        {
            "name": "helloworld-nginx", 
            "image": "<リポジトリURI>", 
            "portMappings": [
                {
                    "containerPort": 80, 
                    "hostPort": 80, 
                    "protocol": "tcp"
                }
            ], 
            "essential": true,
            "healthCheck": {
              "retries": 3,
              "command": [
                "CMD-SHELL",
                "curl http://localhost/ || exit 1"
              ],
              "timeout": 5,
              "interval": 30,
              "startPeriod": 0
            }
        }
    ], 
    "requiresCompatibilities": [
        "FARGATE"
    ], 
    "cpu": "256", 
    "memory": "512"
}

環境構築

では、準備が整ったので、CLIベースに順を追って構築していきます。 作業ディレクトリは、上記で作成したtask-xxxx.jsonがある場所に移動してください。

VPCの設定

# VPC作成
VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 | jq -r '.Vpc.VpcId')

# DNS hostname resolutionを有効
aws ec2 modify-vpc-attribute --vpc-id ${VPC_ID} --enable-dns-support
aws ec2 modify-vpc-attribute --vpc-id ${VPC_ID} --enable-dns-hostnames

# インターネットゲートウェイの作成
IGW_ID=$(aws ec2 create-internet-gateway | jq -r '.InternetGateway.InternetGatewayId')

# VPCにインターネットゲートウェイを追加
aws ec2 attach-internet-gateway --internet-gateway-id ${IGW_ID} --vpc-id ${VPC_ID}

# サブネット(パブリック:2、プライベート:2)を作成
PUBLIC_SUBNET_A_ID=$(aws ec2 create-subnet --vpc-id ${VPC_ID} --availability-zone ap-northeast-1a --cidr-block 10.0.0.0/24 | jq -r '.Subnet.SubnetId')
PUBLIC_SUBNET_C_ID=$(aws ec2 create-subnet --vpc-id ${VPC_ID} --availability-zone ap-northeast-1c --cidr-block 10.0.1.0/24 | jq -r '.Subnet.SubnetId')
PRIVATE_SUBNET_A_ID=$(aws ec2 create-subnet --vpc-id ${VPC_ID} --availability-zone ap-northeast-1a --cidr-block 10.0.2.0/24 | jq -r '.Subnet.SubnetId')
PRIVATE_SUBNET_C_ID=$(aws ec2 create-subnet --vpc-id ${VPC_ID} --availability-zone ap-northeast-1c --cidr-block 10.0.3.0/24 | jq -r '.Subnet.SubnetId')

# パブリックのルートテーブル作成
PUBLIC_ROUTE_TABLE_ID=$(aws ec2 create-route-table --vpc-id ${VPC_ID} | jq -r '.RouteTable.RouteTableId')
aws ec2 create-route --route-table-id ${PUBLIC_ROUTE_TABLE_ID} --destination-cidr-block 0.0.0.0/0 --gateway-id ${IGW_ID}

PUBLIC_A_ASSOCITATE_ID=$(aws ec2 associate-route-table --subnet-id ${PUBLIC_SUBNET_A_ID} --route-table-id ${PUBLIC_ROUTE_TABLE_ID} | jq -r '.AssociationId')
PUBLIC_C_ASSOCITATE_ID=$(aws ec2 associate-route-table --subnet-id ${PUBLIC_SUBNET_C_ID} --route-table-id ${PUBLIC_ROUTE_TABLE_ID} | jq -r '.AssociationId')

#Elastic IPを発行
ALLOCATION_ID=$(aws ec2 allocate-address --domain vpc | jq -r '.AllocationId')

# NATゲートウェイを作成
NAT_GATEWAY_ID=$(aws ec2 create-nat-gateway --subnet-id ${PUBLIC_SUBNET_A_ID} --allocation-id ${ALLOCATION_ID} | jq -r '.NatGateway.NatGatewayId')

# プライベートのルートテーブル作成
PRIVATE_ROUTE_TABLE_ID=$(aws ec2 create-route-table --vpc-id ${VPC_ID} | jq -r '.RouteTable.RouteTableId')
aws ec2 create-route --route-table-id ${PRIVATE_ROUTE_TABLE_ID} --destination-cidr-block 0.0.0.0/0 --nat-gateway-id ${NAT_GATEWAY_ID}

PRIVATE_A_ASSOCITATE_ID=$(aws ec2 associate-route-table --subnet-id ${PRIVATE_SUBNET_A_ID} --route-table-id ${PRIVATE_ROUTE_TABLE_ID} | jq -r '.AssociationId')
PRIVATE_C_ASSOCITATE_ID=$(aws ec2 associate-route-table --subnet-id ${PRIVATE_SUBNET_C_ID} --route-table-id ${PRIVATE_ROUTE_TABLE_ID} | jq -r '.AssociationId')

セキュリティグループの設定

# ロードバランサ、Nginx用のセキュリティグループ作成
WEB_SG_ID=$(aws ec2 create-security-group --group-name helloworld-web-sg --description "web security group" --vpc-id ${VPC_ID} | jq -r '.GroupId')

# インバウンド設定で80を許可する
aws ec2 authorize-security-group-ingress --group-id ${WEB_SG_ID} --protocol tcp --port 80 --cidr 0.0.0.0/0

# サービス用のセキュリティグループ作成
APP_SG_ID=$(aws ec2 create-security-group --group-name helloworld-app-sg --description "application security group" --vpc-id ${VPC_ID} | jq -r '.GroupId')

# インバウンド設定で8080を許可する
aws ec2 authorize-security-group-ingress --group-id ${APP_SG_ID} --protocol tcp --port 8080 --cidr 0.0.0.0/0

ロードバランサの設定

# ターゲットグループの作成
# ロードバランサがリクエストを送るターゲットを登録
TARGET_GROUP_ARN=$(aws elbv2 create-target-group --name helloworld-nginx --protocol HTTP --port 80 --vpc-id ${VPC_ID} --target-type ip | jq -r '.TargetGroups[0].TargetGroupArn')

# ロードバランサ作成
LB_ARN=$(aws elbv2 create-load-balancer --name alb-helloworld  --subnets ${PUBLIC_SUBNET_A_ID} ${PUBLIC_SUBNET_C_ID} --security-groups ${WEB_SG_ID} | jq -r '.LoadBalancers[0].LoadBalancerArn')

# リスナー登録
aws elbv2 create-listener --load-balancer-arn ${LB_ARN} --protocol HTTP --port 80 --default-actions Type=forward,TargetGroupArn=${TARGET_GROUP_ARN}

ECSの設定

# タスク定義作成
TASK_HELLO_REVISION=$(aws ecs register-task-definition --cli-input-json file://./task-hello.json | jq -r '.taskDefinition.revision')

TASK_WORLD_REVISION=$(aws ecs register-task-definition --cli-input-json file://./task-world.json | jq -r '.taskDefinition.revision')

TASK_NGINX_REVISION=$(aws ecs register-task-definition --cli-input-json file://./task-nginx.json | jq -r '.taskDefinition.revision')

# クラスタ作成
CLUSTER_NAME=fargate-helloworld
aws ecs create-cluster --cluster-name ${CLUSTER_NAME}

# サービス検出ネームスペース作成
OPERATION_ID=$(aws servicediscovery create-private-dns-namespace --name helloworld --vpc ${VPC_ID} | jq -r '.OperationId')

# 作成したネームスペースのIDを確認
NAMESPACE_ID=$(aws servicediscovery get-operation --operation-id ${OPERATION_ID} | jq -r '.Operation.Targets.NAMESPACE')

ネームスペース作成に時間がかかるので、1分ほど待つ。

# Helloサービス名登録
HELLO_SERVICE_ID=$(aws servicediscovery create-service --name hello --dns-config "NamespaceId=${NAMESPACE_ID},RoutingPolicy=MULTIVALUE,DnsRecords=[{Type=A,TTL=60}]" | jq -r '.Service.Id')
HELLO_REGISTRY_ARN=$(aws servicediscovery get-service --id ${HELLO_SERVICE_ID} | jq -r '.Service.Arn')

# Worldサービス名登録
WORLD_SERVICE_ID=$(aws servicediscovery create-service --name world --dns-config "NamespaceId=${NAMESPACE_ID},RoutingPolicy=MULTIVALUE,DnsRecords=[{Type=A,TTL=60}]" | jq -r '.Service.Id')
WORLD_REGISTRY_ARN=$(aws servicediscovery get-service --id ${WORLD_SERVICE_ID} | jq -r '.Service.Arn')

# Nginxサービス名登録
NGINX_SERVICE_ID=$(aws servicediscovery create-service --name nginx --dns-config "NamespaceId=${NAMESPACE_ID},RoutingPolicy=MULTIVALUE,DnsRecords=[{Type=A,TTL=60}]" | jq -r '.Service.Id')
NGINX_REGISTRY_ARN=$(aws servicediscovery get-service --id ${NGINX_SERVICE_ID} | jq -r '.Service.Arn')

# Helloサービス作成
aws ecs create-service --cluster ${CLUSTER_NAME} --service-name hello-service --task-definition helloworld-hello:${TASK_HELLO_REVISION} --desired-count 1 --launch-type "FARGATE" --network-configuration "awsvpcConfiguration={subnets=["${PRIVATE_SUBNET_A_ID}","${PRIVATE_SUBNET_C_ID}"],securityGroups=["${APP_SG_ID}"],assignPublicIp=DISABLED}" --service-registries "registryArn=${HELLO_REGISTRY_ARN},containerName=helloworld-hello"

# Worldサービス作成
aws ecs create-service --cluster ${CLUSTER_NAME} --service-name world-service --task-definition helloworld-world:${TASK_WORLD_REVISION} --desired-count 1 --launch-type "FARGATE" --network-configuration "awsvpcConfiguration={subnets=["${PRIVATE_SUBNET_A_ID}","${PRIVATE_SUBNET_C_ID}"],securityGroups=["${APP_SG_ID}"],assignPublicIp=DISABLED}" --service-registries "registryArn=${WORLD_REGISTRY_ARN},containerName=helloworld-world"

# Nginxサービス作成
aws ecs create-service --cluster ${CLUSTER_NAME} --service-name nginx-service --task-definition helloworld-nginx:${TASK_NGINX_REVISION} --desired-count 1 --launch-type "FARGATE" --network-configuration "awsvpcConfiguration={subnets=["${PRIVATE_SUBNET_A_ID}","${PRIVATE_SUBNET_C_ID}"],securityGroups=["${WEB_SG_ID}"],assignPublicIp=DISABLED}" --service-registries "registryArn=${NGINX_REGISTRY_ARN},containerName=helloworld-nginx" --load-balancers "targetGroupArn=${TARGET_GROUP_ARN},containerName=helloworld-nginx,containerPort=80"

動作確認

以下のコマンドを実行する。

open http://$(aws elbv2 describe-load-balancers --load-balancer-arns ${LB_ARN} | jq -r '.LoadBalancers[0].DNSName')/hello/webresources/hello

表示された画面に「Hello World!」が表示されるか確認してください。 環境構築後、ヘルスチェックが通すまでに時間がかかるので、時間をおいてから確認してください。

環境削除

最後に構築した環境をお片づけしましょう。

# ECSサービスの起動タスク数を0に更新
aws ecs update-service --cluster fargate-helloworld --service nginx-service --desired-count 0
aws ecs update-service --cluster fargate-helloworld --service hello-service --desired-count 0
aws ecs update-service --cluster fargate-helloworld --service world-service --desired-count 0

# ECSサービスを削除
aws ecs delete-service --cluster fargate-helloworld --service nginx-service
aws ecs delete-service --cluster fargate-helloworld --service hello-service
aws ecs delete-service --cluster fargate-helloworld --service world-service

# ECSクラスタを削除
aws ecs delete-cluster --cluster fargate-helloworld

# サービスディスカバリのサービス名を削除
aws servicediscovery delete-service --id ${HELLO_SERVICE_ID}
aws servicediscovery delete-service --id ${WORLD_SERVICE_ID}
aws servicediscovery delete-service --id ${NGINX_SERVICE_ID}

# サービスディスカバリのネームスペースを削除
aws servicediscovery delete-namespace --id ${NAMESPACE_ID}

# ロードバランサを削除
aws elbv2 delete-load-balancer --load-balancer-arn ${LB_ARN}

# ターゲットグループを削除
aws elbv2 delete-target-group --target-group-arn ${TARGET_GROUP_ARN}

# NATゲートウェイを削除
aws ec2 delete-nat-gateway --nat-gateway-id ${NAT_GATEWAY_ID}

# ルートテーブルを削除
aws ec2 delete-route --route-table-id ${PRIVATE_ROUTE_TABLE_ID} --destination-cidr-block 0.0.0.0/0
aws ec2 disassociate-route-table --association-id ${PRIVATE_A_ASSOCITATE_ID}
aws ec2 disassociate-route-table --association-id ${PRIVATE_C_ASSOCITATE_ID}
aws ec2 delete-route-table --route-table-id ${PRIVATE_ROUTE_TABLE_ID}

aws ec2 delete-route --route-table-id ${PUBLIC_ROUTE_TABLE_ID} --destination-cidr-block 0.0.0.0/0
aws ec2 disassociate-route-table --association-id ${PUBLIC_A_ASSOCITATE_ID}
aws ec2 disassociate-route-table --association-id ${PUBLIC_C_ASSOCITATE_ID}
aws ec2 delete-route-table --route-table-id ${PUBLIC_ROUTE_TABLE_ID}

# インターネットゲートウェイをデタッチ
aws ec2 detach-internet-gateway --internet-gateway-id ${IGW_ID} --vpc-id ${VPC_ID}

# Elastic IPを解放
aws ec2 release-address --allocation-id ${ALLOCATION_ID}

# サブネットを削除
aws ec2 delete-subnet --subnet-id ${PUBLIC_SUBNET_A_ID}
aws ec2 delete-subnet --subnet-id ${PUBLIC_SUBNET_C_ID}
aws ec2 delete-subnet --subnet-id ${PRIVATE_SUBNET_A_ID}
aws ec2 delete-subnet --subnet-id ${PRIVATE_SUBNET_C_ID}

# セキュリティグループを削除
aws ec2 delete-security-group --group-id ${WEB_SG_ID}
aws ec2 delete-security-group --group-id ${APP_SG_ID}

# VPCを削除
aws ec2 delete-vpc --vpc-id ${VPC_ID}

おわりに

AWS CLIのみでFargateを使った環境構築を行いました。 今回はオートスケーリングなどの設定を行いませんでしたが、負荷に応じてタスクごとにスケールが可能なので、 コンピューティングリソースを有効に使いつつ、柔軟に対応ができそうです。 サービスごとにアプリケーションの更新が可能なので、他のサービスに影響を与えずにデプロイが可能になります。

もし、マイクロサービスに手をつけたいけど、インフラ環境をどうすればいいか悩んでいる方は、試してみてください。

参考

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-service-discovery.html

DBのバージョン管理で苦労しないために

どうも、小野です。

今回は、開発で意外と問題になってくるDBのバージョン管理についてのお話です。

みなさんは、どのように管理していますか? DBは開発工程前に予め設計するのですが、やはり変更はつきものです。 しかもDBはアプリケーションの核になっているので、構成が変わるとエラーが発生したり、随時更新していかないと環境によって構成が異なったりします。

私も周知漏れなどで、自分のところでは動くけど、他の環境では動かないなどは日常茶飯事でした。 ちゃんと管理しろって話ですが、エンジニアの人数も少なかったので、管理コストに比べたら、トライアルアンドエラーの方が良かったりします(汗 ただし、エラーログに「〜の列が見つかりません。」のような、エラーのトレースができることが前提ですね。

現状の管理方法における問題点を挙げ、改善方法についてお話します。

続きを読む

Trelloによるプロジェクト管理

アジアカップもW杯のような盛り上がりを見せて欲しいと思っている、小野です。

プロジェクトを進めていく中で、プロジェクト(タスク)管理は必要になってきます。 管理方法については、十人十色で企業によってやり方は異なります。弊社ではタスク管理方法にTrello(トレロ)を採用しています。

今回は、Trelloを使ったタスク管理方法についてご紹介したいと思います。

trello.com

Trelloを採用した理由

無料で利用できるWebサービスなので、サーバ管理も不要です。Googleアカウントを持っていれば、アカウント登録が簡単です。

Trelloを採用したのは、以下の理由が挙げられます。

  • 操作が直感的で使いやすい、わかりやすい
  • メンバーのタスクが把握しやすい
  • アドオン、Chrome拡張機能によるカスタマイズ性が高い

今までにRedmineを使いましたが、Trelloに比べ入力項目が多く、タスクの更新を行うための手順が多いので途中で断念しました。 進捗を変更するだけでも、詳細を開いて、進捗を変更して、保存といった操作が必要です。 Trelloであれば、ドラッグ&ドロップのみで変更できます。

ボードを作成する

ボードはプロジェクト単位で作成するのが管理しやすいです。(〜アプリ開発など)

ボード作成
ボード作成

作成する際に、ボード名と公開範囲を決めます。作成するとホーム画面にボードが表示されます。

リストを用意する

作成したボードを開いて、リストを以下の5つ用意します。このリストで進捗を管理します。

  • Pending(保留、やるかも)
  • Todo(やること)
  • Doing(仕掛中)
  • Done(完了)
  • Review(確認)

進捗管理リスト
進捗管理リスト

横スクロールの必要がない範囲で収めると使いやすくなると思います。 ちなみに今使っている端末はMacbookAirの13インチで、解像度は1440×900です。

Pending

やるかどうかわからないタスクや、今作業するタイミングではないタスクなどを置きます。 定期的に棚卸ししていかないと、溜まっていくので注意が必要です。

Todo

やるべきタスクを置きます。新たにカードを作成するときはここに作成します。

Doing

作業中のタスクを置きます。 担当者がTodoからDoingにカードを移して、作業を開始します。

Done

担当者が作業を完了したら置きます。

Review

第三者への確認が必要なタスクを置きます。 アプリケーションの動作確認やレビューなどです。

タスクを作成する

まずはタスク名と後述するラベルだけ設定しておきます。 他に必要があれば、タスクの詳細、担当するメンバー、期限などを設定します。

タスク作成
タスク作成

タスクの優先順位の付け方

タスクを行う際の優先順位はカードの並び順で設定します。 以下の図のように、上が高く下が低いとイメージです。

優先順位
優先順位

ラベルでリリースバージョンを管理

同じプロジェクトでも、タスクによってリリースするバージョンが異なる場合があります。その場合にラベルを使います。 Trelloのフィルタリング機能によるラベルの絞り込みができるので、特定バージョンのカードのみを表示することも可能です。

ボード上に表示されるのは、ラベルの色のみなので、その色がどのバージョンなのかわかりづらいです。 そこで後述するプラグインを利用することで、ラベル名も表示できるようになります。 以下の画像は、Chrome拡張機能を追加した場合のものです。

ラベルによるバージョン管理
ラベルによるバージョン管理

実際のカードの流れ

  1. Todoにタスク(カード)を作成します。
  2. 担当者はTodoからDoingにカードを移動し、作業に取り掛かります。
  3. 作業が完了したら、Doneにカードを移動します。(タスクの内容によっては、Reviewに移動することもあります)
  4. 開発環境(サーバ)へのデプロイなどを行い、Reviewにカードを移動します。
  5. 確認で問題がなければ、カードをアーカイブし、問題があればTodoに移動する。

カードを移動する際にメンバーをアサインすると、担当者にデスクトップ通知されるので気付きやすくなります。

おすすめの拡張機能

前にも申し上げましたが、Trelloはアドオンを追加できます。ただし、無料アカウントの場合だと、1つのアドオンまでしか追加できません。 2つ以上利用したい場合は、有料アカウントになる必要があります。

ChromeでもTrello向けの拡張機能がありますので、2つほどご紹介します。

カードにラベル名称を表示します。

カードにNoを表示します。 Gitのブランチ名などにカードNoを入れてあげると、カードとソースバージョンの紐付けが行いやすくなります。

おわりに

弊社で行なっているTrelloを使ったタスク管理方法は一例に過ぎません。大事なのは、自分たちにとって最適な手法を見つけることです。 ぜひ、タスク管理にTrelloを採用してみてはいかがでしょうか?

JJUG CCC 2018 Fallに参加してきました

www.java-users.jp

どうも、小野です。

先日、JJUG(Japan Java User Group)が主催するJJUG CCC 2018 Fallに参加してきました。 今回はその様子をお伝えしていきます。 本記事では、セッションの内容は書きません。内容について知りたい方は、 記事の最後のリンクを確認してください。

写真を全くと言っていいほど、撮っていないのでイメージしにくいとは思いますが、 予めご了承くださいm( )m

(余談ですが、イベント名にFallとありますが、時期的にWinterですね。)

開催場所は新宿ベルサールグランドカンファレンスセンターでした。 JR新宿駅西口から徒歩15分程度とちょっと遠いんですね。

JJUG CCCの特徴

スタッフがボランティア

他の企業主催のイベントはわかりませんが、JJUGのイベントは100%ボランティアスタッフです。 ボランティアスタッフのみなさんには本当に感謝しています。

託児所があります

お子さんがいる家庭で、休日のイベント参加は難しいものがあります。 なんと、本イベントでは託児所が設けられています。 安心して子連れで参加できますね。 次回、参加する機会があったら利用したいと思います。

参加費無料

コミュニティ主催でありながら、参加費が無料です。 しかも、ランチセッションに参加すると、お弁当も配布されます。 場所代、お弁当代だけ考えても結構な金額いくと思いますが、 そこを無料でやっていただけるのはとても助かるし、感謝しています。 ただし、全てのセッション後は懇親会があるのですが、これに参加する場合は1000円かかります。 でも、1000円以上の価値はありましたね。 料理は、LINEの恒例?の寿司が提供されていたみたいです。LINE DEVELOPER DAYでもありました。 (残念ながら、私は次の日3時起きだったので参加できませんでした。。。)

受講セッションの内容

Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話(福嶋航)

私も普段AWSを利用しており、身近に感じる内容でした。 ECSについては前々から興味があり、Java、SpringBootでどのように構築されているか興味がありました。

セッションの内容はJavaの内容よりもECSよりの話でした。

あと、今だとFargateが東京リージョンにあるので、なぜ使わないのかなと思っていたのですが、 FargateにはECSに比べコストがかかるというデメリットがため採用しなかったそうです。 確かに、コストがかかるという記事はよく見かけます。

まずはECSから使ってみようと思います。

モジュールグラフが作られる様子を学ぼう(opengl-8080)

よくQiitaでお世話になっているopengl-8080さんのセッションです。

Java9からモジュールシステムの導入により、新たな問題の解決方法を説明してくださいました。 相変わらず、図を使い込みわかりやすい資料でした。 今、業務ではJava8を利用していおり、モジュールシステムについてはモヤっとしか理解していませんが、 今後、Javaのアップデートした際には、本資料を活用したいと思います。

今こそStream API入門(櫻庭 祐一)

Java8から導入されたStream APIですが、個人的に今更感はあったので小ネタでを挟んでくるのかなと期待していましたが、 入門と書いてある通り、初心者向けの内容でした。

業務でStreamAPIを使っているので、既知の内容でしたが、1つだけ勉強になったことがあります。 それは、StreamAPIを使ったことがある人だったら、一度は躓く例外の取り扱いについてです。 登壇者である櫻庭さんの回答は「Either」を利用するといいそうです。

ちなみに私は、Stream処理内でRuntimeExceptionをスローし、Stream処理外でCatchするようにしています。

Java を活用したマイクロサービスのための Kubernetes 活用(寺田佳央)

寺田さんは話の冒頭に、Microsoftに在籍していながらも、自分は「Javaの人間」とアピールしていたのがとても印象的でした。

さて、本セッションは最近注目されているkubernates(K8s)のお話です。

kubernatesはマイクロサービスの管理を楽になるなど得られるメリットは大きいのですが、 その反面、覚えることが多く安易に採用しない方がいいとのことでした。

本番運用での採用は、まだ難しいかもしれないですね。

さいごに

コミュニティ主催であり、お弁当が配布されるなら参加料は有料でもいいのかなと思いました。 無料でここまでやれているのが凄いと思います。

本カンファレンスは、イベント名のとおりJavaを中心とした内容になっています。 初心者から上級者までJavaに興味がある人でしたら楽しめるイベントだと思います。 年に2回開催されているので、興味があったら参加してみてください。

セッションの資料が以下にまとめられています。 興味のある方はぜひ。

github.com

LINE DEVELOPER DAY 2018に参加してきました

f:id:frevo-works:20181122000445j:plain

どうも、小野です。

先日、LINEが主催するエンジニア向けカンファレンス『LINE DEVELOPER DAY 2018』に参加してきました。 過去にも何度か開催されていたのですが、情報収集力が足りず、あったことすら知りませんでした。無念。。 今年の開催に関しては、Twitterでフォロー中の ちょまど(@chomado) さんのツイートを見て知りました。 Twitterは重要ですね。

今年のテーマは「NEXT LINE」です。LINEが次に目指すものは大きく分けて2つあります。

続きを読む

マイクロサービス化に悩んでる人へ

どうも、小野です。

以前、参加されていただいたAWS DEV DAYのMicroservicesのセッションを聴いて、
改めてマイクロサービスの有効性や複雑性など再認識させられました。

特に、以下のスライドがとても参考になりました。

www.slideshare.net

今はバスワードとも言える「マイクロサービス」。

マイクロサービスとよく比較されるものとして、モノリシックというアーキテクチャがあります。

モノリシックは1枚岩と表現されるとおり、1つの巨大なシステム(サービス)のことです。
管理対象は1つなので、管理は楽そうではありますが、以下のようなデメリットが挙げられます。

  • プログラム修正時の影響範囲の把握が難しい
  • テストを含むビルドに時間がかかる

これは最終的にリリースサイクルのスピードに関わってきます。

これらを解決するために考えられたのが、マイクロサービスです。

私もマイクロサービスについて勉強し、導入を検討しましたが、結局断念しました。
断念した理由ですが、主に以下の3つが挙げられます。

  • 実装での考慮すべき点が多く、実装コストの増加につながる
  • エンジニアが足りない
  • リリースのスピードが求められていない

当時携わっていたシステムは受託PJだったため、スケジュールも決められており、
実装コストをなるべく抑え、品質を重視する必要があったため、断念せざるを得ませんでした。
その上、人が全然足りず、マイクロサービスをやっていくのは自分の首を締めるだけでした。

本記事ではマイクロサービスの導入によって、どこまでのメリットが得られるか考えながら読んでいただきたいです。

続きを読む