tshimba’s blog

このサイトの掲載内容は私自身の見解であり、所属する組織とは関係ありません

IBM Cloud Functions でカスタムのDocker imageを利用する

通常は用意されているランタイムを利用して Action を作成しますが、ランタイムが用意されていない言語や、インストールされていないライブラリを使用したい場合などはカスタムでDocker imageを用意する必要があります。現在用意されているランタイムは以下になります。

用意されているランタイムの場合はWebコンソールからデプロイできます。CLIの場合は以下のように指定します。

ibmcloud fn action create nodesample index.js --kind nodejs:10

ランタイムに用意されていない言語の利用

基本的には Docker Hub の ibmfunctions にランタイムのイメージがあります。

例えば ibmfunctions にない Java などを利用したい場合は、動作未検証ですが OpenWhisk のイメージを利用すれば動かせるのではないかと思います。

言語は用意されているが使用したいライブラリが入っていない場合

例えば Python のイメージには以下のライブラリがデフォルトで入っています。

$ docker run -d --name py37 ibmfunctions/action-python-v3.7
$ docker exec -it py37 sh
# pip list
Package                Version
---------------------- ---------
asn1crypto             0.24.0
attrs                  19.1.0
Automat                0.7.0
beautifulsoup4         4.8.0
botocore               1.12.211
cassandra-driver       3.18.0
certifi                2019.6.16
cffi                   1.12.3
chardet                3.0.4
Click                  7.0
cloudant               2.12.0
constantly             15.1.0
cryptography           2.7
cssselect              1.0.3
docutils               0.15.2
elasticsearch          6.3.1
etcd3                  0.10.0
Flask                  1.0.2
gevent                 1.4.0
greenlet               0.4.15
grpcio                 1.23.0
httplib2               0.13.0
hyperlink              19.0.0
ibm-cos-sdk            2.5.1
ibm-cos-sdk-core       2.5.2
ibm-cos-sdk-s3transfer 2.5.2
ibm-db                 3.0.1
ibmcloudsql            0.2.23
idna                   2.7
incremental            17.5.0
itsdangerous           1.1.0
Jinja2                 2.10.1
jmespath               0.9.4
kafka-python           1.4.6
lxml                   4.3.4
MarkupSafe             1.1.1
numpy                  1.16.4
pandas                 0.24.2
parsel                 1.5.1
pika                   1.0.1
Pillow                 6.0.0
pip                    19.2.2
protobuf               3.9.1
psycopg2               2.8.2
pyarrow                0.14.1
pyasn1                 0.4.5
pyasn1-modules         0.2.5
pycparser              2.19
PyDispatcher           2.0.5
PyHamcrest             1.9.0
pymongo                3.8.0
pyOpenSSL              19.0.0
python-dateutil        2.8.0
pytz                   2019.2
queuelib               1.5.0
redis                  3.2.1
requests               2.22.0
scikit-learn           0.20.3
scipy                  1.2.1
Scrapy                 1.6.0
service-identity       18.1.0
setuptools             41.1.0
simplejson             3.16.0
six                    1.12.0
soupsieve              1.9.3
tenacity               5.1.1
tornado                4.5.2
Twisted                19.7.0
urllib3                1.23
virtualenv             16.7.1
w3lib                  1.20.0
watson-developer-cloud 2.8.1
websocket-client       0.48.0
Werkzeug               0.15.5
wheel                  0.33.4
zope.interface         4.6.0

ここに含まれていないライブラリ(例:uuid)を利用したい場合は、以下の Dockerfile のように新しいイメージを作成し、Docker Hubなどパブリック(IBM Cloudからアクセス可能)なDockerレジストリへPushします。

FROM ibmfunctions/action-python-v3.7
RUN pip3 install uuid

サンプルアクションのデプロイ

パッケージの作成

任意ですが、パッケージを作成しておきます。ネームスペースのようなもので無くても問題ありません。

ic fn package create dev

Actions の作成

以下の main.py を用意して、先程Pushしたイメージを指定して Action を作成します。

ic fn action create dev/pysample tshimba/action-python-v3.7-custom main.py

デフォルトでは main がエントリーポイントになります

def main(params):
    return params

実行

以下のコマンドで実行し動作確認してみます。

ic fn action invoke dev/pysample -p helo world --result

Kubernetes Helm vs Operator

Kubernetes のパッケージ管理には Helm がありますが、一見似ている機能を持った Operator が最近注目を集めています。

例えば Red Hat OpenShift のバージョン 3 から 4 へのもっとも大きな変更点は Operator を前提としたアーキテクチャとなったことです。

以下の記事では、「Install, Upgrade, Management の方法を完全に再構築し、これにより高度な運用や Automation が実現できます。この達成に貢献したものといえば Operator 以上のものはありません」ということが述べられています。

OpenShift 4 is Kubernetes at its core and in this release we have completely re-architected how we install, upgrade and manage the platform, while also bringing advanced day 2 management and automation to the application services that run on the platform. These advancements are based on many new innovations in the Kubernetes ecosystem, none bigger than Kubernetes Operators.

blog.openshift.com

RHEL8からはAnsibleが完全にMainstreamになりAutomationの時代になりましたが、この流れを汲んでいるような印象です。

ちなみに、Operator で OpenShift 自体の Upgrade までできてしまいます。

nekop.github.io

Helm vs Operator

ところで Helm と Operator は何が違うのでしょうか。

以下の記事がわかりやすいためいくつか引用しながら説明していきます。

blog.openshift.com

Helm Charts are useful for addressing the complexities of installation and simple upgrades of particularly stateless applications like web apps. However when it comes to stateful applications there is more to the upgrade process than upgrading the application itself.

Webアプリのようなステートレスなアプリケーションのインストールやアップグレードには便利だが、ステートフルなアプリに関してはアプリ自体以外への変更も必要なためHelmでは不十分だということです。

Webアプリのコンテナは状態を持たないように、セッションなどの状態はデータベースへ保存するようにしますが、このデータベース自体はどうするかということですね。

If you have ever tried to upgrade a PostgreSQL database before, you know that upgrading PostgreSQL itself is the least of the problems. Dealing with the schema changes between database versions is where the main complexity lies, which often requires dumping the data and re-importing it back to the new version of the database in a controlled manner

例えばデータベースのバージョンによってSchemaに変更があるのであれば、一度データをdumpしてから後でimportしてあげる必要があります。これを Operator だとうまくやってくれるのでしょう。

実際に OperatorHub で PostgreSQLMySQL の Operator を見てみると、Rolling Upgrade や Scaling, Failover などの機能が提供されているものがあります。

operatorhub.io

ということで、Helm では Stateful なサービスの管理は難しいという背景から Operator がでてきたことがわかりました。

Operator 自体の説明はこちらの記事を参照してください。

tshimba.hatenablog.com

Kubernetes Operator の何が魅力なのか

Why Operator

Operator はある記事では Game-Changer であると言われています。

dzone.com

また Red Hat OpenShift 4 (Released May 1, 2019) の Version 3 からの最大の変更点は Operator を利用した Automation なのではないでしょうか。

OpenShift 4 is Kubernetes at its core and in this release we have completely re-architected how we install, upgrade and manage the platform, while also bringing advanced day 2 management and automation to the application services that run on the platform. These advancements are based on many new innovations in the Kubernetes ecosystem, none bigger than Kubernetes Operators.

Introducing Red Hat OpenShift 4: Kubernetes for the Enterprise – Red Hat OpenShift Blog

www.redhat.com

歴史

Operator は元々 CoreOS によって 2016 年に提唱されたコンセプトです。

【OSS】CoreOS、コンテナ管理コンセプト「Operators」発表---Dockerコンテナ管理フレームワーク「Kubernetes」向け、エンジニアやデベロッパーの固有の知識を自動化

2018 年 1 月に Red Hat が CoreOS を買収すると発表しました。この時 CoreOS は Operator や Quay を持っていました。

www.redhat.com

そして 2018 年 5 月に オープンソースのツールキットとして Operator Framework が発表されました。

RedHatのCoreOSがKubernetesアプリケーションを管理するツールキットを発表 | TechCrunch Japan

Operatorとは

Operator とは何でしょうか。CoreOS のサイトでは以下のように説明されています。

Conceptually, an Operator takes human operational knowledge and encodes it into software that is more easily packaged and shared with consumers.

概念的には、オペレータは人間の操作上の知識を取り入れ、それをより簡単にパッケージ化され消費者と共有されるソフトウェアにエンコードする。 by Google Translate

Introducing the Operator Framework: Building Apps on Kubernetes | CoreOS

これだけだとよくわからないので、まずはOperatorの仕組みから見ていきます。

Operatorの仕組み

Operator の仕組みを理解するためには、まずは Kubernetes の CRD と Custom Controller を知っておく必要があります。

CRD (Custom Resource Definition)

Kubernetes には Pod, Service, Deployment などのリソースがありますが、その他に独自リソースを定義することができます。

Custom Controller

Kubernetes にはリソースを管理する Controller があります。たとえば ReplicationController は指定されたレプリカ数のPodを起動した状態に保ちます。 Custom Controller はデフォルトのリソースや CRD に対してアクションを取る独自 Controller を定義することができます。

Custom Resources - Kubernetes

Operator

以下の記事の説明がとても分かりやすかったため引用します。

qiita.com

Operatorは Custom Resource と Costom Controller から成り立ちます。 Custom ResourceはKubernetes上に登録可能な独自リソースであり、上述の What 部に相当します。 Custom Resourceを作成するには CRD (CustomResourceDefinition) という機能を利用します。 CRDに独自のリソース(Kind: MySQL等)とそのスペックを定義してKubernetes上に登録することで、Custom Resourceの利用が可能になります。

一方Custom Controllerは上述の How に相当し、どのようにCurrent StateとDesired Stateを一致させるか(Reconciliation Logic)を担います。Operatorの文脈ではCustom ResourceをCustom Controllerが扱う対象とします。

つまり、Custom Resourceに定義されたDesired Stateを実現するのがCustom Controllerであり、これらを一括りにOperatorと呼びます。

注意点

Operator が増えてくると、特に適当な名前で登録したCRDなどリソース名が被ってしまうことがあります。 その場合はリソース名のフルパスを指定する必要があるそうです。

また、OpenShift で Operator を使用する場合には適宜 ServiceAccount の権限設定などを適切にしておく必要があります。

Operator Hub

https://operatorhub.io/ というサイトがあり、DockerHub の Operator 版のような位置づけかと思っています。

www.redhat.com

OpenShift Certified Operators

Operator 自体は誰でも作れるものなので、OpenShift 向けの Operator として Certified Operator というものがあり、安心して使えそうです。

blog.openshift.com

OpenShift 4のCluster Version Operator

OpenShift のクラスタバージョンの管理も Operator で出来てしまうというのはなかなか衝撃的です。

nekop.github.io

その他

  • Operator SDK: Enables developers to build Operators based on their expertise without requiring knowledge of Kubernetes API complexities.
  • Operator Lifecycle Management: Oversees installation, updates, and management of the lifecycle of all of the Operators (and their associated services) running across a Kubernetes cluster.
  • Operator Metering (joining in the coming months): Enables usage reporting for Operators that provide specialized services.

結論

Operator 利用すると、裏で自動で CRD や Custom Controller を作成してくれます。Controller まで出来上がるということは、リソースをある状態に保てるということです。言い換えれば、Operatorを使うことでKubernetesやOpenShift上でマネージドサービスのように信頼性のあるサービスをPrivateに簡単に構築できてしまうと言えるのではないでしょうか。

参考

KubernetesのCRD(Custom Resource Definition)とカスタムコントローラーの作成 - Qiita

enterprisersproject.com

medium.com

github.com

AWS Certified Big Data - Specialty に合格しました

学生の頃は全く資格には興味がなかったのですが、社会人になってからは単位のような目にわかるものがなくなったせいか資格をよく取るようになりました。独学では偏りがでてしまうところを俯瞰的に、また世の中的なベストプラクティスを効率的に知ることができるところが資格試験のいいところかなと思います。

この度 Big Data に合格してAWSの資格が7つになりました。

f:id:tshimba:20190728192611p:plain

本記事では AWS Certified Big Data - Specialty について記載しますので、AWS認定の全体的な説明についてはこちらを参照してください。

www.linkedin.com

前提知識

以下の状態で今回 Big Data 試験の対策を開始しました。

試験対策

Linux Academy の AWS Certified Big Data - Specialty Certification の Practice Exam を3周やりました。試験の情報も少なくどこを深掘りしたらいいかもわからなかったのでこれくらいにしました。

結果

これだけで無事合格しましたが、結構ギリギリだったと思います。他の方がブログに書いているのと同じくCollectionが一番難しく、次点でStorageの点数が低かったです。

反省点

以下を意識してもう少し勉強していたほうが良かったかなと思いました。

  • 既存システムを考慮してAWSへどう移行するかなど、実際と近いケースを想定してアーキテクチャを検討する
  • データの特性によって、Data StreamsやFirehoseでS3へ格納するのか、またはRedShiftやDynamoDBに入れたほうがいいのかを理解する

また以下の Qwiklabs のコースをやっておいたらもう少し点が上がっていたのかなという気がします。

Tips

現在日本語でも提供されていますが、英語だと強調されているニュアンスが失われたり、意味がわからないところが1割以下くらいですがあります。適宜英語に切り替えて回答することをおすすめします。 私の場合は1週目が1問を1.5分くらいで回答して70分余ったため、2周目で適宜英語に切り替えたりしつつ回答しました。

試験自体が2年ほど前に出たこともあり、当時のAWSの機能を想定して答える必要がある箇所があるかも知れません。試験が更新されたら Glue の問題が結構入ってくるのではないでしょうか。反対に Data Pipeline は減るのかなと思います。

aws.amazon.com

関連リンク

受験前に以下のブログも参考にさせていただきました。

blog.brainpad.co.jp

qiita.com

techblog.nhn-techorus.com

cloudfish.hatenablog.com

JJUG ガチKubernetes講座まとめ

先日開催されてJJUG主催のKubernetes講座【東京】JJUG ナイトセミナー 「ガチKubernetes講座@Microsoft」 3/2(金)開催に参加してきました。

当日の資料はすべてGitHub上に公開されています。

github.com

資料を直接読み込むのが一番いいかと思いますが、当日スピーカーの方が話した内容を殴り書きでメモしましたので、以下に載せておきます。

例えばラベルにはapp, env, versionは必ず入れましょうだったり、Deploymentの設定にはネットのサンプルとして転がっているYAMLファイルでは不十分なので最低限こういうないようは記載しましょうといった内容がためになりました。最後の8章は、Kubernetes関連のHelm, Draftなど便利ツールの紹介でした。

講座中はスキップした内容もあったこともあり、すべてはメモできていないので、本エントリは概要の把握にとどめ、詳細はGitHubの原典にあたっていただければと思います。

Speaker

Yoshio Terada k8s-Azure-Container-Service-AKS--on

hackfest で蓄えたノウハウ伝授 ローカル環境にあったメモをbrash upしたもの

Kubernetesのすばらしさ - 開発者と運用者両方が協力して扱うことで発揮できる

資料はすべてGitHubに公開する

2020のプロジェクトがあるので、すべてのサービスを知っている人はいない。 常にキャッチアップをしないといけない。

About Kubernetes

  1. Master
  2. node
  3. Pod
  4. Container
  5. Service
  6. Deployment
  7. iptable
  8. ingress
  9. version
  10. namespace
  11. istio

master

master serverの重要なコンポーネント - API Server: REST を待ち受けるサーバ

node

可用性セットのVM

pod

Pod: Container間のサービスが密接に関わりがある場合

service

1 service, multi pods

deployment

replicas

labels

ラベルからこのサービスを選択可能。 ちゃんと書いていきましょう。

例: - app: account-service - env: test - version: v1

container

image: xxx <- 作成したimageの指定

iptable

version

最新 1.9.x

namespace

dev, prod, testなどで分けて使うイメージ

istio (6章)

version 0.5? まだ本番環境では速い。 istio (サービスメッシュ) はトレンドなので動向を見守る

podの中にproxyが作成される イエーガー? 分散トレーシングして、マイクロサービスの依存関係のツリーを可視化してくれたりする サービスから個々のサービスの呼び出しにどのくらい時間がかかるのか取得できる

Kubernetes自身のネットワーク周りが弱い。Istioすごい便利 - version 1に100%処理を振るなどの指定 - 特定のheaderがあるリクエストだけがversion 2にアクセスするなど - カナリアリリース - サーキットブレーカー <- Java側でnetflixのライブラリを使用しなくてもいい。Istioでやってくれる

AzureでKubernetesを使用する場合の説明

提供形態

  • Managed: microsoft managed master servers. masterノード用のVMの支払不要。k8s のバージョンアップもコマンド一つで可能。システムを停止せずに更新可能(3,40分程度かかる)
  • not managed: ACS is not managed. 自身でmasterノードのHAなど必要

環境構築

Mac, Windows 10は簡単 古いwindowsVMなどを立ち上げたほうが速い

Azure cli

brew install az command

$ az aks <- kubernetes 環境構築
$ az login

AKS

まだpreview version 一部リージョンで使用可能

Azureのリソースグループの説明

$ az group create --name MCACS-AKS --location eastus
$ az aks create --resource-group MCACS-AKS --name esakscluster --node-count 5 --generate-ssh-keys
$ az aks install-cli <- credential 取得
$ kubectl cluster-info
$ kubectl version <- 1.7.7 (update later)

nodeの数

サービスにあわせてVMの数も増やす

$ az aks scale --name esakscluster --resource-group MCACS-AKS --node-count 7

version up

無停止バージョンアップが可能 Azure は1.8.7が最新、1.9.x対応準備中

$ # version check
$ az aks get-upgrades --name esakscluster --resource-group MCACS-AKS
$ # upgrade
$ az aks upgrade --name esakscluster --resource-group MCACS-AKS  --kubernetes-version 1.8.7 --yes
$ # check version
$ kubectl get node -w

構築

Dockerfile

前提知識:小さいイメージを作る java:8-jdk-alpine <- 小さい * alpineはコマンドなども変わるので気をつける。普通のUbuntuなどとは違う 注意点例1:ssl関係ライブラリが入っていない 注意点例2:useraddではなくadduser

ビルド結果のみimageに入れる

docker version 17.05 から multi stage build 複数のビルドステップを記述可能。(FROMを複数記述可能) -> DeliveryPipeline のような感じで、BUILDステップ、DEPLOYステップを分けて記述可能 * サンプルではparayaを使っている

Java SE9 以降 -> JREを自分で作れる -> より小さいimageを作れる

push image

pull image from kubernetes

Pod

本番環境で耐えられる deployment

教科書レベルのdeploymentに追加すべきこと

ラベル

ラベルは必ずつける app, env, version

rolling upgrade

今動いているコンテナに来ているアクセスはどうするのかなど、設定可能

例: - minReadySecond -> コンテナ起動後、アプリが正常に動くまで待つ - maxSurge -> 先に1個増やす - maxUnavailable -> かならず1個は残す

health check

livenessProbe

  • initialDelaySeconds: コンテナが起動しただけで正常となる(デフォルト)ことを防ぐ。healt chechまでの時間。falseだとコンテナを再起動されてしまう。
  • readinessProbe: サービスを使えるかを確認する。10秒に一回pingをかける
  • failureThreshold: X回失敗したらFailとする

リソース管理

pod 上の service は node 上のリソースを使い切ってしまう。 -> node上の全サービスに影響を与える可能性がある。

実際には負荷テストをしてから、リソースの上限を決定する

$ # get pods
$ kubectl get po
$ # 使用しているリソースを取得
$ kubectl top pod PODID
設定での指定方法
  • requests:
  • limits: (単位:1cpu = 1000m)

コンストラクタ的なもの

init Container

Podを起動前に実行する処理 Java クラスのコンストラクタ的なもの

poststart hook

prestop hook

------------------ ここまででpodが作成できました

Service

YAML要素

  • selector: ラベルをしていしてexposeする。versionなども指定可能。ex) app: account-service
  • type: 基本クラスタIPを指定する

複数YAMLをまとめる

--- で区切ってYAMLを繋げる

リリース作業

以下の手順が必要だが、毎回実行するのは大変 - build app - create image - push image - pull image ...

Shellスクリプトで記述してしまう。 (jenkisとかは使えないが、開発で頻繁にリリースする場合は使える)

---- ここまででビルド完了

動作確認

本番環境では基本クラスタIPを使用するが、特定のサービスの動作確認をしたい場合にはport forwardして単体で公開する。

YAML

YAMLを書く時に参考にできる公式の情報の調べ方

$ kubectl explain deplloyment.spec

---------- ここまで3章

4章

最低限覚えておいたほうがいいコマンド一覧 22個 -w: watchの略 -> 動的に変わる情報を閲覧する -o wide: podがどのnode上で動いているか取得する

  1. a
  2. 2
  3. config map service-name.ns-name.svc.cluster.local <- dns名でアクセス可能(直接ipでない)
  4. secret
  5. apply: 上書きできる
  6. delete
  7. edit: 一時的に設定を変える <- 一時的にサービス単体に外部IPを与える時など
  8. scale --replicas: 明示的にスケールをさせる場合
  9. auto scale
  10. kubectl config get-contexts: よく使うkubernetes環境をデフォルトに設定できる
  11. kubectl xxx: よく使うnamespaceをデフォルトに設定できる

5章

KubernetesのREST api

6章

istio

7章

Kubernetesを扱う上での注意点

タグ:latest <- latestタグを使用するのはやめてください

何がlatestなのかわからなくなってくる 必ずimageに対してはversion番号を振る kubernetesはロールバックなどもできるので、どのバージョンに戻るか指定するのが難しい(人間にやさしくない。不可能ではない)

1つのサービスを1コンテナで提供していきましょう

自分がKubernetesのどのバージョンを使用しているのか意識する

バージョンが上がるとYAMLの書き方やコマンドが変わってくる。後方互換性がなくなってくる。

Podを直接使わないでください。

* ReplicationController(Old) -> ReplicaSet(Old) -> Deployment

できるだけ小さいimageを使用する

officialはまだいいかもしれないが、人のimageは使用しない。

ClientIPを使用する

Nodeに対してアクセスできないようにする(Azure AKSではdefaultで使用できなくなっている)

Nodeが乗っ取られると最悪 必ずmaster経由でアクセスする

recordオプション

applyをするときにはrecordオプションを使用する

config map, secretを使用しましょう

8章

Kubernetesを扱う時に便利なツール

  1. Helm: 開発、デプロイ
  2. Draft: 開発時にユーザをXXのdeveloperと認識して、draft create とするとjavaと認識する?
  3. SpenNaker: CI/CD

  4. weave

# すごい細かい情報が取れる
$ kubectl port-forward -n weave PODID
  1. Heptio Ark: Backup & Restore
  2. kube-monkey
  3. open service broker Kubernetes Service Catalog Azure: OSBA (Open service broker for Azure)

マイクロサービスとドメイン駆動設計 (1)

マイクロサービスアーキテクチャの目的と課題

最近はどこもかしこもマイクロサービスがブームになっているようである。クラウドの普及に伴って、マイクロサービスを実際に構築できる技術的な土壌が整ってきていることも追い風になっている。しかし、実際に構築しようとすると壁にぶちあったってしまうことが多いと思う。

ユーザー企業が求めていることは、変化に速く対応できるシステムを作ることであると思う。このような要件を満たすためにマイクロサービスアーキテクチャを適用できる。マイクロサービスが技術的に実現することは、サービスを分割して、個々のシステムを頻繁にリリースできることである。頻繁にリリースを行うことで、変化に迅速に対応する基盤を提供することができる。このことを忘れてベンダー企業ではサービスを分割することだけを考えて変化に迅速に対応できるかというところを忘れていることもあると思う。

サービスの分割方法

そもそもマイクロサービスというネーミングがミスリーディングだと思うが、SOAよりは小さいだろうというくらいで、特にサービスの大きさが本質ではない。サービスを適当に分割しただけではシステムはより複雑になり、テストも終わらずにリリースできないコードが溜まっていくことさえあると思う。では具体的にどのようにサービスを分割していくかというと、ドメイン駆動設計の知識が必要になってくる。サービスを実際のビジネス・組織と同じ単位で分割することで、本来の目的であるリリースを頻繁に行えるシステムができる。

米国などではドメイン駆動設計は2003年に登場してからその考え方が普及し、そして今になってドメイン駆動設計をより簡単に実現できるマイクロサービス関連技術が登場してきた経緯があるのだと思う。翻って日本では、ドメイン駆動設計のバックグラウンドなしに、マイクロサービス関連のコンテナやKubernetesなど表面的な技術だけがブームになってきてしまっている気がする。ドメイン駆動設計を理解していない限り、マイクロサービス関連技術を使って、運用者と開発者、ユーザー企業とベンダー企業が幸せになれるようなシステムは作れないのではないかと思う。

ドメイン駆動設計の書籍

ドメイン駆動設計に関する書籍は、エリック・エヴァンスのドメイン駆動設計聖典である。機械学習のPRLMくらいの立ち位置だと思う。

それなりにボリュームがあるので、2,3ヶ月かけて読んでいく予定である。ドメイン駆動設計に関する気付きなどをここにまとめていけたらと思う。

2017年の活動振り返り

新年の抱負の後ですが、一度2017年の活動の振り返りを書いておきます。

tshimba.hatenablog.com

新年の抱負に書いた事以外に、普段の心がけとしてなるべく振り返りを多くしていきたいと思います。

2017 年にやったこと

インプット

IBM Cloud 認定試験

IBM Cloud (当時 Bluemix) の資格取得しました。

AWS 認定試験

AWS の勉強を初め、わかりやすい目標として資格取得を設定し取得しました。

tshimba.hatenablog.com

昨年8月からAWSの勉強を始め、Developer (Associate), Solution Architect (Associate), DevOps (Professional)を取得しました。以前書いたDeveloper以外の試験対策エントリーは今後書く予定です。

Alexa スキル開発

AWS認定試験にはAlexaが入っていないので、別途スキルを作ってみました。

tshimba.hatenablog.com

アウトプット

主な対人でのアウトプットは、社内コミュニティの機械学習勉強会と新入社員研修講師でした。

2018 年の心がけ

インプットばかりに追われて、アウトプットがあまりうまくできていなかったと感じています。インプット後、他の人に共有できるレベルのアウトプットを意識してまとめ・振り返りをしていきたいと思います。

2018年終了時点では、本エントリーと抱負のエントリーをベースに振り返りをします。