GitHub 20k+スターDevOps OSSコア開発者が語るDevOpsのススメ　JDDにおける運用と知見

JDDにおけるDevOps

Takuya Noguchi氏（以下、Noguchi）：ご紹介いただきましたJapan Digital DesignのNoguchiです。「DevOps in JDD」とタイトル発表させていただきます。

私は今年の夏にソフトウェアエンジニアとしてJDDにジョインしています。これまでは20年ほど一貫してデジタルトランスフォーメーションのエンジニアリングをやってきました。また、OSSの開発やオフラインミートアップなどのコミュニティ活動を精力的にやっています。

先ほど（Red Hatの）中島さんからお話があったOSS GitLabのCore TeamでCore developerをしています。Core Teamは世界で6人ぐらいいるんですが、日本では他にいないので、リクルーティング中です。CNCFのほうではCloud Native Ambassadorというのをやっていて、これも50人ぐらい世界にいるんですが、こちらも日本では他にいないので、リクルーティング中です。

それ以外には、開発者体験やDevOpsに関するミートアップであったり、イベントをやらせていただいております。

JDDの話はオープニングでもお話させていただきましたが「UXを中心としたイノベーションをやっていこう」という会社になります。

銀行の子会社なのでFinTech企業と認知されてはいますが、もう少し広い領域でUX全般のプロジェクトをいくつか進めているという状況です。

社員数は80人ぐらいで、エンジニアは、データサイエンティストやデザイナーも含めて22人ほど在籍しており、現在7つほどプロジェクトを進めています。

会社は2017年10月に設立していて、ちょうど1年ほどの会社です。それから、エンジニアがジョインしたのがまだ半年ぐらいで、その後どんどん増えてきています。エンジニアの平均在籍月数では2、3ヶ月じゃないかな、という会社です。

DevOpsとは何か？

ということで、JDDにおけるDevOpsといっても、Devしたものがまだありませんしプロダクションを出しているものがないため、DevOpsの話ができないんですが……。

DevOpsの基礎について、そしてDevOpsとは何かということに関してはいくつか本がありますが、『Effective DevOps』という本が一番いいかなと思っています。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

英語版ですけど、こちらの書籍の一部は、先週発表されたMicrosoftのAzure DevOpsのリリースに伴ってフリーチャプターが出ているので、Microsoftのページからもダウンロードできるようです。

DevOpsの言葉の起こりは、2009年にFlickrが「1日に10回デプロイをする」と言ったのがはじまりです。

一方で、これはFlickrやメルカリなどのいわゆるシステム・オブ・エンゲージメントと呼ばれるSoEシステムだと、1日に何回もデプロイすることがあるため、初期のDevOpsの意味での優位性を得ることができます。一方で我々の（金融サービス）事業で必要とするシステムにおいて、SoR、システム・オブ・レコードの開発・運用、SoI、システム・オブ・インサイトのようなインサイトを理解するデータサイエンスでは、この意味でDevOpsを導入すべきでしょうか。

後者の事業形態において、初期のDevOpsの目的であるデプロイを1日に何度もやるという文脈ではなく、もう少し違ったかたちで進めていく必要があります。

登場から10年経って、DevOpsは何か、という議論が再燃してきました。最近では、単純なDevとOpsとの連結というよりは、よく出てくるのがこのDevOpsの輪です。

これはPlanして、Verifyして、Packageして、Releaseして、Configureして、Monitorして、その結果をPlanにつなげていくという輪で、DevOpsライフサイクルを実現します。これを実現するためにはやはりツールチェーンが有効です。

GitLabの特徴

一方で、ツールチェーンを用意するだけでは不十分で、開発文化を良くしていくということと、一人ひとりのエンジニア、一人ひとりのOps担当者のコラボレーションが、必要不可欠になってきます。またDevOpsの担当者とのコラボレーションも必要になってきます。

そこで我々JDDでは、私が（GitLab自体の）開発者ということもありますが、GitLabを導入しました。第三者の調査で、エンタープライズでは67パーセントのシェアがあるとされています。海外では非常に高いシェアを持っているプロダクトになります。このソフト、私も開発しているので、だいたいどういうものか、かなりよくわかっているんですが、スタートアップだったり小さい企業でも非常に役に立ちます。

先ほどのDevOpsの輪の構成要素の7個はこの表の中に入っているんですが、それ以外に左右に1個ずつ、SecureとManageが追加されています。

これはGitLab側のDevOpsの定義なんですが、左側のManageで、DevOpsのサイクルがいかに効率的に回っているかを評価するというものを、ツールチェーンのなかに含めています。

それから、金融サービスを提供するうえで必要不可欠なのがセキュリティです。最近もまたいくつか問題が起きて、ニュースになっているのでご存知かもしれませんが、「DevSecOps」というキーワードも出てくるほど、セキュリティは重要になってくるので、この1個のツールチェーンで標準的にシステムのDevSecOpsを進めていくのは有効だと思います。

下に競合製品の比較があります。これを組み合わせてもいいんですが、組み合わせていく労力は少なくないので、我々のような小さな企業では、少し難しいのかなと感じています。

もう1つ、GitLabにはKubernetes連携があります。

クラウドを当たり前に使っていく現在においては、アプリケーションのコンテナ化は非常に重要です。うえで、とくに重要かなと思います。そのコンテナ化したアプリケーションを動かしていくためにはオーケストレーションが必要だということで、Kubernetesを使っていくのは非常に有効な選択だと思います。

海外の銀行・金融サービスではこれらに取り組んでいる企業も多くあります。アメリカのCapital Oneだったり、イギリスのMonzoだったり、新しい挑戦をする銀行もKubernetesを漸進的に取り入れていますが、まだ日本の金融サービスでのKuberenetes活用は公開されているものは私の知る限りないのかなと思います。

非同期的な働き方

では、原理としてはこういうかたちなんですが、JDDにおけるDevOpsについて、もう少し実体に沿ってお話ししたいと思います。

JDDについてはいろいろなメディアでお伝えしているんですが、非同期的な働き方をするのが特徴の会社です。これはどういうことかというと、よくあるのがフルタイムのエンジニアが多いと思いますが、我々は週1からの勤務や、副業でチームにジョインするということも積極的にやっています。

ですので、メンバーの平均稼働が週4日以下で、毎日必ずいるわけじゃないというチームのなかで進めています。それからリモートワークを推進していますので、オフィスにいる人もいればリモートの人もいるというかたちでエンジニアが集まっています。

また、金融機関ということもあり、レガシーなエンタープライズの側面もあります。それから少人数ですので、一人ひとりに仕事が依存してしまったりということもあります。

こうした状況のなかで、DevOpsを導入していくことによって、SPOF（単一障害点）となるようなポイントを減らしていったり、インフラをコード化したり。あとは、「複数の目でチェックしていく」というものが金融業界ではよく言われますが、複数人の目をソフトウェア開発にも取り入れるということを進めてられます。

エンジニアがDevOpsを進められる時代に

JDDにおいては、先ほどの図のスタートポイントのPlan、開発の企画の部分から始めなければいけません。Planはアーリーステージの組織のソフトウェア開発とその運用においてもっとも大事なフェーズです。

私がジョインした時は、いくつかPlanに関するツールがたくさん存在していました。Jira Softwareだったり、Confluence、Backlog、MS Project。

あとは普段のコミュニケーションはMicrosoft TeamsやSlackがあったりというかたちでした。現在はグループウェアをOffice 365に統合している関係上、Microsoft Teamsへの統合を進めています。そういうところで、普段のコミュニケーションあるいは設計において、ツールを統一していくということを順次進めている段階になります。

先ほどの（メルペイの）高木さんの話にも少しありましたが、小さな組織においてはDevエンジニアがOpsも運用もしていくのが当たり前になっていると思います。パブリッククラウドが非常に優れたインフラストラクチャーを提供してくれているので、そうしたことが実現できます。

というところで、ソフトウェア開発者がオペレーションできるような仕組みになってきているので、ソフトウェアエンジニアもDevOpsの取り組みが容易にできるようになってきてる、ということが言えます。

DNSクラウドサービスの運用について

非常に短い期間の中で最初に取り組んだJDDでのDevOpsの話をしたいと思います。ここで紹介したいのは、DNSのレコードマネジメントです。

DNSのレコードは、最近だとパブリッククラウドのプロバイダーが何社か出てきていますが、マネジメントコンソールがしっかりしていたりするので、Web UIから簡単にマネジメントできると思います。

ですので、我々も最初はそういうマニュアルの運用をしていたんですが、やはり記録を残していくということに課題がありました。マニュアルの変更で運用する限りは、「これはどういう目的でいつ誰が変更したのか？」ということがわかりませんでした。そこで、我々が導入しているGitLab CIとそれらの関連ツールを使って改善をした、という取り組みになります。

今回はGitHubのOctoDNSというものを使ってます。Terraformでも、Amazon Route 53とかGoogleCloud DNSのようなプロバイダーも提供されていますが、あとから説明しますMultiple Providerに対応していないので、この製品を選択しました。あとはGoogle Cloud DNSを使っているのですが、それはDNSSECを使いたいからという理由です。それからYAMLベースで、ということですね。

Terraformの場合、HCL（HashiCorp Configuration Language）のフォーマットが少し特殊なので、誰でもいじれないということが少し課題になることもあります。ですので、YAMLベースは多くのソフトウェアエンジニアにとって変更がしやすい良い選択かなと思っています。

Code、Merge Request、Review、Dry run、Go productionというかたちで、パイプラインを進めていきます。

ここにCodeを記載させていただきますが、一般的なCIツール、Travis CIやCircleCIと比べても、GitLab CIではコード上、簡潔に書けるので、YAMLは非常に良いなと思います。

先ほどの（Red Hatの）中島さんの話にもあった、「変更がどういう状態か？」というものを、この中段ブロック（3-4行）で、実行は下のほうのブロックでやっています。そして、マスタに取り込まれた時だけ手動でやるといったワークフローも簡潔に組めているのがお分かりいただけますかと思います。このようにソフトウェアエンジニアの担当者でもワークフロー設計が簡単にできます。

コードベースを変更したらこのようにReviewをして、diffを見て、デプロイするというのは、みなさんやっているのかなと思います。

DNSのレコードはそれほど高頻度で更新しないケースも多くあるかと思います。ですので、3ヶ月後に更新しようとしたらコードと実態の差分が発生していた、ということもあるかもしれません。そこで、そういう変更が起きていないことを24時間に1回、1日1回確認するのも、GitLab上でテストとして組み込んでいます。

他のTravis CIやCircleCIなど、その他のツールでも簡単にできるとは思いますが、ディベロッパーが簡単に設定ができて、デイリーのタスク実行を簡単にできるので、これは非常に楽だと思います。

全てのジョブパイプラインが成功と表示されていて「当たり前じゃん」と思うかもしれませんが、1日1回設定が変更されていないことを確認するようなジョブが実際には走っていて、それが問題ないということでやっています。もし問題があれば、MS Teamsにアラートがくるようになっています。

運用にまつわる2つの課題

こちらの実装は、2週間ぐらい前に終わった部分なんですが、継続的に運用していくにはさらなる改善ポイントがあります。今後の課題は2つかなと思っています。

1つはPython 2.7で書かれていて、GitHubが出しているOSS、github.com/githubの下にあるリポジトリ、みなさん触られたらわかると思うんですが、あまりメンテナンスされていません（笑）。GitHub社内からのOSSはメンテナンスされてないものがよくあるので、そういったプロジェクトがOSSになるのかなという印象もありますので、コミュニティベースのメンテナンスというかたちでなっているかと思います。たまたま私がPythonを書きたかったので、Python 3対応をやったりして、プルリクエストを出しています。なかなかマージされていませんが（笑）。

もう1つ、もともとやりたかったことが、Multiple DNS provider supportです。いま使っているGoogle Cloud DNSはSLA 100パーセントですし、他のプロバイダーのSLAも100パーセントに近い状態なんですが、やはりDNSへの攻撃によりダウンしてしまうこともあります。

大型のDDoSアタックが2016年にも起きていますし、2015年にも国内プロバイダーに攻撃がありました。ですので、複数のDNSプロバイダーにサポートしておくというのは、システムの安定性を実現するためには必要だと思っています。シェアが多いCloudflareとかDynをセカンダリーDNSホスティングとして、そのあたりを試してみようかなと考えているところです。

金融業界にはITのナレッジが求められている

というところで、立ち上がったばかりのエンジニアリング組織の内情や今後の計画をお話しさせていただきましたが、金融サービスや、その他身近な日常の生活の課題のフェーズのアイデアを開発したいとなった時に、GitLabを使ってDevOpsを進めて、サーバーレス、コンテナ、DataOpsのようなことをやりたい方がいらっしゃれば、ぜひご参加いただければと思います。

いま進行中のプロジェクトではFirebaseを使ったりして、サーバーレスを使っていくのは、有効かなと思っています。それから、既存のシステムやしっかり作らなければいけないところではコンテナ、Kubernetesのテクノロジーを使ったり。AI分析では、DataOpsのような、データ分析におけるDevOpsを実現したい方がいらっしゃれば、ぜひご参加いただければいいかなと思います。

私も金融業界に来たのが初めてなんですが、IT業界の知識、ナレッジは金融業界にとって非常に新しいと感じていて、デジタルトランスフォーメーションを実現するためには、IT業界にいらっしゃるエンジニアの経験が非常に役に立つのかなと思います。

昨日ぐらいに、Firebaseでキャリアページを用意したので、アクセスしてみてください。

（会場笑）

今回DevOpsの話をしましたが、Android/iOSエンジニアやUXデザイナー、データサイエンティストなど幅広く募集していますので、ぜひご興味のある方はここを踏んでみてください。ありがとうございました。