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
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.
RHEL8からはAnsibleが完全にMainstreamになりAutomationの時代になりましたが、この流れを汲んでいるような印象です。
ちなみに、Operator で OpenShift 自体の Upgrade までできてしまいます。
Helm vs Operator
ところで Helm と Operator は何が違うのでしょうか。
以下の記事がわかりやすいためいくつか引用しながら説明していきます。
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 で PostgreSQL や MySQL の Operator を見てみると、Rolling Upgrade や Scaling, Failover などの機能が提供されているものがあります。
ということで、Helm では Stateful なサービスの管理は難しいという背景から Operator がでてきたことがわかりました。
Operator 自体の説明はこちらの記事を参照してください。
Kubernetes Operator の何が魅力なのか
Why Operator
Operator はある記事では Game-Changer であると言われています。
また 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
歴史
Operator は元々 CoreOS によって 2016 年に提唱されたコンセプトです。
【OSS】CoreOS、コンテナ管理コンセプト「Operators」発表---Dockerコンテナ管理フレームワーク「Kubernetes」向け、エンジニアやデベロッパーの固有の知識を自動化
2018 年 1 月に Red Hat が CoreOS を買収すると発表しました。この時 CoreOS は Operator や Quay を持っていました。
そして 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 を定義することができます。
Operator
以下の記事の説明がとても分かりやすかったため引用します。
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 版のような位置づけかと思っています。
OpenShift Certified Operators
Operator 自体は誰でも作れるものなので、OpenShift 向けの Operator として Certified Operator というものがあり、安心して使えそうです。
OpenShift 4のCluster Version Operator
OpenShift のクラスタバージョンの管理も Operator で出来てしまうというのはなかなか衝撃的です。
その他
- 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
AWS Certified Big Data - Specialty に合格しました
学生の頃は全く資格には興味がなかったのですが、社会人になってからは単位のような目にわかるものがなくなったせいか資格をよく取るようになりました。独学では偏りがでてしまうところを俯瞰的に、また世の中的なベストプラクティスを効率的に知ることができるところが資格試験のいいところかなと思います。
この度 Big Data に合格してAWSの資格が7つになりました。
本記事では AWS Certified Big Data - Specialty について記載しますので、AWS認定の全体的な説明についてはこちらを参照してください。
前提知識
以下の状態で今回 Big Data 試験の対策を開始しました。
AWS Certified Solutions Architect - Professional を取得済みで普段からAWSを触っていますが、あまりビッグデータ関連は触っていません
2年ほど前に Big Data on AWS という有料のクラスルーム研修を受けました
ビッグデータを支える技術 を読んだことがある
Cognitive Class (旧BigData University) というサイトで以下のHadoop関連コースを受講したことがあります
- Big Data 101
- Python for Data Science
- Spark Fundamentals I
- Hadoop 101
- Scala 101
- MapReduce and YARN
- Apache Pig 101
- Simplifying data pipelines with Apache Kafka
- Moving Data into Hadoop
- Controlling Hadoop Jobs using Oozie
- Developing Distributed Applications Using ZooKeeper
- Solr 101
- NoSQL and DBaaS 101
- Accessing Hadoop Data Using Hive
- SQL Access for Hadoop
- Using HBase for Real-time Access to your Big Data
- Spark Fundamentals II
- Analyzing Big Data with a spreadsheet UI
- Spark Overview for Scala Analytics
- Spark MLlib
- Exploring Spark's GraphX
- Analyzing Big Data in R using Apache Spark
試験対策
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 は減るのかなと思います。
関連リンク
受験前に以下のブログも参考にさせていただきました。
JJUG ガチKubernetes講座まとめ
先日開催されてJJUG主催のKubernetes講座【東京】JJUG ナイトセミナー 「ガチKubernetes講座@Microsoft」 3/2(金)開催に参加してきました。
当日の資料はすべてGitHub上に公開されています。
資料を直接読み込むのが一番いいかと思いますが、当日スピーカーの方が話した内容を殴り書きでメモしましたので、以下に載せておきます。
例えばラベルには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
- Master
- node
- Pod
- Container
- Service
- Deployment
- iptable
- ingress
- version
- namespace
- 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は簡単 古いwindowsはVMなどを立ち上げたほうが速い
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上で動いているか取得する
- a
- 2
- config map service-name.ns-name.svc.cluster.local <- dns名でアクセス可能(直接ipでない)
- secret
- apply: 上書きできる
- delete
- edit: 一時的に設定を変える <- 一時的にサービス単体に外部IPを与える時など
- scale --replicas: 明示的にスケールをさせる場合
- auto scale
- kubectl config get-contexts: よく使うkubernetes環境をデフォルトに設定できる
- 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を扱う時に便利なツール
- Helm: 開発、デプロイ
- Draft: 開発時にユーザをXXのdeveloperと認識して、draft create とするとjavaと認識する?
SpenNaker: CI/CD
weave
# すごい細かい情報が取れる $ kubectl port-forward -n weave PODID
- Heptio Ark: Backup & Restore
- kube-monkey
- open service broker Kubernetes Service Catalog Azure: OSBA (Open service broker for Azure)
マイクロサービスとドメイン駆動設計 (1)
マイクロサービスアーキテクチャの目的と課題
最近はどこもかしこもマイクロサービスがブームになっているようである。クラウドの普及に伴って、マイクロサービスを実際に構築できる技術的な土壌が整ってきていることも追い風になっている。しかし、実際に構築しようとすると壁にぶちあったってしまうことが多いと思う。
ユーザー企業が求めていることは、変化に速く対応できるシステムを作ることであると思う。このような要件を満たすためにマイクロサービスアーキテクチャを適用できる。マイクロサービスが技術的に実現することは、サービスを分割して、個々のシステムを頻繁にリリースできることである。頻繁にリリースを行うことで、変化に迅速に対応する基盤を提供することができる。このことを忘れてベンダー企業ではサービスを分割することだけを考えて変化に迅速に対応できるかというところを忘れていることもあると思う。
サービスの分割方法
そもそもマイクロサービスというネーミングがミスリーディングだと思うが、SOAよりは小さいだろうというくらいで、特にサービスの大きさが本質ではない。サービスを適当に分割しただけではシステムはより複雑になり、テストも終わらずにリリースできないコードが溜まっていくことさえあると思う。では具体的にどのようにサービスを分割していくかというと、ドメイン駆動設計の知識が必要になってくる。サービスを実際のビジネス・組織と同じ単位で分割することで、本来の目的であるリリースを頻繁に行えるシステムができる。
米国などではドメイン駆動設計は2003年に登場してからその考え方が普及し、そして今になってドメイン駆動設計をより簡単に実現できるマイクロサービス関連技術が登場してきた経緯があるのだと思う。翻って日本では、ドメイン駆動設計のバックグラウンドなしに、マイクロサービス関連のコンテナやKubernetesなど表面的な技術だけがブームになってきてしまっている気がする。ドメイン駆動設計を理解していない限り、マイクロサービス関連技術を使って、運用者と開発者、ユーザー企業とベンダー企業が幸せになれるようなシステムは作れないのではないかと思う。
ドメイン駆動設計の書籍
ドメイン駆動設計に関する書籍は、エリック・エヴァンスのドメイン駆動設計が聖典である。機械学習のPRLMくらいの立ち位置だと思う。
それなりにボリュームがあるので、2,3ヶ月かけて読んでいく予定である。ドメイン駆動設計に関する気付きなどをここにまとめていけたらと思う。
2017年の活動振り返り
新年の抱負の後ですが、一度2017年の活動の振り返りを書いておきます。
新年の抱負に書いた事以外に、普段の心がけとしてなるべく振り返りを多くしていきたいと思います。
2017 年にやったこと
インプット
IBM Cloud 認定試験
IBM Cloud (当時 Bluemix) の資格取得しました。
AWS 認定試験
AWS の勉強を初め、わかりやすい目標として資格取得を設定し取得しました。
昨年8月からAWSの勉強を始め、Developer (Associate), Solution Architect (Associate), DevOps (Professional)を取得しました。以前書いたDeveloper以外の試験対策エントリーは今後書く予定です。
Alexa スキル開発
AWS認定試験にはAlexaが入っていないので、別途スキルを作ってみました。
アウトプット
主な対人でのアウトプットは、社内コミュニティの機械学習勉強会と新入社員研修講師でした。
2018 年の心がけ
インプットばかりに追われて、アウトプットがあまりうまくできていなかったと感じています。インプット後、他の人に共有できるレベルのアウトプットを意識してまとめ・振り返りをしていきたいと思います。
2018年終了時点では、本エントリーと抱負のエントリーをベースに振り返りをします。