JFrog Japan Blog

DevOpsを加速する、JFrog日本法人メンバーによるブログです。

JFrog ArtifactoryやXrayといった自社ツールはもちろん、CI/CDやコンテナ技術(DockerやKubernetes)などDevOpsの一般的な内容も扱います。
その他、日本でのDevOps事例紹介やお楽しみコンテンツも掲載予定です。 JFrogならではの面白くて役に立つブログを目指しますので、お楽しみに!

Java 開発者のための次世代 DevOps: BinOps

JFrog DevOps Acceleration Engineer 三宅です。

先日(といってもだいぶ経ちますが)JJUG CCC 2020 Fall (#jjug_ccc) にて「開発者がバイナリを中心とした開発フローを意識すると何が嬉しいのか?」についてご紹介してきました。ここではその内容を要約してご紹介したいと思います。

ソースコードと共にインフラコードも全て Git で管理する GitOps が脚光を浴びはじめています。この GitOps という言葉は皆さんも馴染みがあるのではないでしょうか?

運用 (Ops) の役割を開発 (Dev) に寄せていくというのは DevOps の成功に欠かせない要素です。GitOps はそのような背景で誕生し "Git as the source of truth" が根本の考え方になっています。一方、アプリケーションのライフサイクルや DevOps の真の実現を考えた際には、本当にソースコード「だけ」を管理すれば最適なソリューションとなるのでしょうか?

本セッションの内容は "BinOps" と呼ばれるバイナリやアーティファクトに焦点を当てた DevOps の実現方法 "Binary as the source of trush" の新しい考え方を特に Java 開発者の立場から理解してもらえるように作成しました。

私自身も開発の経験が長く、開発者にとってソースコードが舞台の中心であることはよく分かります。そのため実は JFrog にて本格的にバイナリを中心とした DevOps に触れる前は、ビルドした後のパッケージやアーティファクトの管理はあくまで副次的なもの、という印象がありました。

このような経験も含めて、一度自分のまとめとして「バイナリ管理」について整理したいと思っていました。今回の発表では出来るだけ噛み砕いてバイナリ管理のメリットをまとめることができたと思っています。詳細は下記発表スライドにてご確認ください。またご質問やご意見などもお待ちしております。

speakerdeck.com

カエルと実践するコンテナ

JFrog DevOps Acceleration Engineer 三宅です。

今回は「コンテナ」シリーズ全 3 回の最終回として、コンテナを中心とした開発フローやツールの実践についてご紹介したいと思います。

第 1 回、第 2 回は特定の商用製品やツールに触れずに、それぞれ「コンテナ」「コンテナ・オーケストレーション」の概要についてご紹介しました。

blog.jfrog.co.jp

blog.jfrog.co.jp

今回はコンテナベースのソフトウェアを開発・運用する上で実際に留意すべき点、必要になるツール群などのご紹介をしたいと思います。

そもそも「ソフトウェア・デプロイメント」とは何でしょうか? 定義としては「ソフトウェアを使用可能にするあらゆる活動」ですが、具体的には「プロセス」と「アーキテクチャー」から成り立ちます。「コンテナ」はこのいくつか進化してきたデプロイメントの「アーキテクチャー」に関連する最新の技術という捉え方ができます。

マイクロサービスのデプロイメントにはいくつかパターンがあり、コンテナを利用するものは "Container as a service" や "Service instance per container" などと呼ばれることがあります。

このアーキテクチャーを実現するために要となるのが「コンテナ・レジストリ」と呼ばれるツールです。Docker Hub やクラウドベンダーをはじめとする色々なコンテナ・レジストリが世の中に存在しています。

今回は「クレジットカードなし」でずっと(一年間などの制限なく)無料で使い続けることができる JFrog Artifactory の SaaS サービス やオンプレミス用のフリーのツール JFrog Container Registry についてご紹介致します。その特徴やコンテナ管理に止まらない「バイナリ全体を管理する」という新しい概念に触れていただければ幸いです。

以上、詳細は下記ウェビナーの内容にまとめてありますのでぜひご覧ください。

www.youtube.com

speakerdeck.com

何かご質問などあれば、どしどしお寄せください。

それでは、また次回お会いできることを楽しみにしております!

猿でもわかるコンテナ・オーケストレーション

JFrog DevOps Acceleration Engineer 三宅です。

今回は Kubernetes をはじめとするいわゆる「コンテナ・オーケストレーション」の話をしたいと思います。「コンテナ」シリーズ全 3 回のうちの第 2 回目となります。

第 1 回目は「コンテナ」の概要や歴史、それを支える OS の技術などをご紹介しました。

blog.jfrog.co.jp

コンテナは「リソースが分離されたプロセス」であり、OS レベルの仮想化にカテゴライズされるテクノロジーであることをご紹介しました。その「プロセスの隔離」を実現するための技術的な詳細についても触れました。

コンテナを使えばリソースを効率的に管理できるので、アプリケーションのデプロイに用いられる機会も増えてきました。ただアプリケーションが複雑になってくるとそれを構成するいわゆる「マイクロサービス」の構造も複雑になってくるため、これらがデプロイされる単位であるコンテナの数も膨大な数になってきます。この複雑で大規模になったコンテナを管理するためのツールが「コンテナ・オーケストレーション」です。

コンテナ技術と垂直・水平方向のスケールの歴史、また API とアーキテクチャーを中心に Kubernetes の基礎的内容を下記ウェビナーにてご紹介しましたので、ご興味あれば参照いただければと思います。

www.youtube.com

speakerdeck.com

何かご質問などあれば、どしどしお寄せください。

それでは、また次回お会いできることを楽しみにしております!

猿でもわかるコンテナ

JFrog DevOps Acceleration Engineer 三宅です。

今回から全 3 回に渡り「コンテナ」について紹介したいと思います。

まず第 1 回目は「コンテナ」の概要や歴史、それを支える OS の技術などを振り返りながらご紹介します。

  • コンテナとは?
  • アプリケーションの分離
  • コンテナを支える技術と歴史
  • イメージとは?
  • まとめ

一言で「コンテナ」と言っても、色々な見方があると思います。まずは多くの方がそうであるように「コンテナを利用する」側の見方があります。例えば開発者に取っては運用者にアプリケーションをハンドオーバーするときの「便利な箱」にもなるでしょうし、3rd パーティーのコンテナを利用するユーザーからすると Dockerfile が簡単なインストール手順書にもなるのではないでしょうか。

一方、「コンテナを実装する」側の見方もあります。なぜコンテナの中ではファイルシステムやプロセスやネットワークが制限されているのでしょうか? コンテナが「分離するもの」とはなんでしょうか? そのカラクリはどうなっているのでしょうか?

実はコンテナの歴史は長く、筆者が以前在籍していたサン・マイクロシステムズの商用 UNIX OS の Solaris に搭載された Solaris Container がリリースされたのが 2004 年、今から 15 年以上も前のことになります。そのコンテナの歴史も気になるところです。

現在のコンテナ技術は Linux をベースにしたものが中心でしょう。この Linux 上でコンテナ技術を実装するには Linux Namespaces や Linux Control Groups (cgroups) の理解が大切です。またイメージの技術は Union File System を土台にしています。

これらの詳細な内容を先日、弊社ウェビナーでご紹介致しました。当日は 200 名近くの参加があったようです。ご参加いただいた皆様どうもありがとうございました。また当日の録画とスライドは下記にありますので、振り返ってみたい方、見逃した方など適宜参照いただければ幸いです。

www.youtube.com

speakerdeck.com

何かご質問などあれば、どしどしお寄せください。

それでは、また次回お会いできることを楽しみにしております!

自動車もソフトウェアの時代。ITインフラの絶え間ない改善で世界中の開発者を支える―Woven Planet Holdings様インタビュー

We have the English version as well. Read here :)


こんにちは、デベロッパーアドボケイトのよこなです。
今回は新企画、JFrogのお客様にお話を伺うインタビューです。製品の活用術はもちろん、DevOpsへの取り組みやチームの印象的なエピソードなどをたっぷり聞いていきます。

記念すべき第1回目はウーブン・プラネット・ホールディングス株式会社(Woven Planet Holdings)様にお話を伺いました。

www.woven-planet.global

インタビューを受けて下さったのは、Infrastructure Engineeringチームよりヤンさん、守屋さん、そしてそしてArene Toolsチームよりエトウルノーさんです。

現在、自動車業界は100年に1度の転機が訪れていると言われています。品質の高い乗り物を作るのみならず、自動運転やコネクテッドカーなどの新しい技術を取り入れたサービス展開が重要になってきます。日本はこれまでも自動車産業で世界的に成果を上げてきましたが、次の時代はどのように戦っていくのか、興味深い局面を迎えていますよね。そんな中、Woven Planet Holdings様がどんな考えを持ち、ソフトウェアとどう向き合っているのかを色々と教えていただきました。

まずは、参加して下さった方を改めて簡単にご紹介します。

  • ジャック ヤンさん - Jack Yan: Senior Director
  • 守屋 哲さん: Senior Engineer
  • グウェン エトウルノーさん - Gwenn Etourneau: Senior Infrastructure Engineer
    (以下、本文では敬称略、名字のみ記載しています。)

f:id:ihcomega:20200925104543j:plain
ジャック ヤンさん


これからの自動車産業を支えるソフトウェア。迅速な改善を続けるには、マインドセットの変革が欠かせない

―Woven Planet Holdings様の事業について教えて下さい。

ヤン: Woven Planet Holdingsは、2018年3月に設立されたトヨタ・リサーチ・インスティテュート・アドバンスト・デベロップメント株式会社(Toyota Research Institute - Advanced Development, Inc.(TRI-AD))を前身として、2021年1月に設立されました。「Mobility to Love, Safety to Live」をビジョンとし、既存の枠を超えた大胆な変革と新たな価値提供の加速化を目的としています。自動運転に関連する新しい技術と、先進的で安全なシステムを世界中の人々に届けることがミッションなんですね。 また、最近ではスマートシティのデザイン、コネクテッドモビリティ、ロボティクスの技術をトヨタやパートナーの方々と実証する場である「Woven City」にも携わっています。

―次世代の生活を支えていくようなわくわくする事業ですね。
自動車というとハードウェアのイメージが先行する人も多いと思いますが、扱っているのは主にソフトウェアですよね。

ヤン: そうですね、Woven Planet Holdingsはソフトウェアの会社です。例えば、自動運転用のマッピングプラットフォームに用いるようなソフトウェアを開発しています。ハードウェアの製造は行っていませんが、ソフトウェア提供のためには当然ハードウェアのことも考え、共に歩む必要があります。 我々が日々開発しているソフトウェアのうち、自動車そのものに搭載しているのは1割程度です。それ以外の9割は、ソフトウェアを開発したり自動車にソフトウェアを展開したりするためのソフトウェアツールが占めます。

―なるほど。自動車というと専門知識も多く難しそうですが、社員の皆さんは自動車関連の経験をお持ちの方が多いのですか?

ヤン: トヨタ自動車やデンソーなど関連会社からの出向で、自動車業界の知識を持っている人は多いです。一方で、金融業界だったりソフトウェア開発会社だったり、他の業界から来た人もいますよ。自動車業界とソフトウェア業界それぞれの知識を組み合わせて活かしていく必要がありますね。

―様々なバックグラウンドの方々が力を発揮出来る環境なのですね。これについてはまた後ほど詳しくお伺いしたいです。
続いて、皆さんの業務について詳細をお伺いします。普段の業務では主にどういったことを担当されていますか?

ヤン: 我々Infrastructure Engineeringチームは開発に必要なツールを管理しています。JFrog Artifactoryはそのうちの一つですし、それ以外には例えばソースコードを管理するVCSを提供しています。こうしたツールの提供によって、製品を作っている開発者の生産性を向上させることが我々の使命です。 また、クラウド環境の管理も担当しています。開発者が日々不自由なくクラウドを活用出来るよう、クラウドリソース管理の自動化を行っています。

―どういった人と関わりながらお仕事を進めていくのですか?

エトウルノー: Woven Planet Holdings社内の開発者、そしてトヨタ自動車のような他の会社の開発者という二つに大きく分けられます。関わる開発者とは毎日のようにコミュニケーションを取りながら作業を進めています。今は社内向けの活動が多いですが、ゆくゆくは我々のプラットフォームを外部にも公開していきたいと考えています。

―では、そうした仕事をする上で難しいのはどんなところですか?

ヤン: 自動車を扱っていると、多くのカスタマイズされたハードウェアと向き合うことになります。それらと開発ツールのインテグレーションは難しい点の一つですね。

エトウルノー: しかも、安全性を担保した上で実現しなくてはならないですしね。最終的には自動車の上で動くアプリケーションの開発を支えているので、安全性について考え続ける必要があり、それもまた難しいところです。

―課題と向き合うためには何が必要でしょうか?導入している便利な武器や道具はありますか?

エトウルノー: 例えばCI/CDパイプラインのような便利な仕組みは取り入れていますが、大事なのは道具そのものというよりもマインドセットなんですよ。CI/CDの場合、問題が発生した時には何が起きたか追跡出来るようにしておきたいので、ある程度の期間ログを保存しておく必要があります。これは自動運転のシミュレーションにも同じことが言えるんですが、何かを遡ってトレースする、それが出来るようにしておくという考え方が重要ですね。

―他にも仕事に関する難しいところはありますか?

ヤン: 社内の開発者を支えるという観点だと、チームがDevOpsをスムーズに導入するための支援も行っていますが、それも難しい点と言えるかもしれません。

守屋: 従来の自動車業界ではウォーターフォール式の開発を行ってきたので、DevOpsを取り入れた文化に変えていく必要があります。その移行に苦労している開発者もいますね。

―そういったカルチャーを変えていく動きは大変でしたか?社内で反対する意見があったり、説得のために尽力したりする必要があったのでしょうか?

守屋: 現状のままが良いというような意見は聞いたことがないですが、それでも考え方をかなり変えないといけないので、そこに大変さはありますね。一度に全てを変えるのは困難なこともありますし、一歩一歩取り組んでいます。

エトウルノー: そうですね。そして、DevOpsを取り入れるだけではなくやはりマインドセットの変化が大事だと思います。よくアジャイル開発の文脈で議論されるように、組織やプロジェクトの進め方を変えていく必要があります。 こうした動きはチームにとどまらずグローバルな方向性と言える気がします。我々のようにごく一般的なソフトウェア扱う時のみならず、自動運転に関わるような開発においても同じようなマインドセットが取り入れられるといいなと思います。シリコンバレー風ですね。そのために弊社ではアジャイル開発を学べるトレーニングもありますし、ツールの使い方やインテグレーションの仕方についても共有をしています。

―多種多様な人が集まる中で、ベースとなるマインドセットが醸成されているのは当たり前のことではないですもんね。Woven Planet Holdings様はそこを大事だと捉えて工夫されていることがよく分かります。
さて、アジャイルの話が出たところで、それについても深堀りしていきます。アジャイル開発やリーン開発においてよく語られるTPS(トヨタ生産方式)は非常に有名ですよね。Woven Planet Holdings様の開発においてもTPSは取り入れられていますか?

ヤン: 今はアジャイル開発を取り入れていますが、問題が発生したら生産ラインを止めてそこで解決するという点ではTPSと非常に似ていますね。また、ソフトウェア開発を継続的に良くしていく「カイゼン」の原則を大事にしています。トヨタがTPSを用いて自動車製造業で成功を収めたように、ソフトウェア開発が上手くいくよう努めています。

f:id:ihcomega:20200925104520j:plain

―開発で取り入れている具体的な手法やフレームワークなどは何かありますか?

ヤン: スクラムのフレームワークを導入し、2週間ごとのスプリントを回しながら作業しています。最近はリモートワークを行っているので、スクラムイベントはビデオ会議で行っています。

―では、アジャイルにカイゼンを続けていくために、開発者はどのようなスキルセット、マインドセットを持つべきだとお考えですか?

ヤン: 伝統的なソフトウェア開発では、数ヶ月や数年に渡るようなプロジェクトを遂行し、最終的な完成品をリリースすることを目指していました。しかし、アジャイルに開発を進めるには、リリースをより小さな塊で迅速に行い、素早くフィードバックを得られるようにする必要があります。こうしたマインドセットを持つこと、それに向けて変化していくことが重要だと思いますね。

エトウルノー: ヤンの言うように、マインドセットは本当に大事です。ウォーターフォールでの作業に慣れていると、基本的には一つのタスクに取り組み、それが終わってから次のタスクに移るといった方法で作業をします。しかし、アジャイルの世界では、同時並行で複数のタスクを行う必要も出てくると学ばなくてはなりません。 小さな単位で頻繁にリリースすることでユーザーからのフィードバックサイクルを短くし、問題を修正して再適用したり、方向性を改めたりすることが出来ます。

継続的デリバリーで社内の開発者の効率を上げる。Woven Planet Holdingsのインフラを支えるDevOpsの姿とは

―続いて、DevOpsについてお伺いしていきます。導入として、どのようなことを目指して日々作業しているか教えていただけますか?

エトウルノー: チームの目指すところとして、開発者がより多くの時間を開発に充てられる状態を実現することが挙げられると思います。開発者が必要なツールをセットアップしたり良いプラクティスを探したりすることに時間を割いて欲しくないんですよね。例えば彼らが自らプロビジョニングをしたりとか、そういったことは避けたいです。つまり、ツールやそのベストプラクティスは我々の方から提供して、開発作業に集中してもらう時間を増やしたい、効率的に作業を進めて欲しいと考えているのです。

―皆さんはサービスを作る開発者を支える存在なのですね。そうしたツールのリリースはどのくらいの頻度で行えるようになっていますか?

エトウルノー: 我々が扱うインフラツールについては、自動化されたパイプラインにより数時間以内にリリース出来るようになっています。ダウンタイムもほとんどありません。コードをプッシュしてから開発環境、ステージング環境、そして本番環境に至るまでリリースはほぼ自動で行われます。このように継続的インテグレーションと継続的デリバリーを実現しているのですが、ここが我々の頑張りの表れと言えるところだと思います。 ただ、プロダクトのリリースはまた事情が異なりますし、チームによっても様々です。

―大半が自動化されて継続的デリバリーまで実現されているのはすごいですね。そうした仕組みやDevOpsの導入は創業当時から続いているのでしょうか?

ヤン: そうですね、始めから取り入れられていました。CEOのJames Kuffnerがシリコンバレー出身なのもありますが、アジャイルもDevOpsもデファクトスタンダード扱いですね。

―そうした先進的な取り組みをされる中で、JFrog Enterpriseをお使いいただけていることをとても光栄に思います。ありがとうございます。よろしければ選定理由を教えてください。

ヤン: シリコンバレーにある、自動運転の先行研究をおこなうトヨタ・リサーチ・インスティテュート(TRI)とは密に連携して業務をしています。TRIがArtifactoryを使用しているので、同じツールを採用しました。

―JFrogをどのように使っているかについても簡単に教えて下さい。長所や短所もあればぜひお聞かせください。

守屋: 主にCIパイプラインで生成したアーティファクトを保存するのにArtifactoryを使っています。 長所はたくさんありますが、安定していることだと思います。課題として思いつくのは、インフラエンジニアの視点からするとパーミッションの管理が複雑な点です。細かいパーミッションが設定出来るのですが、量が多すぎて管理が大変だと感じます。また、Artifactoryはソースコードが公開されているわけでなくブラックボックスなので、自分たちでトラブルシューティングするのが難しいことも挙げられます。

―ありがとうございます。生の声を聞くことが出来て嬉しいです。

生み出した「カイゼン」の成果をトヨタ全体―すなわち世界中へ広げていける可能性と面白さ

―さて、最後に人やチームについて伺いたいです。どのような方が集っていらっしゃるのですか?

ヤン: 多様なメンバーで構成されていますよ。例えば今日参加しているメンバーだと、守屋さんは国内の大手電機メーカーで社内プラットフォームや開発ツールを担当していたそうです。エトウルノーは暗号通貨の会社でインフラのDevOpsを推進した経験を持っています。

―色々なバックグラウンドの方が集う環境なのですね。そうした方々が入社後すぐ溶け込む秘訣はありますか?

ヤン: まず会社全体の話をすると、HRチーム主導で行っている標準の入社後プログラムがあります。また、「Dojo(道場)」と呼ばれる社内でトレーニングを実施するチームも存在し、そこではスキルアップのために様々なコースを受けることが出来ます。オンボーディングのプロセスはかなり充実した良いものになっていると思いますね。

f:id:ihcomega:20200925104147j:plain

―入社前から備えているべきことはあるのでしょうか?採用のポイントも簡単に教えてください。

ヤン: 会社の公用語が英語であり、多くの海外から来たエンジニアと仕事をするので、グローバルな仕事の経験や視点を持っていることは大事だと思います。技術的な観点では、インフラ、自動化、クラウドなどの知識や経験を見ています。

―それら全てを満たす方を採用するのはなかなか難しいのではないでしょうか?

ヤン: おっしゃるとおり、技術力がありバイリンガルで、かつ文化的にもマッチする方を見つけるのは簡単なことではありません。ですが、会社にもチームにも強いミッションがあり、それに共感してもらえること大切です。嬉しいことに、世界中から多くの応募者が来てくださっています。

―確かに、お話を伺っていても先進的なことを当たり前のように取り組んでいるところがとても魅力的だと感じます。自動運転やスマートシティ構想はわくわくしますし、多くの方の注目を集めているのでしょうね。 ちなみにどなたか、何故Woven Planet Holdings様にジョインしたか教えてくださる方はいらっしゃいますか?

守屋: 前職では研究をしていたので、ビジネスからかけ離れていたんですよね。今はぐっと近くなり、自分の知識をビジネスに応用してインパクトを与えられるかもしれないというのがとても刺激的ですし、学びも多いです。

―なるほど。今が充実しているだけでなく、二つのキャリアが繋がっているのも素敵ですね。 では、守屋さんの場合、ビジネスに関われていることがWoven Planet Holdings様で働く面白さと言えるのでしょうか?

守屋: そうですね。自分のやり甲斐となっているのは主に二点あるでしょうか。一つは今述べたように最新の技術を使い、その技術をビジネスに適用していくことです。もう一つは、ユーザーの文化やマインドセットを変えていくところです。これらは最も面白く、またチャレンジングな部分と言えます。

―ヤンさんはいかがでしょう?どんなことがやり甲斐となっていますか?

ヤン: 私の場合、身近な開発者の生産性を向上させること、そしてひいてはトヨタの開発を改善することに取り組んでいるという自負があります。トヨタは非常に大きな会社なので、そこに身をおいてグローバルな視点で学び続けることはやり甲斐がありますね。

―ここまで様々なお話を聞かせてくださりありがとうございます。取り組みも考え方も非常に面白く、日本のエンジニアの見本になるものだと感じました。 最後に、これからTRI−AD様のような組織や取り組むエンジニアの皆さんに向けて、何かメッセージをいただけないでしょうか?

ヤン: レガシーなシステムを運用している環境でDevOpsを取り入れるのは非常に難しいですよね。私から言いたいことは二つです。第一に、迅速なデリバリーとフィードバックを実現するには、変化や変更を受け入れる勇気が必要です。だからこそ、迅速なリリースに必要な意思決定をする準備をしておくのが大事だと思います。もう一つは失敗を恐れないことです。リスクを取らずして目標を達成することは出来ません。

守屋: 私が言えるのは「一日では変われない」ということです。一歩一歩努力していかないといけないですよね。


非常に熱量のある面白いお話を伺うことが出来ました。アジャイル開発にDevOpsと、新しい考え方を取り入れて仕組みに落とし込めているところに技術力の高さを感じさせられます。そこに到達するにはマインドセットを変えるところから、と強調されていたのも印象的です。 私の興味もありますし、きっと他のエンジニアの方の参考や励みにもなるはずなので、ぜひこれからもWoven Planet Holdings様の取り組みや事例を教えていただきたいなと感じました!

JFrogのインタビューを受けてくださるお客様を絶賛募集中です。ぜひ、こちらまでご連絡ください。