now maintainance mode
 now maintainance mode2-5

プログラムを買うのと、洋服を買うのは似ている、ユニクロで買うかデパートで買うか
洋服であることに変わりはないし
デパートにユニクロが入っていることもある
セレクトショップの方がいいこともある
 
トレーナー1枚は
トレーナー1枚であることに変わりはない

つまり 飲食店が過小ではなく飲食店が競争状態になるということは
その地域に牽引産業が不足しているということを示している。

言い方を変えれば牽引産業の方が多い場合、オフィスでの昼食競争が巻き起こり
飲食店に行列が発生するのですぐにわかる。

つまり昼食を提供している飲食産業が競争状態に陥るという事は
その地域一帯の牽引産業が衰退しているといえる

Bash 改良版コード

DockerのAPIをTCPで待受させる – Qiita

change config(FAILED)

or easy rewrite

DockerのAPIをTCPで待受させる – Qiita

EMRの対抗技術でECSをみて3週間
ようやくやりたいことがスムースにできるようになってきた。

ひさしぶりにiPhoneを買いたくなった

すこし本格的に 機械学習をやろうとして 3か月ぐらいまともにプログラムが組めてない
サーバーを立てて Hadoopをどうたらこうたら
クラスタ林gで100台ぐらいのPCを1分借りたいだけなんだが Amazon EMRなどを使えばいいというはなしはおいておくと
やれECRだECSだと様々な単語が飛び出し
やれしらべたりなんだりで
完全ローカルな環境にレジストリ立てるのに外部に公開したWebサーバが必要な場合があるなど
めちゃくちゃ感があるので(Docker HUBなどをつかうのもためした)

環境構築するだけで 初見だとWebサーバの構築などに慣れていて 3か月くらいかかるなと
クラスタリング設定したり
いろんな他のソフトの設定をしたり かなりたいへんで
ようやくJupyter notebookにもどって
機械学習のスクリプトをためせるかなみたいな。

EMRでやめときゃよかった まぁ というわけでこの辺はまだドキュメントも少ないので
結構環境構築に慣れていても 3か月は欲しい

Bigdata化しない機械学習の環境なら1人月もあればいい

Amazon純正のECRがいまいち難しいので
場合によっては SSL環境下のDocker Registryは自分で建てたほうが良いかもしれない
問題は Docker Registry が PULL専用の場合 CloundFrontで大規模配信で1024コンテナとかを短時間で配信しきれるかどうか
調査しておかなければいけないことは根深い
(さすがにコンテナを1024個デプロイするとなるとCloundFront級でないときつい 何が使えるか調査)

実験して確認するから 肝心の機械学習のコーディングできやしねぇ

いきおいDocker Registryをローカルに抱えたAMIでスタートしてぇ
さすがに1000台は客がついてから実験に入るとしても
100台ぐらいはデモンストレーションできないとだめだろうなと(ま少ない台数でクラスタリングでBigdataするアルゴリズムもあるけどそれはそれ)

調査する内容が多い(ダメだというにも調査は必要なために 良いプラン ダメなプランわける調査が長い)

ECR Amazon Elastic Container Registry

(ECR) is a fully-managed Docker container registry
思っていたのとは少し違い、やはり大規模向けかとおもう。
ECSとの連携を確認するが、やはり少々使いにくさは残る。
Dockerとは思った以上にはよく連携している。

ECS Amazon Elastic Container Service

コンテナ系サービス vCPU単位で実際に使う計算量を先に指定してコンテナを複数立ち上げるイメージ or EC2

大規模向けというのもあるのだろうが
個人にはとっつきにくさがある。
Dockerとは違うところが多いので、個人ならEC2かEMRとは思うが
EMRの対抗技術として、興味深く確認中
とにかくとっつきにくい
とはいえであるがゆえにブロガーとしては面白い

EMR

EC2のクラスタリングサービスでECSのEC2よりは使いやすさを感じる
とはいえしょっぱなでトラブルをくらい(その後は安定)
良し悪しはあるが難しい
EC2で複数台を借りるより割引があるので
並行演算で多数使うならいいかもしれない。

Amazon ECS タスクに Amazon ECR イメージリポジトリからイメージを取得することを許可する

補足 よくある事項

Task Lifecycle – Amazon Elastic Container Service
Amazon ECSのタスクで表示されるステータスについて
PROVISIONING
  ↓
PENDING
  ↓
ACTIVATING
  ↓
RUNNING

※ECSとECRの連動は結構手間、セキュリティー系を結構設定しないとImageのPULLに失敗する
Docker hubやプライベートリポジトリをEC2に立てたほうがスムーズな場合がある(調査 8h)

※ログの保存先がS3ではなくCloudWatchなのでパーミッションが必要

雑感

RedhatだったりUbuntuだったりLinuxの細かいディストリビューションの違いよる細かい違いに
苦労する。
1つ1つ原因を調べて対処するころにはメーカーが対処が終えて
やんなきゃよかった3週間みたいな悩みを抱える。

クラスタリングとはいわないけど負荷分散は昔からやっているエンジニアが
Hadoopという個別技術などを前提として

ロールの設定だったり、CloudWatchの設定だったり
それなりに手間なので、コンテナイメージの作成以外の
雑多なタスクは頼める人がいるならお願いするのが吉
 
EMR,ECS,ECRを2週間使ってみて感想を書く。
(あと1週間ぐらい調査が必要)
すると、思いもよらない話はいろいろ出てくるので、それについては下調べをして
技術職としてスキル対応したうえで、大丈夫そうか?とか将来性を加味すると
まぁ2週間ぐらい。

つかってみないとわからないとか
やってみてだめだと、気を取り直してまた明日とか 実際は1か月あると楽
 
簡単にサンプルがあったりすると動かなかった場合にメーカー問い合わせなどまで考えないといけないとなると3か月コース
※レポートにまとめて報告とかだと執筆作業で+2週間
簡単に雑感報告+αの見積もり