継続は力なり

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

RDS の SSL/TLS 証明書を AWS CLI でローテーションする

タダです.

RDS および Aurora で使用している SSL/TLS 証明書が rds-ca-2015 を使っている場合は 3/5までにrds-ca-2019 に切り替える必要があります.今回は AWS CLI で RDS の証明書を切り替える検証を行なったので同様の対応を検討している方の参考になれば嬉しいです. sadayoshi-tada.hatenablog.com

証明書の切り替えで使うコマンドについて

証明書を切り替えるために使ったコマンドは以下のコマンドです.

  • describe-db-instances
  • describe-pending-maintenance-actions
  • modify-db-instance

コマンドの利用詳細

それぞれのコマンドの利用の詳細を順番で書きます.

1, describe-db-instancesrds-ca-2015インスタンスを確認します.

aws rds describe-db-instances --query 'DBInstances[?CACertificateIdentifier==`rds-ca-2015`].{Name:DBInstanceIdentifier}' --output table
---------------------
|DescribeDBInstances|
+-------------------+
|       Name        |
+-------------------+
|  database-1       |
+-------------------+

2, describe-pending-maintenance-actions で保留中のメンテナンスの有無を確認します.

aws rds describe-pending-maintenance-actions                    
{
    "PendingMaintenanceActions": [
        {
            "ResourceIdentifier": "arn:aws:rds:ap-northeast-1:XXXXXXXX:db:database-1",
            "PendingMaintenanceActionDetails": [
                {
                    "Action": "ca-certificate-rotation",
                    "AutoAppliedAfterDate": "2020-02-04T22:03:06Z",
                    "CurrentApplyDate": "2020-02-04T22:03:06Z",
                    "Description": "Rotation of CA certificate"
                }
            ]
        }
    ]
}

AWS のブログによると 2/5~3/5 に証明書が切り替わって再起動すれば証明書が有効な状態になります.上記の保留中のメンテナンスはこの証明書切り替えのメンテンスとなります.このメンテナンスが表示されているうちは証明書切り替えが完了していないことになります.

RDS、Aurora、DocumentDB 用の SSL/TLS 証明書が失効し、メンテナンスおよびセキュリティ管理に関する当社の標準規律に則った 5 年に 1 度の置き換えが行われます。それに関して、重要なスケジュールを次に明記しておきます。

2019 年 9 月 19 日 ー CA-2019 証明書が利用可能になりました。

2020 年 1 月 14 日 ー この日以降、作成されるインスタンスは、新しい証明書 (CA-2019) を使用するようになります。必要性がある場合は、一時的に古い証明書に戻すこともできます。

2020 年 2 月 5 日~3 月 5 日 ー RDS において、既存インスタンスに対する新しい証明書の (インストールのみで有効化はしない) ステージングが行われます。インスタンスを再起動することで、この証明書が有効化されます。

2020 年 3 月 5 日 ー CA-2015 が失効します。証明書の検証を使用しているアプリケーションで更新を行っていないものは、接続ができなくなります。

aws.amazon.com

3, modify-db-instance で証明書を切り替える

いよいよ証明書を切り替えます.SSL 接続を行う場合はインスタンスクラスターの再起動が発生しますが,SSL 接続を行なっていない場合は再起動不要な AWS CLI オプション --no-certificate-rotation-restart もあるので,AWS のブログで紹介されたコマンドを試してみました.コマンドを実行後に describe-pending-maintenance-actions で確認したらまだ保留中のメンテナンスが残っています.つまり,rds-ca-2019 への変更が保留中となっている状態になっていてまだ証明書の切り替えは完了していない状態と言えます.

 aws rds modify-db-instance --db-instance-identifier database-1 --ca-certificate-identifier rds-ca-2019 --no-certificate-rotation-restart
{
    "DBInstance": {
        "DBInstanceIdentifier": "database-1",
        "DBInstanceClass": "db.t2.micro",
        "Engine": "mysql",
        "DBInstanceStatus": "available",
        ~中略~
        "PreferredMaintenanceWindow": "thu:15:50-thu:16:20",
        "PendingModifiedValues": {
            "CACertificateIdentifier": "rds-ca-2019"
        },
        ~中略~
        "CACertificateIdentifier": "rds-ca-2015",
        ~中略~
    }
}

aws rds describe-pending-maintenance-actions               
{
    "PendingMaintenanceActions": [
        {
            "ResourceIdentifier": "arn:aws:rds:ap-northeast-1:XXXXXXXX:db:database-1",
            "PendingMaintenanceActionDetails": [
                {
                    "Action": "ca-certificate-rotation",
                    "AutoAppliedAfterDate": "2020-02-04T22:03:06Z",
                    "CurrentApplyDate": "2020-02-04T22:03:06Z",
                    "Description": "Rotation of CA certificate"
                }
            ]
        }
    ]
}

GUI で証明書を切り替えを行う場合もこの変更をすぐに適用するか,メンテナンスウィンドウで適用かを指定しています.そのため, 変更をすぐに適用する --apply-immediately オプションを指定して再度実行しました.describe-pending-maintenance-actions で再度確認したら保留中のメンテナンスの表示が消えたので証明書切り替え完了です.

aws rds modify-db-instance --db-instance-identifier database-1 \
  --ca-certificate-identifier rds-ca-2019 --no-certificate-rotation-restart --apply-immediately
{
    "DBInstance": {
        "DBInstanceIdentifier": "database-1",
        "DBInstanceClass": "db.t2.micro",
        "Engine": "mysql",
        "DBInstanceStatus": "available",
        ~中略~
        "PreferredMaintenanceWindow": "thu:15:50-thu:16:20",
        "PendingModifiedValues": {
            "CACertificateIdentifier": "rds-ca-2019"
        },
        ~中略~
        "CACertificateIdentifier": "rds-ca-2015",
        ~中略~
    }
}

aws rds describe-pending-maintenance-actions
{
    "PendingMaintenanceActions": []
}

念のため GUI でも確認しても証明書が rds-ca-2019 に切り替わっていることが確認できました. f:id:sadayoshi_tada:20200117214821p:plain

まとめ

CA 証明書切り替えを AWS CLI で動作を確認したのでその内容をまとめました.--no-certificate-rotation-restartオプションを使うまでこのオプションを使えば証明書が切り替わっていると勘違いしていたので確認ができてよかったです.改めて検証の大切さを感じました.

『PowerUserAccess』を使わず EC2 や Lambda の IAM を制御するポリシーサンプル

タダです.

開発期間中に開発者の権限としてAWS 管理ポリシー「PowerUserAccess」を設定することがあると思います.ただ,「PowerUserAccess」の詳細を確認すると IAM の操作がNotActionで不許可にされています.

PowerUserAccess」の詳細

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*",
                "account:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:DeleteServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization",
                "account:ListRegions"
            ],
            "Resource": "*"
        }
    ]
}

EC2 や Lambda などのサービスでは IAM ロールを作り他のサービスと連携しますが,「PowerUserAccess」を設定すると IAM ロールや ポリシーの作成や付与ができません.AWS の管理者としては開発スピードを落とさず,IAM は必要最低限の権限を付与させたいです.今回は,EC2 と Lambda の IAM ロール・ポリシーを作成,付与する場合の IAM ポリシーを検証したので設定例を紹介します.

EC2 の IAM ポリシー例

EC2 の IAM ロール・ポリシー作成,付与のための IAM ポリシー例が以下になります.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateRole",
                "iam:CreatePolicy",
                "iam:PutRolePolicy",
                "iam:AttachRolePolicy",
                "iam:PassRole",
                "iam:List*",
                "iam:Get*",
                "iam:CreateInstanceProfile",
                "iam:AddRoleToInstanceProfile"
            ],
            "Resource": "*"
        }
    ]
}

肝となるのが iam:CreateInstanceProfileiam:AddRoleToInstanceProfile になります.EC2 の IAM ロールには インスタンスプロファイルを使用しますので,インスタンスプロファイルを作り(iam:CreateInstanceProfile)IAM ロールにインスタンスプロファイルを追加する( iam:AddRoleToInstanceProfile ) が必要です.

Lambda の IAM ポリシー例

次に, Lambda の IAM ロール・ポリシー作成,付与のための IAM ポリシー例が以下になります.カスタムポリシー,AWS 管理ポリシーどちらも Lambda の IAM ロールに適用可能なポリシーとなっています.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateRole",
                "iam:CreatePolicy",
                "iam:PutRolePolicy",
                "iam:AttachRolePolicy",
                "iam:PassRole",
                "iam:List*",
                "iam:Get*"
            ],
            "Resource": "*"
        }
    ]
}

Lambda 関数に綿密なアクセス権の解説ドキュメント

なお,Lambda の IAM ポリシーはドキュメントでも詳しく解説されている部分が少なかったのですが,下記の記事でケースごとにポリシー例が紹介されているので細かな制御を検討する時に参考にするとよいでしょう. aws.amazon.com

まとめ

EC2 と Lambda の IAM ロールやポリシーを作成・付与するための IAM ポリシー例を紹介しました.ユーザーの権限制御が AWS をセキュアに使うために必要な要素の1つです.IAM ポリシーの作成にあたっては実際に操作してみないと意図通りに設定されてるかがわかりにくいと思いますので,こう言ったナレッジは記事化して同じ悩みを持つ方の参考になれば嬉しいです!

『Jest』での『Fine-grained assertions test』と『Validation tests』の実践

タダです.

AWS CDK のテスト手法で前回は「Snapshot tests」を学んだので,今回は「Fine-grained assertions test」と「Validation tests」を学んでいきます.

「Fine-grained assertions test」と「Validation tests」の意義

  • Fine-grained assertions test」とは,CDKで作成したテンプレートの一部をチェックし意図した設定になっているかをテストするための手法です.
    • 例えば,SQS の場合は expect(stack).toHaveResource('AWS::SQS::Queue', {プロパティ}) の記述で検証します.
  • Validation tests」とは,特定のリソースに対する適切な Construct が定義されているかを検証する手法です.一般的なユニットテストにあたります.

上記の2つのテストを前回の SQS リソースを使って実践します.

sadayoshi-tada.hatenablog.com

「Fine-grained assertions test」 の実践

インフラソースコードの準備

以下のSQS デッドレターキューのソースコードに対して「Fine-grained assertions test」を行います.//でコメントしている箇所のみを変更したとします.

import cloudwatch = require('@aws-cdk/aws-cloudwatch');
import sqs = require('@aws-cdk/aws-sqs');
import { Construct, Duration } from '@aws-cdk/core';

export class DeadLetterQueue extends sqs.Queue {
    public readonly messagesInQueueAlarm: cloudwatch.IAlarm;

    // デッドレターキューの保存期間が14日間の定義
    constructor(scope: Construct, id: string) {
        super(scope,id , {
            retentionPeriod: Duration.days(14)
        });
    // SQS の CloudWatch メトリクスで ApproximateNumberOfMessagesVisible を定義
        this.messagesInQueueAlarm = new cloudwatch.Alarm(this, 'Alarm', {
            alarmDescription: 'There are messages in the Dead Letter Queue',
            evaluationPeriods: 1,
            threshold: 1,
            metric: this.metricApproximateNumberOfMessagesVisible(),
            period: Duration.minutes(1),
        });
    }
}

テストコードの準備

2つのテストコードを用意します.1つ目はデッドレターキューの CloudWatch メトリクス ApproximateNumberOfMessagesVisible が設定されているかのテストで,2つ目はデッドレターキューの保存期間が14日間かのテストになります.

import { Stack } from '@aws-cdk/core';
import '@aws-cdk/assert/jest';

import dlq = require('../lib/dead-letter-queue');

test('dlq creates an alarm', () => {
    const stack = new Stack();

    new dlq.DeadLetterQueue(stack, 'DLQ');

    expect(stack).toHaveResource('AWS::CloudWatch::Alarm', {
        MetricName: "ApproximateNumberOfMessagesVisible",
        Namespace: "AWS/SQS",
        Dimensions: [
        {
            Name: "QueueName",
            Value: { "Fn::GetAtt": [ "DLQ581697C4", "QueueName" ] }
        }
        ],
    });
});

test('dlq has maximum retention period', () => {
    const stack = new Stack();

    new dlq.DeadLetterQueue(stack, 'DLQ');

    expect(stack).toHaveResource('AWS::SQS::Queue', {
        MessageRetentionPeriod: 1209600
    });
});

テストコードの実行

テストコードを実行してみると2つとも意図した設定の通りであったためテストが通りました.変更を加えた箇所のみをテストをしたい場合に「Fine-grained assertions test」が有効でしょう.

>> npm run build && npm test

> jest-handson@0.1.0 build /XXX/XXX/awscdk-handson/jest-handson
> tsc


> jest-handson@0.1.0 test /XXX/XXX/awscdk-handson/jest-handson
> jest

 PASS  test/dead-letter-queue.test.ts
  ✓ dlq creates an alarm (69ms)
  ✓ dlq has maximum retention period (30ms)

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        2.532s
Ran all test suites.

「Validation tests」の実践

インフラソースコードの準備

次に以下のコードに対して「Validation tests」を実践します.SQS のデッドレターキューの保存期間を Construct の Props に渡された値で設定可能なのが最長14日間であるよう定義しています.

import { IAlarm, Alarm } from '@aws-cdk/aws-cloudwatch'
import { Queue } from '@aws-cdk/aws-sqs'
import { Construct, Duration } from '@aws-cdk/core'

export interface DeadLetterQueueProps {
    /**
     * The amount of days messages will live in the dead letter queue
     *
     * Cannot exceed 14 days.
     *
     * @default 14
     */
    retentionDays?: number;
}

export class DeadLetterQueue extends sqs.Queue {
  public readonly messagesInQueueAlarm: cloudwatch.IAlarm;

  constructor(scope: Construct, id: string, props: DeadLetterQueueProps = {}) {
    if (props.retentionDays !== undefined && props.retentionDays > 14) {
      throw new Error('retentionDays may not exceed 14 days');
    }

    super(scope, id, {
        // Given retention period or maximum
        retentionPeriod: Duration.days(props.retentionDays || 14)
    })

    this.messagesInQueueAlarm = new Alarm(this, 'Alarm', {
        alarmDescription: 'There are messages in the Dead Letter Queue',
        evaluationPeriods: 1,
        threshold: 1,
        metric: this.metricApproximateNumberOfMessagesVisible(),
    })
    }
}

テストコードの準備

このテストは CloudFormation テンプレートでリソースにデッドレターキューの保存期間の値を保持しているか,デッドレターキューの保存期間が14日間を超えた場合にエラーが出るかをテストします.

import { Stack } from '@aws-cdk/core';
import '@aws-cdk/assert/jest';

import dlq = require('../lib/dead-letter-queue');

test('retention period can be configured', () => {
    const stack = new Stack();

    new dlq.DeadLetterQueue(stack, 'DLQ', {
        retentionDays: 7
    })
    expect(stack).toHaveResource('AWS::SQS::Queue', {
        MessageRetentionPeriod: 604800,
    })
})

test('configurable retention period cannot exceed 14 days', () => {
    const stack = new Stack()
    expect(() => {
        new dlq.DeadLetterQueue(stack, 'DLQ', {retentionDays: 15})
    }).toThrowError(/retentionDays may not exceed 14 days/)
})

テストコードの実行

テストコードを実行してみると以下のように2つのテストとも通ったことを確認しました.

>> npm run build && npm test

> jest-handson@0.1.0 build /XXX/XXX/awscdk-handson/jest-handson
> tsc


> jest-handson@0.1.0 test /XXX/XXX/awscdk-handson/jest-handson
> jest

 PASS  test/dead-letter-queue.test.ts
  ✓ retention period can be configured (87ms)
  ✓ configurable retention period cannot exceed 14 days (2ms)

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        4.753s, estimated 5s
Ran all test suites.

まとめ

Fine-grained assertions test」と「Validation tests」の意義とテストコードを実践しました.目的に応じて3種類のテストを使い分けて,質の高いインフラのコード開発とデプロイを実践していきたいですね.

関連記事

AWS CDK の他の記事もぜひ!

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

年末年始にこそたくさん学ぼう! AWS のサービス別ワークショップの紹介

タダです.

2019年の年の瀬ですが,みなさんいかがお過ごしでしょうか.年末年始で時間ができたので普段できない勉強や作業に使ってみたり,何かネタを探す方もいるかもしれません.そんな方々向けに AWS が無料で提供しているワークショップをサービス別で紹介します.特に,re:Invent 2019 で公表されたワークショップもありますので,re:Invent 2019 に参加できていない方も学びを通じて楽しめると思います!

Compute

EC2 Spot Instance

EC2 Spot Instances Workshops Site ec2spotworkshops.com

EC2 Spot Instances Workshopp Repository github.com

Lightsail

Amazon Lightsail Workshop Site lightsailworkshop.com

Container

Fargate

Amazon ECS Workshop for AWS Fargate Site ecsworkshop.com

Amazon ECS Workshop for AWS Fargate Repository github.com

EKS

Amazon EKS Workshop Site eksworkshop.com

Amazon EKS Workshop Repository github.com

re:Invent 2019 公表コンテンツ

CON317 - Securing your EKS github.com

NET403: Amazon EKS and Kubernetes on EC2 Container Networking Workshop Site awsk8snetworkshops.com

Amazon EKS and Kubernetes on EC2 Container Networking Workshop GitHub Repository github.com

AppMesh

AWS App Mesh Workshop Site www.appmeshworkshop.com

AWS App Mesh Workshop Repository github.com

Storage

DataSync

NFS server migration using AWS DataSync and AWS Storage Gateway github.com

Database

DMS

DMS での Aurora,DynamoDB への移行とアプリケーション構築の実践 github.com

re:Invent 2019 公表コンテンツ

AWS Database Migration Workshop github.com

Redshift

Redshift Exercises github.com

Security

AWS Security Workshops Site awssecworkshops.com

日本語版サイト awssecworkshops.jp

AWS Security Workshops Repository github.com

re:Invent 2019 公表コンテンツ

OPN215 - Intelligent Automation with AWS and Snort IDS github.com

SEC404 - Building Secure APIs in the Cloud Site workshop.reinvent.awsdemo.me

Management Tools

Service Catalog

re:Invent 2019 公表コンテンツ

Service Catalog tools workshop at re:Invent 2019 Site service-catalog-tools-workshop.com

AWS CDK

Building a Serverless Application with the AWS Cloud Development Kit github.com

日本語の解説サイト aws.amazon.com

re:Invent 2019 公表コンテンツ

ARC321 - Builders Workshop github.com

DOP336 - Serverless app infrastructure with the AWS Cloud Development Kit (AWS CDK) github.com

AWS Management Tools

AWS Management Tools Lab(AWS Service Catalog, AWS Systems Manager, AWS Config, AWS CloudWatch, AWS CloudTrail, AWS CloudFormation) www.awsmanagementweek.com

Control Tower

Control Tower Exercise Labs controltower.aws-management.tools

Well-Architected Framework

AWS Well-Architected Labs SIte wellarchitectedlabs.com

AWS Well-Architected Labs Repository github.com

Mobile

Amplify

re:Invent 2019 公表コンテンツ

AWS re:Invent 2019 Mobile Workshops github.com

Serverless

Lambda, API Gateway, Step Functions,Serverless Application Repository etc

Wild Rydes Serverless Workshops GitHub Repository github.com

Serverless Security Workshop github.com

.NET web application based on decoupled architecture github.com

Serverless Image Processing: Workshop image-processing.serverlessworkshops.io

AWS Workshop on Microservices www.microservicesworkshop.com

re:Invent 2019 公表コンテンツ

SVS201 - Build a serverless web app for a theme park github.com

SVS217 - Package your app for the AWS Serverless Application Repository github.com

SVS203 - AWS Lambda, Amazon API Gateway, Amazon S3, Amazon DynamoDB, Amazon Cognito, and AWS Amplify Console WorkShop webapp.serverlessworkshops.io

Robotics

RoboMaker

Robomaker Workshops github.com

Alexa

AWS & Alexa Workshop Site alexaworkshop.com

AWS & Alexa Workshop Repository github.com

Voice Robotics Workshop voiceroboticsworkshop.com

Search

Amazon Elasticsearch Service

re:Invent 2019 公表コンテンツ

re:Invent Elasticsearch Workshops Site reinvent.aesworkshops.com

AI

SageMaker

re:Invent 2019 公表コンテンツ

AIM362 - Build, train & debug, and deploy & monitor with Amazon SageMaker github.com

AIM361 - Hyperparameter Optimization and AutoML gitlab.com

Amazon SageMaker Autopilot – Automatically Create High-Quality Machine Learning Models With Full Control And Visibility Blog aws.amazon.com

AIM403 - Deep learning with Apache MXNet github.com

AWS DeepComposer

re:Invent 2019 公表コンテンツ

AWS DeepComposer workshop github.com

DeepRacer

DeepRacer workshop content github.com

DeepLens

re:Invent 2019 公表コンテンツ

AWS DeepLens Workshops github.com

Sumerian

Sumerian AR Webapp Workshop Site workshop-sumerian-ar-webapp.s3-website-eu-west-1.amazonaws.com

Blockchain

Amazon Managed Blockchain

re:Invent 2019 公表コンテンツ

Build an interbank transfer solution using Hyperledger Fabric on Amazon Managed Blockchain github.com

IoT

FreeRTOS, AWS IoT

Connected Drink Dispenser Workshop github.com

re:Invent 2019 公表コンテンツ

IOT335 - Implementing multi-region AWS IoT github.com

IOT405 - Performing Analytics at the Edge with AWS IoT Greengrass github.com

Others

re:Invent 2019 公表コンテンツ

AWS Builder’s Fair Project Sample Code and Documentation github.com

AWS re:Invent 2019 Trivia Game アーキテクチャを学ぶ

ワークショップではないですが,上記のイベント用サイトとそのコードが公開されているため re:Invent 2019 コンテンツとして載せます.

AWS re:Invent 2019 Trivia Game Site www.reinvent-trivia.com

GitHub Repository github.com

まとめ

リンクを紹介だけでしたがたくさんのコンテンツがありました.特に,AI とServerless のコンテンツの多さにこれらの領域の注力しているのが感じられます.個人的には Container,Database,AI,Management Tools が気になるので触ってみたいですね.この記事で紹介したものが年末年始の勉強の一助になれば嬉しいです.

関連記事

re:Invent 2019 関連の記事としてこちらもぜひ! sadayoshi-tada.hatenablog.com

2019年の振り返りと2020年の抱負

タダです。

2019年も今日で終わりなので,今年の振り返りと来年の抱負を書きたいと思います.

目標の振り返り

まずは,昨年末に立てた目標を振り返ってみます.5つ中2つ達成した状況でした.未達の目標は来年の目標で挑戦するよう試みていくようにしていきます.

sadayoshi-tada.hatenablog.com

No. 目標概要 アクション 結果
1 継続的アウトプットとの継続 週に1本以上の記事を継続 達成
2 読み手を意識するアウトプット はてブ総数や記事シェアなど気にする 達成
3 今年手を広げた新しい技術の深堀 今年手を広げたのはやりたい領域なので引き続き実践力をつけていければと思います。
・Docker / Kubernetes の使い方、インフラの知識の理解を深める、普段使いにする
・CloudFormation, Ansible, Terraformの勉強継続と、実戦投入する
ビッグデータ機械学習等のデータ分析は机上の勉強だけでなく Kaggle や SIGNATE といったコンペに参加する
・CI/CD のツールを使ってみて経験を積む
2/4達成
4 自分の武器を1つ作る Python を使ったデータ分析のプロジェクトに自分を入れてもらえるようにする。
・Web サービスのポートフォリオを最低1つ作る。
1/2 達成
5 セキュリティ、データベース領域が弱いため弱点強化 専門書を購入して資格試験やコンペなどで実力を確認 未達

ブログの振り返り

ブログは何と言ってもカックさん( id:kakku22) のブログメンタリングを今年のはじめに受け始めてから状況が変わりました.ブログを書いてフィードバックをもらって改善するサイクルが回ってブログや SNS での反応が変わっていったのを実感しました.刺激的かつ濃厚な3ヶ月だったなと感じます.ブログを力を入れ始めて人との出会いも増えたし,ブログ書いている人(特に AWS のブログ)って認識してもらえるようになりました.自分が継続的なアウトプットをすることで自分の実力を鍛えていき,周りの人からも認識してもらえるようになれたら初だったので嬉しかったし,RPG のようなレベル上げしているようで自分に合っていると思います.今後もコツコツ続けていきます.

定期的なアウトプットの継続

継続的アウトプット」は継続できており,ブログの継続期間が104週と続けてこれています.ルーティン化されたのでブログ書かないともやもやする身体にはなりましたw

ホッテントリの増加

昨年に比べてホッテントリの数も増えたのですが,メンタリング中に100ブクマ,メンタリング後に200ブクマを超える記事が出たのが一番の成果ですね.それだけ求められる記事をかけたと思い自信になりました.

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

b.hatena.ne.jp

Twitter のフォロワーと読者数の増加

Twitter のフォロワーも年間で167人増え,はてなブログの読者数も年間で35人増えました.ホッテントリと同じで興味を持ってもらえる方が増えて本当に嬉しかったです.

課題

一方で年間を通じてブログの PV 数が平均2,500ほどでした.読み手を意識した記事を作るときにはてブ数や SNS の反応を主に気にしていたのですが,その反応がなくても見られる記事,見続けられる記事にしていくために自分のブログの PV 数も意識が必要だと改めて感じました.そのために,ネタや中身もブログメンタリングで受けた指摘振り返ったり他の人がどんな書き方をしているかも研究していきます.

f:id:sadayoshi_tada:20191231003959p:plain

来年の抱負

2020年の抱負は以下の通りです。来年はデータ分析,クラウドネイティブ(まずはコンテナ)に注力していき,そのアウトプットをブログにしていきます.

No. 目標概要 アクション 結果
1 読み手を意識するアウトプット ホッテントリ入りする記事をを作る(2019年はホッテントリ数が16記事なので20記事を目指す)
月間のPV数を平均3,000超えを目指す
-
2 データ分析コンペに1人で参加できるようになる Kaggleのコンペに一人で参戦して1人でモデルや特徴量を作っていけるようになる
ゆくゆくはメダルを取れるようになる
-
3 クラウドネィティブなアーキテクチャ設計と実装,運用に関する理解を深める 柔軟かつスピーディで拡張性のあるクラウドアーキテクチャを考えて,運用していくための実践力を養う
特にコンテナ技術はクラウドだけでなく,データ分析の文脈でも登場する技術のため理解し扱えるようになりたい
-
4 データベース領域の強化 データベースに対する苦手意識をなくすために資格試験を取り実力を形に残していく -

まとめ

2020年も現状維持じゃなくて成長を意識して行動していきます.