パパエンジニアのアウトプット帳

30歳に突入した1児のパパエンジニアのブログ

マネージャーとして自分の役割を考える

現在の会社で初めてマネージャーという役割になったが、役割の範囲が分からないので悶々としていたら下記のツイートを見つけました。

これを踏まえて自分の役割の範囲を考えるととりあえずは、下記となりそう。

  • 当該部門ののプロジェクトマネジメント
    • デリバリー
    • 品質管理
    • コスト管理
  • 当該部門のプロダクトマネージメント
    • 要件定義
  • 当該部門のピープルマネージメント
    • 教育・育成
    • メンター、キャリア相談
  • 当該部門の技術選定・技術的意思決定
  • 当該部門の開発関連ツール導入の意思決定


こうやって文書化されると、自分のやる範囲が見えてきて優先順位もつけられるようになるので、かなり霧が晴れた感じになったように思う。


それにしても、世の初心者マネージャーはどうやって勉強してるんだろう。。。

terraformでaws_rds_clusterのcreateに2hかかるとtimeoutする

スナップショットからの復元の場合はクラスター作成に時間がかかるのだが、terraformでやってると2hでポーリングがタイムアウトするという。

aws_rds_cluster.aurora57: Error waiting for RDS Cluster state to be "available": timeout while waiting for state to become 'available' (last state: 'creating', timeout: 2h0m0s)

default: 120 minなのでスナップショットのサイズが大きい場合は長くしておいたほうがいいかも。

www.terraform.io

Serverless Framework for Ruby - 複数関数作成編

下記の続き。今回は複数のファンクションを定義してみようと思う。

masaru-tech.hateblo.jp


serverless.ymlの書き方からなんとなく複数ファンクションの書き方は予想がつく。
handerにファイル名.アクション名だろうと。

$ vi serverless.yml
---
 functions:
   hello:
     handler: handler.hello
+    events:
+      - http:
+          path: hello
+          method: get
+  goodby:
+    handler: handler.goodby
+  fuga:
+    handler: hoge.fuga

これで1ファイルにまとめることもファイルを分けることもできる。


しかし・・・


lambdaのファンクションは複数出来ているが、コードサイズが全て同じでしかもそれなりにある。。。
S3にzipがあるのでダウンロードして中をみてみると。。。

$ ls
./            ../       handler.rb    hoge.rb       node_modules/ package.json  yarn.lock


なるほど。全てを1つのzipにまとめてそれをlambdaのhandlerの指定を変えてるんですね。。。
しかも、node_modulesとかpackage.jsonとかはrubyだと要らない。。。

lambdaでデプロイパッケージの容量制限があるのでこれは分けて欲しいなー。

docs.aws.amazon.com

Auroraのスナップショット復元時間はどれくらいかかるのだろうか?

ちょっとスナップショットからAuroraを復元する必要があったので、試しにやってみたら時間がかかった。

なんでこんなに時間かかるのだろう?と調べているとまさにドンピシャな実験をされている方がいた(圧倒的感謝)

blog.father.gedow.net


だいたいこの検証の通りっぽいが、時間によるものなのかスナップショットをとった時のインスタンスタイプも関係あるのかstaging/productionのスナップショットの復元時間がかなり違う。

db.t2.smallから取得したスナップショット48GiB(staging)とdb.r3.largeから取得したスナップショット73GiB(production)から新しくdb.r3.largeのインスタンスを復元しようとしたら、staging:約1.5h/production:約1hと本番の方が早かった。
同じインスタンスタイプだから容量しか影響しないと思っていたが、スナップショットの元となったインスタイプの違いも影響するのだろうか?
不思議だ。

TerraformでAurora2を立てる時のengine、engine_versionの指定

TerraformでAurora2のRDSを立てようと思ったらengine_versionになに指定したらいいか分からなかったのでメモ。


create-db-cluster — AWS CLI 1.16.103 Command Reference

--engine (string)

The name of the database engine to be used for this DB cluster. Valid Values: aurora (for MySQL 5.6-compatible Aurora), aurora-mysql (for MySQL 5.7-compatible Aurora), and aurora-postgresql

--engine-version (string)

The version number of the database engine to use.

Aurora MySQL

Example: 5.6.10a , 5.7.12

Aurora PostgreSQL

Example: 9.6.3

Aurora MySQL データベースエンジンの更新 (2018-02-06) - Amazon Aurora

・Aurora MySQL 2.x のエンジン名は aurora-mysql で、Aurora MySQL 1.x のエンジン名は引き続き aurora です。

・Aurora MySQL 2.x のエンジンのバージョンは 5.7.12 で、Aurora MySQL 1.x のエンジンのバージョンは引き続き 5.6.10ann です。

このドキュメントをみた感じだと、engine = "aurora-mysql"、engine_version = "7.5.12"だとなるが、これだとAurora 2.xではなくAurora MySQL 5.7.12が作成される。
engine_version = "2.03.3"とかにしてもダメで、結局一度5.7.12で作成後2.03.3にコンソールで変更してTerraformで見てみるとengine_version = "5.7.mysql_aurora.2.03.3"という。(分かるわけがない…)


なので、Terraformでのtfファイルは下記のように設定するとAurora MySQL 2.x系を作ることができます。

resource "aws_rds_cluster" "aurora57" {
  ・・・
  engine                              = "aurora-mysql"
  engine_version                      = "5.7.mysql_aurora.2.03.3"
  ・・・
}

Serverless Framework for Rubyをやってみる

AWS LambdaにRubyがきたので、Lambdaをより使う意欲が出てきた。(今まではpythonがほとんどでたまにnodejsで書いていた)
そこで、前からLambdaやるならServerless/Apexのどちらかかなーと思っていたのでまずはServerless Frameworkを試してみる。

serverlessのインストール

まずは、serverlessのインストールから。

Railsで染み付いたのかglobalにインストールするのがなんか嫌なので、プロジェクト直下にインストールします。
あと特にこだわり無いですがyarnが入っているのでnpmではなくyarnでやります。

$ mkdir sample-serverless
$ cd sample-serverless
$ yarn init
$ yarn add serverless

package.jsonにscriptsを定義

このままだとservelessコマンドが実行できないのでpackage.jsonにscriptsを追加します。

$ vi package.json
---
{
  "name": "sample-serverless",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "serverless": "serverless"
  },
  "dependencies": {
    "serverless": "^1.36.3"
  }
}

Rubyのテンプレートからサンプルプロジェクトを作成

準備が整ったので、Rubyのテンプレートからサンプルプロジェクトを作成します。

$ yarn run serverless create --template aws-ruby                 
yarn run v1.7.0
$ serverless create --template aws-ruby
Serverless: Generating boilerplate...
 _______                             __
|   _   .-----.----.--.--.-----.----|  .-----.-----.-----.
|   |___|  -__|   _|  |  |  -__|   _|  |  -__|__ --|__ --|
|____   |_____|__|  \___/|_____|__| |__|_____|_____|_____|
|   |   |             The Serverless Application Framework
|       |                           serverless.com, v1.36.3
 -------'

Serverless: Successfully generated boilerplate for template: "aws-ruby"
Serverless: NOTE: Please update the "service" property in serverless.yml with your service name
✨  Done in 1.87s.

デプロイ前の準備

あとは、serverless deployコマンドを打つだけ!と言いたいところですが、このままではawsへデプロイできません。
deployコマンドを実行できるようにするには、awsのcredentialsを設定する必要があります。
※公式のドキュメント参照 Serverless Framework - AWS Lambda Guide - Credentials


私の環境はすでにaws cliをインストールしているので、下記のコマンドを利用してプロファイルを新規に作成しそれを利用します。

$ aws configure --profile serverless_development
あとは聞かれる通りにaccess keyやsercret keyの情報を入力していきます。

プロファイルが作成できたら、serverless.ymlに追加します。

$ vi serverless.yml
---
※コメント省いてます

service: sample-serverless

provider:
  name: aws
  runtime: ruby2.5
  profile: serverless_development  # aws configure --profile xxxで作成したやつ
  region: ap-northeast-1
  stage: dev

functions:
  hello:
    handler: handler.hello

これで準備は完了です。

デプロイ!

それでは、serverless deployを実行です。

$ yarn run serverless deploy -v
yarn run v1.7.0
$ serverless deploy -v
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
CloudFormation - CREATE_IN_PROGRESS - AWS::CloudFormation::Stack - sample-serverless-dev
CloudFormation - CREATE_IN_PROGRESS - AWS::S3::Bucket - ServerlessDeploymentBucket
CloudFormation - CREATE_IN_PROGRESS - AWS::S3::Bucket - ServerlessDeploymentBucket
CloudFormation - CREATE_COMPLETE - AWS::S3::Bucket - ServerlessDeploymentBucket
CloudFormation - CREATE_COMPLETE - AWS::CloudFormation::Stack - sample-serverless-dev
Serverless: Stack create finished...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service .zip file to S3 (15.08 MB)...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
CloudFormation - UPDATE_IN_PROGRESS - AWS::CloudFormation::Stack - sample-serverless-dev
CloudFormation - CREATE_IN_PROGRESS - AWS::Logs::LogGroup - HelloLogGroup
CloudFormation - CREATE_IN_PROGRESS - AWS::IAM::Role - IamRoleLambdaExecution
CloudFormation - CREATE_IN_PROGRESS - AWS::Logs::LogGroup - HelloLogGroup
CloudFormation - CREATE_COMPLETE - AWS::Logs::LogGroup - HelloLogGroup
CloudFormation - CREATE_IN_PROGRESS - AWS::IAM::Role - IamRoleLambdaExecution
CloudFormation - CREATE_COMPLETE - AWS::IAM::Role - IamRoleLambdaExecution
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Function - HelloLambdaFunction
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Function - HelloLambdaFunction
CloudFormation - CREATE_COMPLETE - AWS::Lambda::Function - HelloLambdaFunction
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Version - HelloLambdaVersionNxhCrecCdNcXpcb9fj6uPopa8NgeMn3M05zFw92CIUQ
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Version - HelloLambdaVersionNxhCrecCdNcXpcb9fj6uPopa8NgeMn3M05zFw92CIUQ
CloudFormation - CREATE_COMPLETE - AWS::Lambda::Version - HelloLambdaVersionNxhCrecCdNcXpcb9fj6uPopa8NgeMn3M05zFw92CIUQ
CloudFormation - UPDATE_COMPLETE_CLEANUP_IN_PROGRESS - AWS::CloudFormation::Stack - sample-serverless-dev
CloudFormation - UPDATE_COMPLETE - AWS::CloudFormation::Stack - sample-serverless-dev
Serverless: Stack update finished...
Service Information
service: sample-serverless
stage: dev
region: ap-northeast-1
stack: sample-serverless-dev
api keys:
  None
endpoints:
  None
functions:
  hello: sample-serverless-dev-hello
layers:
  None

Stack Outputs
HelloLambdaFunctionQualifiedArn: arn:aws:lambda:ap-northeast-1:123456789012:function:sample-serverless-dev-hello:1
ServerlessDeploymentBucketName: sample-serverless-dev-serverlessdeploymentbucket-xxxxxxxxxxxx

✨  Done in 84.97s.

デプロイが完了しました。
serverless deployを実行すると、Lambdaのファンクションを作成するだけではなくS3のバケットやIAMロール、CloudwatchのロググループなどもCloudformationを利用して作成するようです。

デプロイしたLambdaファンクションを実行

デプロイしたLambdaファンクションの実行は、serverless invokeで行います。

$  yarn run serverless invoke --function hello 
yarn run v1.7.0
$ serverless invoke --function hello
{
    "statusCode": 200,
    "body": "\"Go Serverless v1.0! Your function executed successfully!\""
}
✨  Done in 2.34s.

テンプレートのhelloメソッドそのままですが、ちゃんと実行されているようです。 ※Cloudwatchのログを確認するとログが出力されているはずです。

httpからアクセスできるようにする

現状はlambda関数をそのまま呼び出しているだけなので、httpアクセスで呼べるようにしてみます。
下記のようにeventsのhttpを設定することでhttpアクセスが可能になります。

$ vi serverless.yml
---
functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: hello
          method: get

これでデプロイするこ今度は新たにAPI Gatewayが作成され、API Gatewayを利用してhttpでアクセスできます。

$ curl deploy後に表示されているServiceEndpoint/hello
"Go Serverless v1.0! Your function executed successfully!"

ブラウザからアクセスしても同様の文字列が表示されるのでバッチリです。


とりあえずのチュートリアルレベルのことをやってみただけですが、Serverlessを利用してAWSヘデプロイできました。
ちょうど色々なツールをwebhookで連携したかったので、Serverlessを色々触ってみようと思います。

また、Apexも気になっているのでまた別の機会に触ってみようと思います。

has_oneのbuildはhas_manyと違う

Railsでhas_many :commentsみないな時にbuildするときは@blog.comments.buildだけど、has_oneの場合は.buildはnilエラーになる。

has_oneの場合はbuild_xxxというメソッドがあるので、そちらを使うと言うことを今頃になって知った。

class Blog
  has_one :star
end

@blog = Blog.new
# @blog.star.build →nilエラーになる
@blog.build_star