Cloud Native Days Tokyo 2019 -2019年7月22-23日参加レポート
今回、東京が開催されましたCloud Native Days Tokyo 2019に2日間とも参加してきましたので、報告しようと思います。 セッション毎の報告というより、全体を通した感想を話そうかなと思います。
- CNCFの利用率
- CloudNativeとは？
- なぜCRDがホットなのか？
- Kubernetesは必要ですか？
- Circuit Breaker
- twelve factor app
- 技術にフォーカスした発表
- その他
- 最後に
- 蛇足（参加するまでの経緯）
リンクをまとめています。
qiita.com
CNCFの利用率
一日目のKeynoteで印象的だった内容です。 発表者は、OSDT実行委員長である長谷川さんです。
来場者アンケート1354人から聞いた「クラウドネイティブ技術を活用フェーズについて」の紹介がありました。
既に本番環境に適用している人は、なんと46%という驚きの結果でした。また、開発環境に至っては、63%ということでした。
このイベントに参加している時点である程度フィルターはかかっていると思いますが、それでも大きな割合だと感じました。
次の図では、CNCFプロジェクトの180日間におけるCommit数をグラフ化したものです。
生みの親であるGoogleが1位でindependent(個人)が2番目、日本企業Fujitsuが6位です。熱意が伝わってきますね。
ただ、CNCFのメンバーとして日本企業は17社しかないそうで、まだまだこれからといったところでしょうか。 https://landscape.cncf.io/format=memberslandscape.cncf.io
さらには、Kubernetesから認定された日本企業ではまだないみたいです。残念です。
kubernetes.io
今後は、次のようなカンファレンスが海外でもあるみたいです。ぜひ参加してみたいと思います。
events.linuxfoundation.org
events.linuxfoundation.org
CloudNativeとは？
クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。
※ https://github.com/cncf/toc/blob/master/DEFINITION.md#日本語版
「スケーラブルなアプリケーションを構築および実行」が重要です。これを実現する手段の１つにKubernetesがあります。 「CloudNative = Kubernetes」ではなく、「CloudNative ∋ Kubernetes」という感じです。
ただ、最近ではKubernetesを違う観点で考える人が増えてきたそうです。 それが、二日目のKeynoteで発表された北山さんのスライドにあります。 speakerdeck.com
Kubernetesは「platformのためのplatform」と言われるようになりました。 これは、slide.No.9(Kubernetes is a platform)で見て分かる通りで、次のようなことがわかります。
- 運用管理者
- Self-Healingによってスケールが簡単になる
- アプリケーション開発者
- 簡単にデプロイすることができる
これらは、たしかに「プラットフォームから得られる価値」になりますが、 逆に次のような考慮が必要なってきます。
- 運用管理者
- Self-Healingはどこまで信頼性を担保できるか
- アプリケーション開発者
- ユーザー影響を最小限にするためには、どうればよいか
これらのような「プラットフォームを利用するコスト」が「プラットフォームから得られる価値」よりも大きくなってしまいがちになります。 そこで、Operator (CRD)という概念が最近ホットになっています。
なぜCRDがホットなのか？
CRDという言葉は様々なセッションで取り上げらていました。 CRDとOperatorについては、下記をご参考下さい。 silverbirder180.hatenablog.com
Kubernetesを運用すると、既存のリソースだけでは物足りない所がでてくるそうです。 そういう部分が「プラットフォームを利用するコスト」を大きくしてしまいます。 そこで、オリジナルのカスタマイズしたリソースを独自に開発し、運用を自動化することを目的とした CRD、Operatorが生まれました。 ただ、独自に1から作るよりも、下記のサイトから使った方が効率的なときもあります。 operatorhub.io けど、結局は困ったとき、ソースコードを読むことになるので、それぐらいの能力がないと、 運用を回せない気がします。
zlabのladicleさんの次のスライドがとてもわかりやすく、まとまっていました。 これは貴重な資料ですね。 speakerdeck.com
ちなみに、独自に1から作ったケースがサイバーエージェントの山本さんの発表で、次のスライドです。
speakerdeck.com
同じくサイバーエージェントの青山さんがライブコーディングされていたリポジトリが次のものになります。 github.com
Kubernetesは必要ですか？
Kubernetesを使うべきかの話が2日間でちらほらありました。 次のような議論もあります。 www.atmarkit.co.jp
CloudNativeなアプリケーション構築を目指す場合、どうしてもKubernetesを使う方向になりがちですよね。
今回参加したセッションの多くの企業では、Kubernetesを採用するための検討が下記のような感じでした。
- プレインなKubernetesか、マネージドなKubernetesか
- 大体はマネージドなKubernetesを使う。
- かゆい所に手を伸ばすときになって、プレインなKubernetesを使う。
- Kubernetesのエンジニアは何人か。それは専属か
- どこもKubernetesの知識を保有するエンジニアは少ない。
- 数人程度で専任で進めることが多い。
- ノウハウを蓄積するために、スモールスタート
様々なセッションがあった中で、とても王道なステップを踏まれている企業がありました。それは、SoftbankPaymentServiceの鈴木さんの次のスライドです。
特に「運用を回すコストを考慮すると、KubernetesではなくPaaSを使う」 というポイントが好きです。
Circuit Breaker
耳にタコができるぐらい、この単語を聞きました。 下記のサイトが参考になります。 qiita.com
同期リクエストの先で一部のマイクロサービスに障害があると、クライアントやその先の「クライアントのクライアント」までブロッキングが波及することになりかねない。 この問題を、クライアントと実サービスの間に Circuit Breaker と呼ばれるプロキシを介在させて、実サービスの呼び出し失敗が一定基準を超えると、クライアントからのリクエストを即座にリジェクトさせて、ブロッキング連鎖を解消するパターン。
Kubernetesでアプリケーションを構築すると、分散システムの恩恵を受けるために、
アプリケーションをマイクロサービス化する流れになります。そのマイクロサービス化でよく踏む地雷が、
「後ろのAPIが死んだら、連鎖的に他サーバも死ぬ」という現象です。
これを回避するために、上記のCircuit Breakerパターンを使う企業が多数いらっしゃいました。
本当にいろんなセッションで聞きました...。
twelve factor app
次のWantedlyさんのスライドが、私の中では話題になりました。 speakerdeck.com
要は、「アプリケーションとしての設計の考え方(twelve factor app)を、インフラ部分でも適用してみた」という感じです。 どれも具体的なところまで説明されており、実際にKubernetesを構築する際に役に立つものだと思います。
技術にフォーカスした発表
今回のイベントでは、何か1つの技術にフォーカスした発表が多くありました。 それぞれ私なりにまとめてみました。ご参考下さい。
Chaos Engineering
Docker
www.slideshare.net
Envoy
Logging
LinuxKernel
Prometheus
Sandbox
Scheduler
Spinnaker
speakerdeck.com9:embed:cite]
Istio
その他
サイバーエージェントさんより、エンジニアにとってとても嬉しいアイテムを頂きました。
／
— CyberAgent AI事業本部広報 (@cyberagent_ai) 2019年7月19日
7/22-23
CloudNative Days Tokyo
OpenStack Days Tokyo に社員が登壇！
＼
週明け月曜日より行われる #CNDT2019 #OSDT2019
にて、弊社社員が多数登壇します！
またブースにて #Kubernetes キーキャップの
配布や、#おうちk8s の展示をしています！
ぜひ遊びに来てください😀#CNDT pic.twitter.com/UOcfLZL6Kr
さっそく、キーボードにとりつけてみました。最高です！
こちらのサービスから作られたそうで、私も自前で何か作ってみようかなと思いました。 http://www.wasdkeyboards.com/index.php/products/printed-keycap-singles/custom-art-cherry-mx-keycaps.html
最後に
CloudNativeにどっぷり浸かった2日間でした。
どの企業でもCloudNativeを導入したことによる「つらみ」や「価値」を共有して頂いたおかげで、これから導入する人たち（私を含む）にとっては、有意義な時間でした。
全てのセッションを吸収できたわけではないですが、ここで記載したスライドだけでも理解を深めたいなと思います。
cloudnativedays.jp 今度は大阪で開催されるそうです。これも絶対参加したいなと思います！
蛇足（参加するまでの経緯）
筆者はWebが大好きなエンジニアで、Kubernetesについては理解が浅い人間です。主にフロントエンドに注力しています。
ただ、昨年のDeveloperBoost2018で、サイバーエージェントの青山さんのセッションをうけてKubernetesに興味を持ち始めました。
codezine.jp
青山さんはKubernetesにとても詳しい方で、世代が近いせいか、私もこれぐらい夢中になれるものを見つけたいと感じるようになりました。
私はWebに関わるものなら何でも好きで、Kubernetesも含まれます。そこで、青山さん著作のKubernetes完全ガイドを全て実践することにしてみました。もちろんお家Kubernetesでです。
実際に触ってみると、スケールする簡単さに驚きました。ほぼコマンド一発でPodが複製されて、「え！？」とびっくりです。
そこから、段々とハマっていき今回のイベントに参加することになりました。
【増枠】Frontend de KANPAI! #7 - Going on 令和 - 2019年7月19日参加レポート
今回はDeNAさん主催のFrontendのイベントに参加してきましたので、 報告しようと思います。 frokan.connpass.com twitter.com
※ https://twitter.com/DeNACreators/status/1152199891860389888
※ https://twitter.com/antidotech/status/1152154690617872384
※ https://twitter.com/wanami3103/status/1152202843618603008
イベント概要
「Frontend de KANPAI!」（以下、FROKAN）は、フロントエンドエンジニアやフロントエンドに興味がある人が集い、ドリンク片手にゆるく交流・技術交換ができるコミュニティを目指しています。
※ https://frokan.connpass.com/event/135584/
特徴的だったのが立食形式という点です。 会場には多少の椅子が用意されているものの、ほとんどの人が立ってドリンクを持ちながら、登壇者のお話を聞いていました。
座っていると私はあんまり他の参加者とコミュニケーションしない人です。 椅子があると、その椅子が自身のテリトリーになってしまって閉じこもってしまう気持ちがあります。 しかし、立っているとその縛りがないので、楽にコミュニケーションを取れた感じがありました。 照明が暗かったというところもあると思います。ちなみに、お酒は一切飲んでないです。（笑）
ただ、翌日は少しつらかったです...。
ずっと立っていたせいか、足が痛い #frokan
— silverbirder (@silver_birder) July 19, 2019
普段は、メモをがっつり書いてtwitterに投稿している私ですが、 今回は一切そのようなことをしていません。したがって、ほぼ記憶ベースでイベント内容を報告します。ご了承ください。 誤りありましたら、ご指摘下さい。
印象に残ったお話
ReactとWebComponentsでVanillaな開発
日本経済新聞社 宮本 将 さん
WebComponentsに興味がある私は、この発表は気になっていました。
当選してた！https://t.co/DSmx5ObQty
— silverbirder (@silver_birder) July 12, 2019
webcomponentsについて聞きに行く！#frokan
内容をざっくり説明すると「CustomElementsをプロダクトとして使っていたけど、つらみがあったのでtypescriptで縛るようにしたよ」 というものでした。CustomElementsはWeb標準の技術ですが、reactやvueのようなpropによる型縛りがありません。 すべて文字列として表現するため、バリデーションチェックがつらいというお話が印象的でした。 そこで、react(JSX) + typescriptを駆使してCustomElementsをWrapすることで上記問題を解決されたそうです。
実際に導入したことによる「つらみ」というものは、プロダクト導入検討している私にとってはありがたいお話でした。
そもそも、なぜCustomElementsを導入したのかというお話もありました。 日経さんではWebApplicationというよりStaticなWebSiteに近いプロダクトだそうです。 そのため、reactやvueといったフレームワークは必要以上な機能が多いため却下し、 VanillaなJSでCustomElementsを進めて行こうという経緯があるそうです。 プロダクトの特徴に応じてコンポーネント選択すべきね。
※ CustomElementsっていろんなフレームワークで対応しているんですね。 custom-elements-everywhere.com
実録フグ料理
株式会社ディー・エヌ・エー Takepepe さん
当初、「お、ネタ枠か？」と思っていたのですが、 予想以上に面白いお話でした。
Project Fuguというものがあります。 www.heise.de
Unter dem Codenamen Fugu plant Google die Einführung zahlreicher Webschnittstellen in seinem Webbrowser Chrome, welche die Lücke zwischen Progressive Web Apps und ihren nativen Gegenstücken schließen wollen.
Google翻訳を通すと
コードネームFuguの下、GoogleはChromeウェブブラウザで数多くのウェブインターフェースを立ち上げることを計画している。これはProgressiveウェブアプリと彼らのネイティブの対応物との間のギャップを埋めるであろう。
つまりChromeウェブブラウザからネイティブな部分を操作できることを目的としています。 今回Takepepeさんが紹介していたのはShape Detection APIです。 バーコードやテキスト、そして顔を形状検出するデモの発表がありました。 どれもサクッと簡単に動作していましたが、まだ実験的な機能なため安定しない部分もあるそうです。
次の画像は顔検出した箇所にモザイクを入れるデモです。これは笑いました。
ちなみに、Fuguという名前の由来は、 「ネイティブな部分を操作することは色々な事ができるようになり夢が広がるが、使い所を誤ると危険なもの」という話から フグの「調理の仕方によって美味しい料理になるが、毒があるので調理の仕方を誤ると危険なもの」という自戒の念を込めてFuguになりました。 ネイティブな部分を操作できるということは、センシティブな情報を取得できてしまうという面があります。 そこが使い方によっては「毒」になるものですね。
新しいAPI
株式会社ディー・エヌ・エー feb19 さん
いきなりポエムを語り始めたfeb19さん。 「DeNAの人たちは、みんなこうなのか？」と面白く見ていました。 この発表では、HTML,CSS,JSのAPIが紹介されていました。 LazyLoadという有名なものから、少しマニアックなinverted-colorまで幅広く、よくこんなもの知ってるんだなと驚きました。
最後に
フロントエンドのイベントは、今回初めてかもしれません。 参加者の多くは、どちらかというと「陽の者」が多く、ノリが楽しい人たちばかりでした。 参加者の方と技術的な話をしたのですが、やはりreact, vue, augularのワードが多かった印象です。なんだか聞き飽きた印象もありますが、それだけ需要があるのだなと改めて思いました。
AWS Summit Osaka 2019 2019年6月27日参加レポート
大阪のグランフロント大阪で開かれました「AWS Summit Osaka 2019」に参加してきましたので、 私の中で良かった３つのセッションを紹介したいなと思います。
aws.amazon.com
hastagはこちら twitter.com
私のメモはこちら scrapbox.io
- Amazon Sumerian によるVR/AR/MRアプリケーションの開発
- クラウドネイティブなモダンアプリケーション開発入門
- クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そして組織
- 全体感想
Amazon Sumerian によるVR/AR/MRアプリケーションの開発
Amazon Sumerianの位置づけ
xRと呼ばれる３つのRについて説明がありました。
- xR
- VR (virtual reality)
- 仮想の世界に没入
- AR (augmented reality)
- 物理に仮想をオーバレイ
- MR(mixed reality)
- 物理と仮想が相互作用
- VR (virtual reality)
VRやARについては、広く知れ渡っていると思いますが、MRははじめて聞きました。
VRは、Oculus Questのようなヘッドセットで仮想世界に没入できます。
www.youtube.com
ARは、ポケモンGoのようなアプリで現実世界に仮想のキャラクタを投影できます。 www.youtube.com
MRは、VRとARのMixみたいな感じですね。ヘッドセットをかぶりながら、現実世界に仮想世界がmixされた景色が見えます。
代表的なものとして、Microsoft HoloLensがあります。
www.youtube.com
Amazon Sumerianは、このVR/ARにフォーカスしたサービスになります。
xRアプリの課題
課題は下記の感じです。
- ハードウェアが浸透していない
- 何が必要？
- どうやって作る？
- 使ってもらえるかわからない
私自身、xRのアプリを作ったことが１回だけありますが、同じような課題に悩んだことがあります。どうしても専用ハードウェアが必要になり、使ってもらうハードルが高くなってしまいます。
Sumerianの特徴
特徴は4つあります。
- Webブラウザベースの開発環境
- 開発する環境はWebブラウザベースになるので、特別なものを用意する必要がないです。良いですね。
- マルチプラットフォーム
- モバイル、デスクトップ、VRヘッドセット、ARプラットフォームに対応しています。これが一番魅力的なんじゃないかなと思います。開発者にとってもユーザーにとってもありがたいですよね。
- Sumerian Host
- AWSのサービスとの連携
感想
xRはWeb好きな私でも興味がある技術です。Sumerianをつかうことで、xRの開発をよりスピーディに進めれるようなサービスと感じました。
実際触るかどうかは分かりませんが（無料枠使い切ってしまったので...)、こういったxRを開発するための手段を１つ知れたことは良かったと思います。
（他のクラウドサービスにはxR向けサービスないのですかね...?）
※ 下記のレポートもご参考下さい dev.classmethod.jp
クラウドネイティブなモダンアプリケーション開発入門
モダンアプリケーションのデザインパターン
今回紹介されたパターンは、マイクロサービスのデザインパターンのことを指しているのでしょうか。 microservices.io
デザインパターンといえば、GoFのデザインパターンが有名ですね。 en.wikipedia.org 最近では、分散システムにフォーカスした分散システムデザインパターンがあります。
今回登壇で話されいた内容を私が説明するより、下記のほうが十分に説明がありますので、そちらをご参考下さい。 qiita.com
感想
今回のセッションでは、少し駆け足になっていたせいか全て聞き取れなかった印象でした。 ただ、マイクロサービスデザインパターンの存在を知れてよかったです。 CQRSというパターンを業務上調査した覚えがあるのですが、マイクロサービスデザインパターンの １種だったんですね。知りませんでした。 デザインパターンというのは、先人の知恵が蓄積された素晴らしいカタログなので、 １度目を通しておこうと思いました。
※ 下記のレポートもご参考下さい dev.classmethod.jp
クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そして組織
Nulabの現状
Nulabのサービス
Nulabではbacklog,cacoo,typetalkの３つプロダクトをもっています。 backlogでは、ユーザー数が順調に伸びてきており、今年で100万人を突破したそうです。
backlogについて
backlogには、4つのサービスに分かれており、それぞれIssues, Wiki, Gantt, Gitがあります。 前3つのサービスがMonolithで作られており、後1つのサービスが3つの言語(Perl, Python, Java)で作らていたそうです(Goで再実装されました)。
インフラ部分については(backlogの話に限らない...?)、クラスタが日本に6個、海外に2個存在し、インスタンスが200個もあるそうです。 それらは、Terraform+Ansibleで管理するようにしていたそうですが、物理ホストのメンテナンスに大きくコストがかかるという問題がありました。 また、コードベースが巨大化になると開発者、特に新規の人は理解するのに時間がかかってしまう問題もありました。
Kubernetes・EKSの導入
Backlogの問題点から、開発やインフラをスケールするためKubernetesを検討するようになりました。 そこで(比較的規模が小さい?)CaccoにKubernetesで動くように運用してみたそうです。Nulabではコンテナのノウハウが蓄積されているので、効率よく進めれたそうですね。 しかし、kubernetesで運用していくと、ControlPlaneの面倒を見るのが手間になってきます。そこで、マネージドサービスであるEKSを使いはじめたそうです。
どういった点にメリット/デメリットがあるのか知るために、既存と新規をNginxを通して平行提供したそうです。 運用を進めることでkubernetesやEKSのノウハウが蓄積され、BacklogにEKSを検討する材料を手に入れることができます。
感想
Nulabさんの取り組みで勉強になったのは「小さなところから検討したい技術を導入し、ノウハウを蓄積する」ところです。
社内で実績がない技術をプロダクトとして導入するには、それなりに調査する必要があります。
また、その技術に明るい人がいれば導入までの工数は短くなると思いますが、大抵の場合、そういった人は少ないはずです。
そこで、Nulabさんのような取り組みをすると、低いリスクで大きなリターンが得られます。
小さいところからスタートするので、失敗してもリスクは少なくて済みますし、
運用ノウハウが蓄積できれば、拡大できます。
私も、プロダクトへ何度か提案したことがありますが、今回のポイントも検討してみたいなと思います。
※ 下記のレポートもご参考下さい aws.amazon.com
全体感想
AWS Summit Osakaは今回が初めてだそうです。前回は震災の影響で中止になったみたいです。
AWSは、私がはじめて触ったクラウドサービスなので、今回参加してみました。
Sumerianってものを知りませんでしたし、マイクロサービスデザインパターンも知りませんでした。
こういう大規模なセミナーでは、様々なジャンルのセッションが集まっているので、全く知らない領域のセッションを受けてみたり、よりDeepなセッションを受けたりと面白いです。
関西に住んでいる私にとっては、こういった大規模セミナーは中々珍しいので、とてもありがたかったです。
【増枠】Mix Leap Study #45 - Google I/O、WWDCまとめて報告会！ 2019年6月15日参加レポート
今回は、ヤフー株式会社主催の下記セミナーに参加してきました。 Google/Appleどちらも大好きで、けど海外カンファレンスにいけなかった私にとって、今回の報告会は新鮮な内容ばかりでした。 その内容を記事に書こうと思います。 yahoo-osaka.connpass.com
hashtagはこちら twitter.com
- Google I/Oとは？
- WWDC（Worldwide Developers Conference）とは？
- Google I/Oの概要とMLKitのアップデート 加藤 貴晴さん
- Googleアシスタントの他プラットフォームへの拡張方法の紹介 一円 真治さん
- What’s WWDC? / Swift UI ’n Siri Recap 田中 達也さん
- AR・ML・その他Appleプラットフォームのアップデート 林 和弘さん
- 最後に
Google I/Oとは？
Googleが主催する、開発者向けイベントです。 Google I/Oでは、WEBやGoogleが出しているガジェットなど様々な技術情報についてセッションが行われています。 https://events.google.com/io/
※ https://yahoo-osaka.connpass.com/event/132601/
WWDC（Worldwide Developers Conference）とは？
Appleが毎年開発している、開発者向けイベントです。
WWDCでは、appleの新製品の紹介や新しい技術についての発表が行われています。
https://developer.apple.com/wwdc19/
※ https://yahoo-osaka.connpass.com/event/132601/
ヤフーでは、google I/OとWWDCの両方に約30名の社員が参加したそうです。 すごい数ですね。
Google I/Oの概要とMLKitのアップデート 加藤 貴晴さん
Google I/Oの概要
Google I/Oが始まったのは2008年からで、毎年開催しているそうです。 今年は2019年なので、11回目になります。
今回は全部で164セッションありました。 その内のTOP3が下記のとおりでした。
- Android 64
- Web 39
- ML/AI 32
Web好きの私としてはTOP2というのが悔しいですね。(笑) ML/ALが3番目とは驚きです。
Deplex on the web
www.gizmodo.jp ウェブベースでも使えるGoogleAssistantのことで、レンタカーや映画の予約ができるみたいです。 これのすごいところは、レンタカーを予約するまでのステップを全て自動入力してくれるみたいです。 そこまで便利になったのかと驚きました。 ちなみに、日本にはまだ対応していません。
WebAuthn
パスワードレスな生体認証のことを指すそうです。 こちらについてのセッションが下記のようです。 developers.google.com
ひとまず知ることができてよかったです。
ML
ML Kitの発表があったそうです。 developers.google.com
その中でも、翻訳APIについて報告会では熱く話されていました。
ML On-Device Translate API
デバイス上で翻訳することができるようになります。
そのため、外部とのやり取りができない環境でも翻訳できます。
つまり、オフラインでも動作します。
また、59言語に対応しているというすごい数です。 firebase.google.com
一部無料で使えるとのことで、こういうスタンスは本当に大好きです。 firebase.google.com
※ 翻訳する際は中間に英語を挟むような作りになっているみたいです。
AutoML Vision Edge
こちらもEdgeというデバイス、つまりはAndroid端末上で動作するカスタム機械学習モデルを作成できるサービスです。
ここで注目したいのは、またしてもデバイス上(On-Device)で動作する点です。
Googleではこのデバイス上で完結する方針を、これからも進めていくのでしょうか。
On-Deviceだと、どうしてもデータをデバイス上に保存する必要があります。 そのため、保存すべきデータをいかに軽量にするかという問題があります。 オフライン環境でも動作できるようになれば、災害時や緊急事態には役立ちますよね。 Web好きなら知っていると思いますが、PWAという技術があります。 こちらにもOfflineModeという機能があり、こういったOn-Deviceの先駆けとなっていたのでしょうか。
Googleアシスタントの他プラットフォームへの拡張方法の紹介 一円 真治さん
いろいろとお話されていたのですが、下記の内容が一番衝撃でした。 japanese.engadget.com
Googleはまったくあたらしい音声認識と言語理解モデルを開発し、100GB必要だった学習モデルを0.5GB以下まで削減したとしています。これにより、学習モデルをスマートフォン内部に格納できるようになり、AI機能の動作にネットワーク接続不要に。この結果、ほぼ遅延なくデバイス上で音声認識が行えるようになるとのことです。
またしてもデバイス上ですが、GoogleAssistantを動かすのにモデル作成が必要みたいです。 それにかかる容量が100GBも必要だったものを0.5GBまで削減したという衝撃的な発表があります。 また、AI機能の動作にネットワーク接続が不要とのことなので、必要なデータをダウンロードできていれば、オフライン環境でも動作できます。
What’s WWDC? / Swift UI ’n Siri Recap 田中 達也さん
SwiftUIについて
WWDCで発表されたSwiftUIは、WWDCを参加していた人みんながめちゃくちゃ盛り上がったそうです。 Swiftであんまり開発したことがないので、ほぼ想像で話しますが、 従来のSwiftによる開発は、ソースコードをビルドして、端末にビルド後のデータを移動させて動作確認する必要がありました。 そこを、SwiftUIはわざわざ端末にデータ移動せず、xcode上でpreviewできるという開発者にとって、とてもハッピーな機能がついたようです。
SwiftUIってどうやって使うの？
swiftUI自体は動かせますが、動的プレビューを使うためには、osのバージョンをとあるbetaバージョンまで引き上げる必要があるそうです。私はそれができませんでした。
— silverbirder (@silver_birder) June 25, 2019
この件について登壇者さんに質問してみました。そのとおりとのことです。 swiftUIを手軽に動かしたい場合は、playgroundでも試せるそうなので、近い内にやってみようかなと思います。
ショートカットアプリ
標準でiphoneにインストールされるようになったアプリで、正直あんまり使った覚えはありません。 他アプリとの連携が用意になったらしいので、アプリ開発の幅が広がりますね。 （すみません、SwiftUIのことばかり考えていました（笑））
AR・ML・その他Appleプラットフォームのアップデート 林 和弘さん
内容的には動画があったほうがわかりやすいのですが、 都合上見せれないものばかりだったため、なんだかモヤっとした内容でした。（笑）
ARについて
ARKit→ARKit2→ARKit3の順で進化してきたのですが、動画がなく、ふ〜んってなってしまいました...。
Authentication
「sign in with apple」という内容に私は惹かれました。 AppleのIDで認証ができるようになります。 特に、JSライブラリや、REST APIの提供もあるそうです。
JSライブラリ https://developer.apple.com/documentation/signinwithapplejsdeveloper.apple.com
REST API https://developer.apple.com/documentation/signinwithapplerestapideveloper.apple.com
良いっすね〜！これで認証の種類が増えました！
最後に
Google I/OやWWDCには参加したいという気持ちがあるのですが、 やはり英語のちからがまだまだ自信がありません。 徐々に聞き取れるように勉強していきます。 note.mu
今回の報告会で何度も耳にした「デバイス上で動作、オフライン環境」は、 今後、Googleでは力を入れていきたいのかなと思いました。 いま私ができることは、無料で使えるML On-Device Translate APIを試すぐらいかなと思います。 あとは、今と同じで継続して技術情報に対して、アンテナを貼り続けるぐらいでしょうか。
ヤフーの社員さんたちは、こういった新技術に対してキャッチアップする姿勢が積極的で良いなと思います。 私も負けないように頑張りたいと思います。
【大阪・梅田】Kubernetes Meetup Tokyo #19 大阪サテライト- 2019年5月31日参加レポート
大阪からKubernetes Meetup Tokyoに参加できるとのことで、こちらに参加してきました。 Kubernetesの生みの親である3人の内の1人のJoe Bedaから、Kubernetesの歴史の経緯について教えて頂きました。 その話がとてもわかりやすく、なるほどなと思ったので、ぜひとも共有したいと思います。
※ 以降の内容は、私なりの解釈が入っており誤った認識かもしれません。ご了承下さい。 発表の内容は全てYoutubeにありますので、そちらが正しいものです。ご参考下さい。 www.youtube.com
Who is Joe Beda ?
Joe Beda は、Kubernetes の co-founder（共同創設者/最初に開発した3人のうちの1人）/ 昨年 VMware に買収された Heptio の CTO / O'Reilly「Kubernetes: Up & Running」 (邦題「入門Kubernetes」）の共著者で、現在も Kubernetes をリードしている1人です。今回は、Kubernetes のこれまでと未来についてお話いただきます。
※ https://k8sjp.connpass.com/event/126207/
Kubernetesの最初のコミッターで、超有名人。 Googleで働いていたときは、KubernetesやCompute Engineを作っていたそうです。
Joeさん曰く、プラットフォームで開発する上でおもしろいことは、下記２点のバランスだと仰っていました。
- ユーザーが簡単に使ってもらえる事
- 想定していなかった使われ方があった場合の柔軟性
私なりの解釈で言うと、例えば、GCPというプラットフォームの中で、GKEを使うとします。 ボタンをポチポチするだけでクラスターが作成されますよね。簡単で使ってみたくなります。
ただ、簡単だけだと細かい要求を満たせないので、オプションを設定できるようにしたり、 カスタマイズしやすいものへ改善されていきます。柔軟性ってことでしょうか？ この柔軟性をしすぎると複雑になってしまい、ユーザーが使ってくれなくなる恐れがあります（マニアックなユーザーは残るかもしれないけど）。 そこのバランスが大切なのかなと思いました。
Joeさんの詳細な説明はこちらです。
The origins and future of Kubernetes (en/英語)
Joeさんは英語で話されてました。 CPCAmerica(?)の田中さんが通訳をされていたのですが、ものすごくわかりやすかったです。感謝です！ あと、記憶力はんぱねぇ...。
通訳さんの記憶力すごい…… #k8sjp
— Yusuke KUOKA (@mumoshu) May 31, 2019
※ 以下、@apstndb さんの要約Tweetを参考にしました。神!!!
@apstndbさんの訳がわかりやすくて、めっちゃ見てる。
— silverbirder (@silver_birder) May 31, 2019
#k8sjp #osaka
kubernetesの歴史
Borgの誕生
Googleでは、BigDataを処理するためのMapReduceを開発していました。 MapReduceを扱うために、GlobalWorkQueue(GWQ)というものを開発され、これは主にバッチのために作成されたものでした。そこからバッチだけでなく、リアルタイムに実行したい(検索など)サービスに対応するために生まれたのがBorgだそうです。 Googleのような大規模な検索であれば、数％の効率Upでも大きなコスト削減につながるメリットがあります。 これが、Kubernetesの元となりました。
Kubernetesの誕生
GoogleでBorgを開発を進めていく中で、世の中は仮想マシンを扱うユーザーが多かったそうです。 Borgはプロプライエタリなソフトウェアだったため、Borgの世界を知ってほしい、開発者を引き込みたいという願いから、 OSSとしてKubernetesが誕生しました。 またKubernetesは、APIドリブンで開発者の生産性を上げるというのが先で、効率やセキュリティは後からついてきたそうです。
Kubernetesの魅力
Kubernetesとは、「コンテナオーケストレーター」と多くの人は知っていると思います。普及した大きなポイントですね。 他の観点で「１つのデータベースだけでクラスタを管理している設計」が魅力的だという話がありました。 （勝手な解釈かもしれません。すみません）
Kubernetesでは、クラスタの状態を管理するために分散型KVSであるetcdを使っています(その他の状態管理はキャッシュしているそうです。)。 etcdには、APIServerを経由しなければアクセスできないため、一貫したデータの維持が実現できます。 そのetcdの周りにある、ビジネスロジックを実現するコントローラー(Scheduler, Controller Manager)が価値を提供します。 例えば、PodをNodeにアサインしたり、エンドポイントを提供したり、レプリケーションしたりなどなど...。
kubernetesのcontrol planeである、APIServer, Scheduler, Controller Managerがあれば、シングルノードでもマルチノードでも動きます。 kubernetesをDockerForMacで動かしたときは、そういえばシングルノードでしたね。マルチノードってイメージでしたけど。
Kubernetesはコンテナオーケストレーションとよく言われますが、事前にすべてがプランされたオーケストレーションではなく、ジャズのように即興で計画して組み立てていくものに近い思想だそうです。 私は音楽に疎い人なのですが意味は理解しました。（笑）性格的には即興は苦手っす。
CRDとOperators
PodやReplication,Deploymentなど様々なリソースがあります。 ただ、Kubernetes が持っていないものを実装するにはどうすればよいのでしょうか。 そこで、Custom Resource Definitions (CRD)です。 なんだそれは...?
要は、PodやDeploymentのようなリソースを独自に作ることができるのですね。おぉなんだそれ！ 独自に機能を作るためには、Custom Resource と Costom Controllerが必要になり、両方をあわせて Operatorsというものが生まれました。
例えば、下記のようなものがあります。 github.com github.com
Yahooでは、gimbalというOSSを使ってKubernetesを導入したみたいです。 github.com techblog.yahoo.co.jp
詳しくは分かりませんが、こういった拡張しやすい機能があるおかげでドンドン普及するのだなと勉強になりました。
Q&A
Q1. StatefulSets には今回触れられなかったが、どういう扱いなのか
StatefulSets には今回触れられなかったが、どういう扱いなのかという質問。
— _ (@apstndb) May 31, 2019
StatefulSets はデータベースなどに使えるが、 Kubernetes のように動的に変化する環境で何が起こるかを理解して使う必要がある。 Operators のようなものを使う必要もあると。#k8sjp #yjmu
Q2. スケーラビリティに関して
回答が難しい…
— _ (@apstndb) May 31, 2019
スケーラビリティに関してはノード数5000台を現在の目安にしているが、 Pod 数とかによっても変わる。
必要に応じてマルチクラスタでシャーディングして解決することも考える必要がある。#k8sjp #yjmu
Q3. Kubernetes はなぜ etcd を使っているか
Kubernetes はなぜ etcd を使っているか。Kubernetes が etcd を使っているところで Borg は Google internal な Chubby を使った。OSS でいう ZooKeeper でいわゆる Paxos ベースですね。#ymju #k8sjp
— _ (@apstndb) May 31, 2019
Kubernetes ではロジックを含んだ DB は避けたかったが、一貫性は必須だった。 ZooKeeper も検討したけど非常に複雑なので、当時 CoreOS が開発していた etcd を採用した。
— _ (@apstndb) May 31, 2019
もしもやりなおすとしても etcd を選ぶだろうけど、差し替えられるようにすることは考えたかもという話。#ymju #k8sjp
Controller が使うことを考えると、 etcd における変化を watch できる機能が重要だったという話 #ymju #k8sjp
— _ (@apstndb) May 31, 2019
Q4. Virtual Kubelet とか k3s みたいなエッジで活用する動きがコミュニティでは感じられるが、どう見ている?
Virtual Kubelet や k3s は既存の Kubernetes のコンポーネントではうまく要件を致さないようなところでコンポーネントを置き換えることで要件に対応する。これは API ドリブンな Kubernetes の設計をうまく生かしている。#ymju #k8sjp
— _ (@apstndb) May 31, 2019
Kubernetes はデータセンターの中で動かすことが前提なので、 IoT のエッジで動かすものとしてはベストなのかは答えが出ていないという感じ#ymju #k8sjp
— _ (@apstndb) May 31, 2019
そのほか
参加者からの質問は、どれも鋭いものばかり。 適度な質問をしたいなとつぶやきました...。届かなかったけど...。
kubernetesの正しい発音を聞いたら笑われるかな。
— silverbirder (@silver_birder) May 31, 2019
#k8sjp #osaka
Osaka会場
会場提供は、株式会社Aimingさんでした。
会場場所は、グランフロント大阪タワーBの18階にありました。(高い!) 今回使わさせて頂いた場所は、会議室でしょうか。 30,40人ぐらい入れるスペースで、清潔感がありました。
東京との中継は、ときどき音声が途切れてしまうときもありますが、しっかりと写っていました。 ただ、コンテンツとしては、YouTubeにあげらているので、わざわざOsakaに出席しなくても良いのでは？とも思いました。
しかし、それでもOsakaに出席しても良い面もあるのかなと思います。
- 他の方とのコミュニケーションが取れる
- 一緒に発表を聞いて議論ができる
まあ、私はコミュ障なので、ほぼなかったですが...。
改善ポイントとしては、中継地からも質問ができるようになってくれたら良いなと期待しています。
最後に
Kubernetesについて、どういった経緯で誕生したのか、またCRDについても勉強になりました。 また、Kubernetesとは違うのですが、「OSSのちから」というものがエンジニアの世界では大事だと強く感じました。 普段エンジニアが開発する上で、ほぼ間違いなくOSSを使っています。 エンジニアにとって、OSSは不可欠な存在であり、利用するばかりです。
Googleがしたように、「広く使ってほしい、エンジニアを巻き込みたい」という願いから、 OSSとしてKubernetesが広まっていった一要因と思いました。これが有償ならどうだったのでしょうか。 ここまで普及したのでしょうか。
OSSに貢献する企業は、日本にも多く存在します。 個人でもOSSへ貢献できますし、OSS Gateという初心者向けのものもあります。 Kubernetesのコントリビューターは、ちょっとハードルが高いですが、 私もエンジニアとしてOSSへ貢献し続けていこうと思います。
そのほか
拙い文章なのに、最後まで読んでいただき、ありがとうございます。 twitterをしていますので、フォローしてもらえるとうれしいです。(silver_birder)
