toru-murasawaの日記

IoT,Startup,Technology etc

Kubernetesはいいぞ

さて、ここ最近いわゆるラーメン代稼ぎとしてインフラ関連のお仕事をいただいている中、Kubernetes(K8S)をなんとか使えるレベルにまでなってきたのでVMwareや一般的なベアメタルインフラを触ってきたエンジニアの視点でメモを書いてみる。

 

高い学習コスト

K8Sの世界は、極めて高度な抽象化がされているため、まずK8S固有の概念(Pod,service,ingress,persistent volume etc..)を理解した上で手を動かす事が必要になってくる。

基本的に、インフラレイヤとして意識するのはdockerより上位の層が中心となってくるためlow-levelでの理解はむしろ足枷にしかならず、K8Sの美味しい部分をいかに普段のインフラ構築運用上の課題解決に取り込めるかの観点で学習するのがモチベーションを維持する意味でも良いのではないかと思う。

Yamlを乗りこなせ

 K8Sでは、構成に関する全てをyamlマニフェストに定義(宣言)し、オブジェクトの作成やスケールアウトの定義までファイルとして宣言しなければならない。

このyamlをkubectlコマンドに渡して、作成、更新を繰り返していく事になる。 

例えば、ingressコントローラをインストールしたい場合、最低でもingress本体、設定(configmap)、Role、default backendのpod作成などに必要な複数のyamlファイルが必要になる。

ただ、yamlに関してはyumのような依存性を解決してくれるパッケージマネージャーのようなhelmというものがあり、これを活用する事でyaml地獄から幾らかの負担低減にはなるだろう。

Scale out/Rollingupdateが素晴らしい

宣言的インフラの意味するところ、yamlマニフェストに最小Pod(コンテナの単位)や最大Podを記述しておけば、クラスタの総リソース内で自動的にPodのScale out/inが行われる。

そして、Deploymentとして作成したPod定義のコンテナイメージのtagを書き換えれば、全Podのイメージが自動的にRollingupdateして最終的に指定通りのコンテナイメージがdeployされる。

頻繁にdeployが繰り返されるCI/CDのトレンドと最高の組み合わせではないだろうか。

まとめ

私は、Google Cloud Platformが用意するマネージドK8SであるGKEで概念を学んだが、さすがにGKE自体が純度の高いK8S環境なので、オンプレK8S環境でもGKEとほとんど変わらない感覚で操作することができた。ただ、LoadBalancer周りはクラウドプロバイダごとに固有の違いがあるので、この点だけは留意しておきたい。
総じて、K8S自体の学習コスト自体は高いものの、これからはK8Sがコンテナオーケストレーションの主流になることはもはや疑いもなく、クラウドに関わるエンジニアであれば是非とも触ってみてほしい。

 

4K最高。

開発環境として長らくMac mini 2012Lateを使ってきたのだが、昨年末にやっと新型が出たので6年ぶりに買い換えてみた。

モニタも手持ちのFull HD23インチから4K対応の27インチにしてみた。

これが想像以上に良かったので、感想を書いておく。

  • ターミナルがバカスカ開ける
  • スケーリングでなんちゃってretina化で目に優しい
  • Youtubeがきれい

買って、最初にYoutubeで見たDAPUMPのU.S.Aの臨場感がFHDで見るより全然違ったw

私が買ったのはLGの27UK600-Wという機種。Amazonで4万ちょっとで買えたが6年使ったEIZOのEV2336Wとの違いは歴然である。

まあ、4Kでスケーリング表示でも4K最高って話でしたw

 

 

ひとりスタートアップのサービス開発

久しぶりのブログ記事である。

新年ということもあり、初心に返る意味で今回はエンジニアひとりでサービス開発する際に意識しておくといいことがあるかもしれないポイントについて書いてみる。 

サービスデリバリを重視する

大抵のスタートアップは、クラウドサービスの形態(PaaS or SaaS)でサービスを世に出すことを前提とした場合、まず重視すべきは「動くものを、世に出す」ということである。

何を当たり前のことを、と言うべきところだが実際に動いて、それなりのUIを提供しそれなりのドキュメントを伴う形でローンチできるところまでは相当のエネルギーを要する。

まずは、最低限のクオリティ(MVP:Minimal Viable Product)を保ったプロダクトをスピーディに市場に出すことが何よりも最優先される。ここを意識することで、今やるべき事・やらない事の選択がシンプルになる。

Gitを使わない

チームで開発する場合はレポジトリが必須になるのは言うまでもないが、ひとりスタートアップには基本的にレポジトリ管理が必要ないと感じる。

私が採った方法は、ステージングサーバとプロダクションサーバを明確に分けプロダクション環境のコードは直接いじらずステージングサーバ上で改修を繰り返して、一定の動作確認が終わったらrsyncでコードごとプロダクションにコピーする方法だったが、シンプルかつプロダクションへの影響を最小限に抑える意味で有用なアプローチだと思う。

もちろん、Gitを使っても良いがシンプルな方法論としてrsync管理もありではないだろうか。

スケール前提の構成を組む

例えばSNSサービスを作るとして、最初からCDNやリッチなキャッシュサービス(redis or memcache)を使う必要はないとしても、マイクロサービス化できるところはないかを常に意識して構成を考えてほしい。

また、論理的に分割できる単位(ネットワーク/APP/DBなど)は可能な限りVM、コンテナなどで切り出しTCPベースのロードバランサでスケールできる構成にしておく事をオススメする。

サービスがスケールした場合にあなたを助けてくれると同時に顧客にとってもサクサク動くサービスはそれ自体が価値を生むだろう。

(あえて)マネージドサービスを使わない

ここは語弊がある点だが、マネージドサービス(RDS/CloudSQL)などは開発にリソース投下できる点でメリットが大きいが、当たるかわからない段階ではあえて使わない選択もありではないだろうか。

EC2/GCEインスタンスミドルウェアを直接入れて、サービス成長の過程でマネージドサービスに移行すれば自らがconfファイルをいじりながらトラフィックの負荷に応じたチューニングや今後のアーキテクチャの方向性にも目を向ける事ができる。

また、今後AWS/GCP/Azureという選択がより難しくなる中でもプラットフォーマーに依存しないポータルブルなミドルウェア運用スキルというのは今後高まるのではないかと感じている。

まとめ

ここは私自身が場数を踏んでいるわけではないので(無い無い尽くしの状態での結果論)、今後も試行錯誤しながらやっていくんだろうと思う。

本年もよろしくお願いいたします。

 

 

 

 

 

 

 

 

「メールdelay常習犯」の傾向と対策

自営して色々な利害関係者とコミュニケーションするようになると、特に一定規模以上の企業はメール連絡が遅い傾向がみられる。

ひどい担当者はそもそもメールに気づいていない、あるいはこちらから連絡するまで平気で1週間〜2週間返信を放置する人もいる。

ベンチャー企業の時間は有限であり、1営業日あたりの重みを考えながらやるべき事をスケジュールしないと成功はおぼつかない。

上記のような「メールdelay常習犯」に対しての対策を考える。

  • 回答期限を設ける。

「本件、〜までに意志表示をいただけますか」という感じでデッドリミットを設ける。相手は喫緊の課題でなくても回答期限があるのですっぽかしできないという認識をするだろう。稀に、平気で回答期限を忘れている人もいるのでリマインドも効果的だ。

  • 回答項目を箇条書きでリストする

1.〜についての意志 2.〜のスケジュールの設定 といった感じで相手が決定権を持っている事項について箇条書きしメール返信しやすい形にする。

あまりyes,noで答えろ的な文調は失礼になるのであくまで「決定いただけますと幸甚です」といった文調で相手の時間を割いていただいている事に敬意を表したい。

  • メール後に電話する

相手がすっぽかし常習であれば、メール後に電話して念押しするのも原始的だが効果的だ。

その場で回答をもらえるような用件であればメールは言った言わないを回避する意味であえて使い、関係者へのCCのために使うのもありだろう。

 

上記は自分自身が相手のメールにすぐ返す習慣がついているのが前提となる。重要な用件は30分以内に、緊急でない用件でも1営業日以内に返す習慣をつけたい。

私は再度の催促でも連絡が遅れる相手はこちらを必要としない取引先だと思っており、経験上も仕事の品質が低い相手が多いと思っている。3営業日以内にメール返信しない相手とは取引しないくらいの社内ルールがあっても決しておかしいとは思わない。

スタートアップは時には付き合う相手を選ぶ勇気が必要だ。

 

 

 

スタートアップにとっての自社サービスと受託

「IoTはなぜ儲からないのか」という記事で数年ぶりに連絡をしてくれた元同僚がやっているスタートアップに遊びに行った。

彼も自社サービスから受託を経験し、また自社サービスにチャレンジするという。やはり挑戦する起業家は目が輝いているしこちらもエネルギーをお裾分けしてもらった気分に成る。

私も起業して最初に作った自社サービス(農業用IoTサービス)が大コケしてしまい、その後現在に至るIoTクラウドへピボットするきっかけとなるのだが依然、成功とは言えない状況で自社サービスの難しさを日々痛感している。

ここではスタートアップ期(創業5年以内)のベンチャーが自社サービスと受託をどうバランスさせながら乗り越えていくべきかを試行錯誤の身として考えてみたい。

 

ラーメン代稼ぎの重要性

シードマネーが潤沢に準備または調達できている場合を除き、最初の売り上げが立つまでに基本的に資本金を燃やしながら、必要に応じて創業者自身からの役員借入金も加えて事業を運営していく。

この過程で、運転資金としてのキャッシュ稼ぎは重要で当座の入金予測が立ちやすい受託は魅力的である。

一般論としては、受託と自社サービスの両立は「中途半端」で終わると考えている。受託をやっているうちに受託一本になってしまうスタートアップの話を聞くからだ。

創業1年目は自社サービスにフルコミットし、サービスの立ち上がりの状況によっては受託もやるといった感じでまずは自社サービスを優先させた方が後悔も少ないだろうし得るものも多いのではと思う。

 

作るの2割・売るの8割

典型的なエンジニア出身創業者(私自身も含め)の場合、自分のアイデアで自分の技術で作った自社サービスが売れない訳がないと思っている。私の場合は、最初に作った自社サービスが日経新聞にも掲載され展示会でも活況だったのに関わらず大コケしてしまい、メディアの反応と市場の反応は全く比例しないという現実を学ぶ事となった。

農家向け製品だったので九州地方で新聞広告も試してみたりしたが問い合わせのハガキ1枚が来ただけだった。

新聞広告など一定期間継続して効果があるようなものに手を出した時点でスタートアップが取る作戦ではないのはマーケティング経験者であれば判ると思うがそのレベルの判断さえ当時は出来なかった。

相応の金と時間を投じて学んだのは以下:

  • 買ってもらうのは消費者が取る最終行為であって、知ってもらわないとその入り口にも立てない
  • 一過性か、その後につながるかのメディア特性とマーケティング投資を見極める

自社サービスは作ってからが本当のスタートだ。

 

受託というビジネス構造の限界

受託はoutputが決められているので、要件通りの案件をいかに回すかが売り上げの多寡に直結する。

合理的に売り上げを突き詰めようとすれば経営者はいかにエンジニアの頭数を揃え、案件に突っ込んでいくかという人月的な発想をせざるを得ない。

outputとしての対価はキャッシュで得られる代わりに会社に残すべき知的財産は残らず中長期的にみれば先が無い商売というのは明らかだ。

(ここでは受託自体を否定している訳ではなく、受託したノウハウを自社ビジネスに活かせない受託はやるべきで無いという考えだ)

せっかくスタートアップなのだから、リスクを取った分自社サービスに賭けてみてほしい。

 

まとめ

やりたい事を突き詰めるには自社サービスという選択肢は最高だ。

その代わり、作ってからが大変だ!という話でしたw

 

40歳からのスタートアップはありか

私は40歳のおっさんである。

37歳で起業し、一度解散を経験し2度目のチャレンジをさせていただいている。

40歳というと、社会の酸いも甘いも一通り経験し職業人生の折り返しを迎え色々な思いに突き動かされる年齢だろう。自分も不惑どころか日々葛藤の真ん中である。

そんな、腫れものセンチメンタルなアラフォーが40歳から起業するとした場合に直面するであろう事をリストしてみる。

 

体力こそ資本という現実を知る

自社でプロダクトをこしらえて世に問うのだ!という熱い、いや第三者からするとどうでもいい思いを具現化するために1日16時間労働も厭わない覚悟が必要になってくる。

1日24時間という地球上の生命体全てに与えられた物理リソースの限界を超えられない以上、1時間でも多くの生産的作業をしoutputを出さなければならない。 

税金が辛い

アラフォーともなるとサラリーマン時代の所得もそれなりのものになっているだろう。退職後の税金(市民税等)は全てサラリーマン時代の所得をベースに計算されるので前もって備えが必要だ。そして、会社が厚生年金を払ってくれているありがたみを実感するだろう。

サラリーマン時代の人脈は期待するな

会社員時代に誰でも知っている大企業に勤めていた人ほどこの現実に直面するだろう。

名刺にある会社のロゴ、肩書きは全て与えられたものであってそれがなくなった時、単なるおじさんになってしまう。

その代わり、軽薄な付き合いだった人は蜘蛛を散らすように去っていく代わりあなたと仕事したいと言ってくれる人が必ずいるはずだ。そんな人こそ、大切にすべきである。

Give and Takeが基本である

独立すると取引先の社長と交流する機会も増えるだろう。先方の時給を考えた場合、あなたと会ってくれた30分でまず相手になにを提供できるか考えるべきだろう。

常に相手の求めている事を先回りして提供できるネタ作りや準備をしておきたい。

媚びるな

アラフォーで組織を飛び出すのはリスクでもあるが20年社会人をやってきたという事実に自信を持ってほしい。

リスクを負ってまでやりたい事があるのだから、苦手な人に無理くり付き合うだけの時間は無いはずだ。本当に一緒に仕事をしたい人というのは、限られてくるはずだ。

せっかく大海に漕ぎだすのだから自分の意思を持ってやりたい事をやり通そう。

 

日本も副業許可の流れに動いているらしいが、これをチャンスと思うか単なる制度設計の1つと思うかは自由である。

IoTプラットフォームの本質とは

前回、日記のつもりで書いた記事がバズってしまい困惑すると同時に嬉しかったりするのだがあくまで日記なので書きたい事を書いていきたい。

さて、「IoTプラットフォーム」であるが完全にバズワードというか大企業もベンチャーも同じ名前で出しているので一体、A社とB社のプラットフォームで何が違うのか?という企業関係者も多いのではないだろうか。

当社も「IoTメッセージブローカ」のPaaSサービスを運営する事業者として、「IoTプラットフォーム」の本質とは何かを考えてみた。

(ここでいう「IoTプラットフォーム」とはハードウェアエコシステムではなくクラウドプラットフォームを指す)

 

1.モノとのメッセージの交換

バイスクラウドを双方向通信させる仕組み一式の提供をする。メッセージとは温度データであったりモータの停止命令であったり様々だ。一般的にはMQTTというプロトコルが使われる事が多い。ここの出来が悪いとデバイスが増えてきた時に接続が切れたり、処理が間に合わないなど完全にIoTというよりは通信インフラの領域である。選定の際にはただ使えるのかだけでなく、安定性や性能的な要素も重要視すべき箇所である。

 

2.モノの認証

あちこちの現場に散在するデバイスに対して認証の仕組みが無いとセキュリティ的に問題である。そのためトークンと言われるユーザ名とパスワードを1つにまとめた認証文字や証明書をデバイスに埋め込んでクラウド接続の際に認証させる仕組みを提供する必要がある。

 

3.モノの管理

どこの現場のデバイスから何のデータが来たか識別するのにはデバイスの個体管理をする必要がある。名札に相当するのがデバイスIDであり、機器固有のMACアドレスだろうが東京工場1フロアAだろうが識別できれば何でも良い。

 

4.モノが生成するデータの蓄積

バイスにぶら下がるセンサなどの末端ノードの情報をクラウド内に貯める仕組みを提供する。センサによって、出力するデータ数とフォーマットが違うのでNoSQLと言われる闇鍋的なデータの突っ込み方が出来るデータベースが使われる事が多い。いちいち、センサの変更や追加で電文仕様を決めているほど現場は暇ではない。

 

5.外部との連携

ここでいう外部システムとは大抵、ユーザが利用するWebアプリの場合が多い。REST APIという標準的な仕組みを用いて、プラットフォームのデータを取り出し必要によって加工の上あとはユーザ要件によってグラフなりデジタル数値として表示する。

 

以上、5つの基本的な役割が「IoTプラットフォーム」の本質部分である。あとはデータに閾値をつけて通知する機能やウェジェットビルダーなるグラフや数値を見栄え良くピコピコさせる機能があるが、この辺りが差別化要素になる事が多い。

 

まとめ

IoT案件を担当する関係者の方は、上記ポイントさえ押さえておけばプラットフォームベンダの思惑と自社で実現したい事のフィット&ギャップが明確になるだろう。

上記に対する質問に答えられないベンダの場合は、プラットフォームを売り切りたいだけの可能性が高いのでポテンシャルを見極める意味でもユーザ自身がやりたい事を整理しておく事は大切である。