Goalist Developers Blog

Finding File Paths in Your AWS S3 Database

Hello this is Kim from Goalist.

Today I would like to explain an automation I made using AWS(Amazon Web Service) S3 and python. It is easy to access your files when you don't have too much data in your S3 database.

However, if you have a big data or if you need to find a specific data you can't spend your time looking through all your folders to find files you need.

So this automation helps you look up all the paths for the files you need.

Getting started

In order to gain access to your AWS S3 database, first you need to set your credentials so that you can access your AWS S3 database with python.

In your terminal you can simple install the AWS CLI(Command Line Interface) by simply typing:

aws configure

with this, it will ask you to input AWS Access Key Id, AWS Secret Access Key, Default region name, Default output format like the following

AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: 
Default output format [None]: 

However, you can change this in the credentials file in your .aws folder.

Once you have setup your AWS CLI, you can now proceed gaining access to your AWS Bucket with boto3 like the following.

AWS_BUCKET_NAME = 'your bucket name'
session = boto3.session.Session(profile_name='your profile name')
s3 = session.client('s3')

Searching for files

After you gain access to your AWS with boto3, it is time to list all the objects in your bucket.

def list_objects(key_prefix):
    res = s3.list_objects_v2(Bucket='oz-data', Prefix=key_prefix)
    if 'Contents' in res:
        return list(map(lambda x: x['Key'], res['Contents']))

like the above I used the list_objects_v2 method to get my list of all the objects in my bucket.

Next, to find the file path you need, you can write a code that performs as a filter. In my case, I needed my files to include a certain string or have certain dates in between.

Finally, after getting all the files I need, I add them up to a csv file so I can check the path and download the files I need.

Wrap up

That's all from my automation and for this post. I'll leave a link for boto3 documentation and AWS CLI so you can check all the cool commands that you can use.

I'm Kim from Goalist and I will see you soon in another post. Happy Coding :)

Links Boto3 Documentation: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3.html

AWS CLI Documentation: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html

serverlessとstep functionを利用した情報補完処理を作りました

お久しぶりです、ゴーリストのチナパです!

この度、ゴーリストで「自動化100」というテーマでエンジニア達がみんな合わせて様々プロセスを自動化しようとしています。(年内で100個のチャレンジです!)

大きな図から始めさせてください。 今年、ゴーリストのHR事業部で「プロダクトバリュー最大化」を目指し、提供しているデータをより価値高くしようとしています。長い話を簡潔にいうと、会社名からその会社のお電話番号を調べるため、様々なクローラーを利用して、プロセスを作成しました。ただし、これは現在一個ずつコマンドを叩いて実行しなきゃいけないので、最適ではありません。その現状から、AWSのstep functionを利用して、設定ファイルにしたがって、最初から最後まで勝手に動くようにしました。

f:id:c-pattamada:20200811114644p:plain
step functions!

細かい課題設定でいうと、いくつかのFargate/lambdaコンテナーを設定通り動くようにしたいです。(そもそもFargateでどうやってクローラー実行できるのとか気になる方はこちらを参考にしてください)。

最終形態はこちらです。

成功する時:

f:id:c-pattamada:20200811111317p:plain

そしてうまく行かない時も、静かに死ぬではなく、通知がきます。

f:id:c-pattamada:20200811111415p:plain

どうやってstep functionを利用できた?

一つのブログでとても抑えきれなさそうですので、いくつかの便利なところを紹介します。 step function を設定するためのserverless.yml の一部をサンプルとして用意しました。4つのとても便利なところをハイライトしました。

stepFunctions:
  stateMachines:
    addTelephoneFromCompanyName:
      definition:
        Comment: "Will do cool things."
        StartAt: MyTask
        States:
          SuccessNotification:
            Type: Task
            Resource: "arn:aws:lambda:#{AWS::Region}:#{AWS::AccountId}:function:${self:service}-${opt:stage}-successNotification"
            Parameters:
              "Payload.$": "$"
            End: True
          MyTask:
            Type: Task
            Resource: "arn:aws:states:::ecs:runTask.waitForTaskToken" # ➀
            Next: SuccessNotification
            ResultPath: "$.my_output"  # ②
            Catch:                                  #③
              - ErrorEquals:
                  - States.ALL
                Next: FailureNotification  # 失敗した際のstepを適当に懐ける
                ResultPath: $.Error
            HeartbeatSeconds: 300
            Parameters:
              LaunchType: FARGATE
              Cluster: !GetAtt FargateECSCluster.Arn
              TaskDefinition: !Ref FargateECSTaskDefinition
              NetworkConfiguration:
                AwsvpcConfiguration:
                  AssignPublicIp: ENABLED
                  SecurityGroups:
                    - !Ref FargateSG
                  Subnets:
                    - !Ref FargateSubnet
              Overrides:
                ContainerOverrides:
                  - Name: "hp_crawler_container"
                    Command:
                      - "python"
                      - "run.py"
                    Environment:  # ④
                      - Name: "TASK_TOKEN_ENV_VARIABLE"
                        "Value.$": "$$.Task.Token"
                      - Name: "FEED_BUCKET_NAME"
                        Value: "company-hp-crawler-serverless"
                      - Name: "SETTINGS_FILE"
                        "Value.$": "$.settings_file"
                      - Name: "INPUT_FILE"
                        "Value.$": "$.input_file"

上記のようなサンプルで➀から④のところが肝だなと思いました。

➀ waitForToken設定

ecsをが実行し、そのあとで、次のステップを行うため、waitForTaskTokenのやり方でやっていました。ecs側でsend_task_successを呼ぶ必要があります

② ResultPath

ResultPath: "$.my_output"  # ②

step functions のResultPathを利用したら、stateのアウトプットがそのパスのしたで出力されます。そして、stateのインプットを次のstateのも使う必要があれば、できます。 上記のinputが

{"my_input": "hi"}

であれば、アウトプットがこうなります:

{"my_input": "hi", "my_output": "..."}

ResultPathを利用しないと、インプットが上書きされます。

③ Catch:

何かの状況でstateが失敗した時、別処理を行うために使います。 私のお経験で3つの利用で失敗することがあります ・まずは、Taskをかいしする前の問題: 例ecsの定義に問題がある場合(存在しないなど) こちらはAmazon側でかってに認識してエラーが出るので、CatchがあればOKです。 ・ecsの中の処理が失敗する、や自分のコードにエラーが出る。 こちらはコードの中でtry・catch処理を行い、エラーが出る場合、send_task_failure を使ってます。 ・クローラーの場合、エラーが出ずにIOに立ち止まったり、他のトラブルもたまにありますので、定期的にsend_task_heartbeat をよび、state definitionで"HeartbeatSeconds: 300"でも設定すると、タイムアウトエラー的に機能します。

上記のどれかのやり方でエラーが出る場合、Catch処理を実行し、失敗の通知を送るように設定できてます。

④ ecsの環境変数

ecsにstateから変数を渡す時はecsの環境変数を使うとうまく行きました。InputPathを利用し、設定できます。つまり、 inputが

{"my_input": "hi"}

"$.my_input" を設定したら、環境変数に"hi"という文字列を設定できます。

まとめ

ほぼまる1ヶ月かかった自動化でしたので、具体的な説明はブログでまとめづらかったですが、上記の4つのtipsを使うと、 ecs + step functionでの開発をしようとしている方が少しでも楽になるかなと思ってます!

これからも自動化の話題いっぱい投稿するつもりなので、よろしくお願いします!

Serverless Framework,CircleCIでの更新の自動化

どうも,エンジニアのナカノです.

今回は,Serverless Framework,CircleCIでの更新の自動化の内容をご紹介致します.

このお話は,前回の以下の記事の続編となります.主に,CI/CDの話です.

developers.goalist.co.jp

目 次
  • 背景
  • 作り方
  • 所感



背景

テスト,ビルド,デプロイの手順は,EC2の自動管理の開発の際に作っていました.

ただ,手動実行するのが面倒なのと,更新履歴を管理したいというのがありました.

また,CI/CDを作ってしまえば,ローカルでの準備が最低限度の形で済みます.

以上より,インフラと関数パッケージの更新の自動化を行うことに決めました.



作り方

インフラの作成/更新はServerless Frameworkで行い,CI/CDツールはCircleCIにしました.

f:id:r-nakano:20200831193353j:plain


Gitプロジェクトの構成は次の通りです.CI/CDの処理はSHファイルにまとめる様にしています.

ec2-serverless-manager
├── .circleci
│   └── config.yml       # CircleCIの設定ファイル
├── .gitignore
├── README.md
├── ci-package
│   ├── Dockerfile       # ビルドしたイメージはECRで管理している
│   └── bin
│       ├── deploy.sh    # パッケージのビルド、インフラやパッケージのデプロイ
│       └── validate.sh  # モジュールのインストール、Goソースのエラーチェック
├── go.mod
├── main.go
├── pkg
│   ├── aws-ec2.go
│   ├── aws-ssm.go
│   └── chatwork.go
└── serverless.yml       # Serverless Frameworkの設定ファイル


Dockerfileは,golangのイメージをベースとして,以下の様に作成しました.

FROM golang:1.15.0

ENV NODE_VERSION=12 \
    SLS_VERSION=1.79.0

RUN apt-get -q -y update && \
    curl -SL https://deb.nodesource.com/setup_${NODE_VERSION}.x | bash && \
    apt-get -q -y install -y nodejs && \
    npm install -g serverless@${SLS_VERSION}


CircleCIで実行するシェルスクリプトは,それぞれ次の様に実装しました.

# ci-package/bin/validate.sh
#!/bin/bash


# Params
set -eux
script_dir=`(cd $(dirname $0); pwd)`


# Execution
cd ${script_dir}/../../
go install
go test -race -v ./...
# ci-package/bin/deploy.sh
#!/bin/bash


# Params
set -eux
script_dir=`(cd $(dirname $0); pwd)`


# Execution
cd ${script_dir}/../../
GOOS=linux go build main.go
sls deploy -v


また,Serverless Frameworkの設定ファイルserverless.ymlの中身は,次の様な感じです.

service: ec2-serverless-manager

frameworkVersion: '>=1.28.0 <2.0.0'

configValidationMode: warn

provider:
  name: aws
  runtime: go1.x
  stage: ${opt:stage, 'dev'}
  region: ${env:AWS_DEFAULT_REGION}
  stackName: ec2-serverless-manager-cf-stack
  apiName: ec2-serverless-manager-rest-api
  deploymentPrefix: artifacts
  deploymentBucket:
    name: xxxxxxxx.xxxxxxxx.xxxxxxxx
    maxPreviousDeploymentArtifacts: 3
  iamManagedPolicies:
    - 'arn:aws:iam::aws:policy/AmazonEC2FullAccess'
    - 'arn:aws:iam::aws:policy/AmazonS3FullAccess'
    - 'arn:aws:iam::aws:policy/CloudWatchLogsFullAccess'
  iamRoleStatements:
    - Effect: Allow
      Action:
        - 'ssm:Get*'
        - 'kms:Encrypt'
        - 'kms:Decrypt'
        - 'kms:ReEncrypt*'
        - 'kms:GenerateDataKey*'
        - 'kms:DescribeKey'
      Resource: '*'
  logs:
    restApi:
      accessLogging: true
      format: 'requestId: $context.requestId'
      executionLogging: true
      level: INFO
      fullExecutionData: true
      roleManagedExternally: true

functions:
  ec2Manager:
    handler: main
    name: ec2-serverless-manager-lambda-function
    description: Lambda function of EC2 serverless management system
    memorySize: 128
    runtime: go1.x
    timeout: 300
    environment:
      CW_ROOM_ID: xxxxxxxx
    tags:
      Name: ec2-serverless-manager-lambda-function
    events:
      - http:
          path: /
          method: POST


更に,**CircleCIの設定ファイル.circleci/config.ymlの作成は,次の記事を参考に作りました.

medium.com

GitHubとの連携は,次の様なブランチとタグの使い分けの方法で実施する様に対応しました.

  • masterブランチが更新された時は,Goソースのエラーチェックのみを実施する

  • タグが作成された時は,パッケージのビルド,インフラやパッケージのデプロイを行う



所感

Serverless Frameworkは初めて利用しました.やはり,サーバレスインフラの構築に合ってます.

インフラの規模としては,恐らく大きく無いものを作るのに適していそうな気がしますね.

小さく無いインフラを細かく設計して作る等だと,Terraformの方が使い勝手が良さそうです.

何はともあれ,以前から気になってたIaCツールを,今回の自動化の対応で試せて良かったです.

ChatworkからのEC2インスタンスの管理の自動化

どうも,エンジニアのナカノです.

今回は,Chatwork経由でのEC2インスタンスの管理の自動化の内容をご紹介致します.

過去に使ったことの無かった技術を,今回の開発で採用してみることにしました.

目 次
  • 背景
  • 作り方
  • 所感



背景

現在,クローリングデータの運用/納品チームは,EC2インスタンスの管理を次の様に行ってます.

  • 起動の場合:Chatworkのタスクを作成して、EC2の管理コンソールから起動を行う

  • 停止の場合:EC2の管理コンソールから停止を行い,Chatworkタスクを完了にする

これで運用すれば,Chatworkタスクの状態を見て,EC2インスタンスのstateを判断出来ます.

しかし,マニュアルで運用しており,抜け漏れがあり得ますし,何より面倒さがあります.

そこで,この一連のプロセスを自動化させて,同チームの業務改善を進めようと考えました.



作り方

自動化において,インフラはAPI GatewayLambdaといったサーバレス構成を採用しました.

この構成とChatwork Webhookの連携を利用して,イベント駆動な仕組みになる様にしました.

developer.chatwork.com

f:id:r-nakano:20200831160438j:plain


また,EC2インスタンスの自動管理の仕組みの,Gitプロジェクトの構成は次の様になります.

LambdaのハンドラーはGoで開発しました.これは,Goを使ってみたかったからです!

golang.org

ec2-serverless-manager
├── .circleci
│   └── config.yml
├── .gitignore
├── README.md
├── ci-package
│   ├── Dockerfile
│   └── bin
│       ├── deploy.sh
│       └── validate.sh
├── go.mod
├── main.go
├── pkg                  # ローカルパッケージ
│   ├── aws-ec2.go       # EC2インスタンスの検索,起動,停止を行う
│   ├── aws-ssm.go       # SSMパラメータの値を取得する
│   └── chatwork.go      # Chatworkへのメッセージ送信を行う
└── serverless.yml


Goのソースは,それぞれ次のようになります.ルールが少ないので実装が行い易いです.

各々のソースの実装は,次のリンク先のGitHubリポジトリの内容を参考にして行いました.

github.com

github.com

github.com

// main.go
package main

import (
    "encoding/json"
    "fmt"
    "strings"

    pkg "ec2-serverless-manager/pkg"

    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
)

type CwWebhookRequest struct {
    WebhookSettingID string `json:"webhook_setting_id"`
    WebhookEventType string `json:"webhook_event_type"`
    WebhookEventTime int    `json:"webhook_event_time"`
    WebhookEvent     struct {
        FromAccountID int    `json:"from_account_id"`
        ToAccountID   int    `json:"to_account_id"`
        RoomID        int    `json:"room_id"`
        MessageID     string `json:"message_id"`
        Body          string `json:"body"`
        SendTime      int    `json:"send_time"`
        UpdateTime    int    `json:"update_time"`
    } `json:"webhook_event"`
}

func main() {
    lambda.Start(Handle)
}

func Handle(request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    // Lambdaで実行させたいことを実装する
}
// pkg/aws-ec2.go
package pkg

import (
    "os"

    "github.com/aws/aws-sdk-go/aws"
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/ec2"
)

var region = os.Getenv("AWS_REGION")

var sess = session.Must(session.NewSession())
var svc = ec2.New(
    sess,
    aws.NewConfig().WithRegion(region),
)

func StartInstance(instanceId string) (*ec2.StartInstancesOutput, error) {
    input := &ec2.StartInstancesInput{
        InstanceIds: []*string{
            aws.String(instanceId),
        },
    }

    result, err := svc.StartInstances(input)
    return result, err
}

func StopInstance(instanceId string) (*ec2.StopInstancesOutput, error) {
    input := &ec2.StopInstancesInput{
        InstanceIds: []*string{
            aws.String(instanceId),
        },
    }

    result, err := svc.StopInstances(input)
    return result, err
}

func SearchInstance(instanceNm, state string) (*ec2.Instance, error) {
    input := &ec2.DescribeInstancesInput{
        Filters: []*ec2.Filter{
            {
                Name:   aws.String("tag:Name"),
                Values: []*string{aws.String(instanceNm)},
            },
            {
                Name:   aws.String("instance-state-name"),
                Values: []*string{aws.String(state)},
            },
        },
    }

    result, err := svc.DescribeInstances(input)

    if err != nil {
        return nil, err
    }

    var inst *ec2.Instance

    for _, reservation := range result.Reservations {
        for _, instance := range reservation.Instances {
            inst = instance
        }
    }

    return inst, err
}
// pkg/aws-ssm.go
package pkg

import (
    "os"

    "github.com/aws/aws-sdk-go/aws"
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/ssm"
)

func GetSsmPrm(key string) string {
    svc := ssm.New(session.New(), &aws.Config{
        Region: aws.String(os.Getenv("AWS_REGION")),
    })

    response, _ := svc.GetParameter(&ssm.GetParameterInput{
        Name:           aws.String(key),
        WithDecryption: aws.Bool(true),
    })

    return *response.Parameter.Value
}
// pkg/chatwork.go
package pkg

import (
    "bytes"
    "net/http"
    "os"
)

type CwApiConfig struct {
    token   string
    roomId  string
    baseUrl string
}

var cwApiConfig = CwApiConfig{
    token:   GetSsmPrm("/xxxxxxxx/cw_api_token"),
    roomId:  os.Getenv("CW_ROOM_ID"),
    baseUrl: "https://api.chatwork.com/v2/rooms/",
}

func PostMsg(msg string) {
    param := "body=" + msg
    apiUrl := cwApiConfig.baseUrl + cwApiConfig.roomId + "/messages"

    request, _ := http.NewRequest("POST", apiUrl, bytes.NewBufferString(param))
    request.Header.Set("Content-Type", "application/x-www-form-urlencoded")
    request.Header.Set("X-ChatWorkToken", cwApiConfig.token)

    response, _ := new(http.Client).Do(request)
    defer response.Body.Close()
}


以上を利用すると,Chatworkのルームでのタスクの作成/完了時に次が行われる様に出来ます.

  1. ChatworkのWebhookリクエストが,API Gatewayのエンドポイントに送られる

  2. API Gatewayは,Lambdaプロキシ統合を使って,Lambdaの呼び出しを実行する

  3. Lambdaは,リクエストの内容に基づいて,EC2インスタンスの有無を検索する

  4. もし該当のEC2インスタンスが存在すれば,それに対する起動/停止を実行する

  5. レスポンス用のメッセージをChatwork APIへ送り,特定のルームへ送信する



所感

Goには元々興味があったので,今回の自動化の対応でチャレンジすることが出来て良かったです!

一方で,初めて知る部分が色々とあったのもあり,次の点を何とかするのに地味に苦戦しました.

  • Go Modulesを利用したGoプロジェクトの構築

  • Webhook連携でのワークフローの無限ループの回避

最終的には何とかすることが出来て,これらの困難を乗り越えたことが良い経験になりました.

引き続き自動化の対応を進めていき,業務やシステムをより良い方向へ改善出来ればと思います.

次回は,このシステムのCI/CDの部分についてお話しようと思います.ご期待下さいませ~.

社内向けETLシステムのバッチ運用の自動化

どうも,エンジニアのナカノです.

今回は,社内システムのバッチ運用の自動化の内容をご紹介致します.

社内では,クローリングデータを加工するために,ETLシステムが存在します.

このシステムのEC2インスタンスのAMI運用を,今回は自動化しました.

目 次
  • 背景
  • 作り方
  • 所感



背景

今までのETLシステムはLAMPの様なステートフルなもので,サーバ自体の運用が必須でした.

また,同様なシステムが運用の都合で複数出てきたため,コスト面で問題になってきました.

そのため,コストダウンのために,API,バッチ,DBを全て切り分ける様に構成を見直しました.

以下の画像は,ETLシステムのサービスとCI/CDのインフラ構成図のサンプルです.

f:id:r-nakano:20200817164950j:plain f:id:r-nakano:20200817164954j:plain f:id:r-nakano:20200817164957j:plain

大半をステートレスな構成に変更することが出来たのですが,バッチサーバはそれが困難でした.

そのため,バッチサーバのAMIは既存のものをベースとして,構成管理の自動化を進めました.



作り方

色々と調べた結果,主に次の様な構成にしました.

  • GitHubと連携して,CircleCIをパイプラインとして使う

  • CodeBuildでPackerとAnsibleを実行し,AMIを作成する

CircleCIを選んだのは,パイプラインの設定が他のCI/CDサービスよりも細やかだからです.

他には,社内のCI/CDツールでこのサービスが使われているからというのもあります.

また,CodeBuildを利用したのは,CircleCIの無料プランの制限問題を回避するためです.

ビルドに時間がかかるため,CircleCIはあくまでGitHubとCodeBuildの間の仲介者と使っています.

circleci.com

docs.aws.amazon.com

www.packer.io

docs.ansible.com

dev.classmethod.jp


CircleCIからCodeBuildの連携は,CodeBuildに関するAWS CLIを使って行っています.

また,CodeBuildでのコンテナ上では,Packerのコマンドを実行する様にしています.

f:id:r-nakano:20200831151218j:plain

ところで,バッチサーバには管理や利用の有無が不明やプログラムが多く存在します.

これらは,AMIの新規作成や更新の際にS3から必要な分のみをプルする様にしました.

この辺りは弊社の技術負債の1つであり,どこかで何とかしたいところですね....



所感

開発と運用のそれぞれが楽になる案を探し,一旦の落としどころを見つけたという感じですね.

ステートレスな構成に出来ていないのが無念ですが,フローを何とか固められて良かったです.

あとは,Codeシリーズはとても便利ですが,慣れていないとハマり易い印象がありますね.

CodeBuildは,忘れた頃にはIAM関連の設定やネットワーク制約等でハマっってしまいますね....

引き続き,チームで自動化を進めていき,社内外の困りごとを技術で解決していきます.

EC2インスタンスのバックアップの自動化

どうも,エンジニアのナカノです.

今回は,EC2インスタンスのバックアップの自動化の内容をご紹介致します.

バックアップと言っても,今回は特にAMIの定期的な自動作成についてです.

目 次
  • 背景
  • 作り方
  • 所感



背景

社内では,開発/運用のライフサイクルの改善で,ステートレスなシステム構成を目指しています.

一方,古いシステムでステートを持つものが存在し,実際に現役で稼働しているものもあります.

特にこの様なシステムのバックアップの仕組みが整っておらず,これが技術負債となっていました.

今回は技術負債の解消も込めて,自動的なバックアップの設計/開発を進めることになりました.



作り方

構成

EC2インスタンスのバックアップの方法としては,AMIスナップショットの二種類があります.

スナップショットだと料金が発生するため,AMIの自動管理の仕組みを作ることになりました.

調べてみるとAWS Backupが利用出来そうで,今回はこれを使って仕組みを作ることにしました.

去年まではLambdaやCloudWatch Events等で構築する必要があったので,これは便利ですね!

docs.aws.amazon.com

f:id:r-nakano:20200817145335j:plain

セットアップ

以下では,主にAWS Backupの各種リソースの作り方をご紹介致します.


プランとルールの作成

AWSマネジメントコンソールにログインし,次にAWS Backupの管理画面を開きます.

管理画面内のマイアカウント > バックアッププランを開き,バックアッププランを作成のボタンを押します.

今回は新しいプランを立てるを選び,プランやルールの名前は画像の様な感じで設定しました.

f:id:r-nakano:20200817151029j:plain


ジョブのスケジュールは頻度を毎日とし,バックアップウィンドウはカスタム設定で行いました.

開始時間は午後5時(UTC)で,1時間以内に開始し,1日以内に完了する様に設定しました.

日本時間で言えば,毎日深夜2時から1時間以内にAMIが自動作成され,この作成が1日以内に終わるというルールです.

また,有効期限を2日としました.つまり,AMIが1日に1個作られて,2日でローテートされるということです.

f:id:r-nakano:20200817151035j:plain


その次にタグ設定を行い,プランを作成のボタンを押してバックアッププランを作成しました.

基本的には,これらの設定で事足りるかと思います.その他の設定は場合に応じて行う感じです.

f:id:r-nakano:20200817151043j:plain


リソースの割り当て

その後は,マイアカウント > バックアッププランで作成したプランの詳細画面を開きます.

詳細画面内のリソースを割り当てるのボタンを押し,プランとリソースの紐づけの設定を行います.

IAMロールはデフォルトを選びました.また,リソースを割り当てるの設定は次の様に行いました.

割り当てを複数行いたい場合は,割り当てを追加のボタンを押して同様な設定を行えばよいです.

  • 割り当て単位:リソースIDを選択

  • リソースタイプ:EC2を選択

  • インスタンスID:紐付けたいEC2インスタンスのIDを選択

f:id:r-nakano:20200817154056j:plain



所感

Amazon DLMもそうですが,1つのサービスでシステムを簡単に管理出来るのは素晴らしいですね!

AWSでは開発/運用をサポートするものがここ数年で続々と登場し,目を見張るものがあります.

こういったものがあると,工数をあまりかけずにライフサイクルの改善を進められるので良きです.

今後も技術のアップデートを見逃さない様にして,システム改善の最適化を都度に求めたいです.

近況報告と今後の発信について

f:id:r-nakano:20200817175530j:plain

お久し振りです.エンジニアのナカノです.

前回の記事の執筆から,2年と1カ月振りですかね.発信が滞ってしまっておりました.

執筆するのがかなり久々で,ちょっと緊張しています.笑

間が空き過ぎているので,まずは私の近況報告でもさせてください.

目 次
  • 近況報告
  • 今後の発信



近況報告

初配属後から2年間は,運用系のチームと開発系のチームを行き来していました.

現在は,技術戦略のチームで,システムの開発/運用/改善を行っております.

具体的には,大きな対応ですと,ここ数年では主に次の業務を対応させて頂きました.

受託開発案件の対応

  • 不動産関連の情報まとめサイトのインフラ開発

  • 外国人雇用の就労ビザの管理サービスのインフラ設計/開発

社内システムの新規,リニューアル対応

  • 問い合わせ基盤のインフラ/バックエンドの設計/開発

  • 人材業界向けのメディアサービスのインフラ設計/開発

  • 求人媒体用のクローラーシステムのインフラ設計/開発

  • ETLシステムのインフラ/バックエンドの設計/開発

  • 各種サービスの管理システムのインフラ設計/開発

他には,AWS周りや各種インフラの運用/改善等は,社内を横断してサポートしております.

ここ数年は引き続きエンジニアとして,以上の様な感じで活動しておりました.

以前の執筆時と比べて,実に色々な経験をさせて頂き,成長することが出来ました.



今後の発信

先月よりチームの指針の一つとして,自動化100というものが設けられました.

これは,マニュアル業務やシステムを自動化し,困り事や課題を解決しようというものです.

自動化の内容は,技術戦略のチームが一丸となって発信して参ります.

技術ブログに関しまして,ご興味がありましたらお読み頂けますと幸いです.