技術情報 の記事一覧

7/14（木）にGMO Developers Night#35 「クラウドを活用した新決済基盤サービス開発の裏側」をオンラインにて開催しました！今回は、新決済サービス「fincode byGMO」について、開発者がサービスやシステム概要だけでなく、技術発信への取組みや開発体制・進め方の裏話、そして今後の開発ロードマップなどを余すことなく、語り明かしました。イベント告知：https://developers.gmo.jp/20150/本記事はこちらのイベントの書き起こしとなりますので、ぜひご覧ください。 登壇者（敬称略） GMOペイメントゲートウェイ　システム本部 関連事業サービス統括部 執行役員・統括部長吉田 剛士fincode開発担当米山 純司fincode開発担当志野 直生 会社説明_GMO-PGとは 吉田GMOペイメントゲートウェイの会社案内を簡単にさせていただきます。「PGマルチペイメントサービス」が当社のメインサービスとなりまして、主にEC事業者様とカード会社、コンビニ、金融機関などの決済事業者様をつなぐゲートウェイ部分を提供しております。EC事業者様がカード決済やコンビニ決済の利便性を考え、決済手段を追加していく際に、自前で直接繋ごうとすると個別の契約だけでなく様々なインターフェースや接続制約を踏まえてのシステム連携、精算処理といった手続きを決済ごとに対応していく必要があります。これは、加盟店様においては時間・費用ともに高コストになってしまいます。それらの、諸々の仕組みを弊社にて集約、ワンストップで各種決済をご利用いただくためのサービスを「PGマルチペイメントサービス」でご提供させていただいております。決済手段の多様化、キャッシュレスのトレンドなど、決済ゲートウェイへのニーズは年々高まっていて、現時点ではグループで13万強のお客様にご利用いただいておりまして、41億件強、約9.5兆円の年間トランザクションを処理しております。会社としても、毎年25%の営業利益成長を目標とする中で、16期連続で増収増益を達成しております。取引量だけでなく、サービス拡充を含め、開発ニーズにも広がりを続けているという状況です。これら処理を支えている我々システム本部ですが、現在エンジニアは約200名在籍し、内製開発にこだわりまして、LinuxやJavaを中心としたオープンソースベースの開発を行っております。システム本部のベースは現在渋谷ですが、福岡にも開発拠点を設けており、毎年新卒と中途採用を合わせて30名以上のエンジニアの方々を採用しております。 対談 「fincode byGMO」 とは 吉田今回クラウドを活用した新決済基盤サービス開発の裏側と称しまして、GMOペイメントゲートウェイの連結子会社でありますGMOイプシロンが本年5月18日、つい2ヶ月ほど前ですけどもリリースさせていただきました、「fincode byGMO」というプロダクトの開発の裏側を中心に早速ご紹介させていただこうと考えております。先ほども紹介しましたが、弊社は「PGマルチペイメントサービス」やGMOイプシロンの決済サービスなど、決済代行システムを長年にわたり運営させていただいております。こちらは多くのお客様にご利用いただいていますが、お客様の環境が以前と変わりつつある現状を踏まえて、新たな決済サービスの企画を我々としましても1年半ほど前から開始しておりました。それはまさに、テック系スタートアップ領域におけるお客様のニーズに応えることということで企画を始めておりました。新たな事業を始めるにあたって、CTOやプロダクトマネージャーといったエンジニアの方々に対して、より分かりやすく簡単に決済を組み込んでいただけるプロダクトをご提供し、スタートアップ企業様に複雑な決済サービスを短時間かつ最小限のワークロードで導入いただくことで、企業様の立ち上げや成長をぜひとも我々としましてもご支援させていただきたいという思いを大事に、今回のサービス開発に挑んでまいりました。続きまして、今回リリースさせていただきました「fincode byGMO」の特徴を簡単にご紹介します。実装の容易さや利用開始手続きの手軽さというのはもちろんのこと、開発支援コンテンツのWeb提供とかサブスク、プラットフォーム管理機能などの様々なお客様ビジネスにミートするための機能を実装しております。よって、ぜひスタートアップの企業の方々にとどまらず、多くのCTOやプロダクトマネージャーといった方々にも「fincode byGMO」のご活用の機会をいただければと考えております。ではここから、「fincode byGMO」の開発者2名より、実際にどのような観点で設計開発に従事してきたか、また開発中にどんな裏話があったかなどを共有いたします。こういったプロダクト開発をぜひ一緒にやってみたいと思っていただき、この機会を通じて仲間が一人でも増えたらうれしいという思いで本日お話をさせていただきます。 ここからは「fincode byGMO」の開発を担当しております米山からお話しさせていただきます。まずは自己紹介させていただきます。米山純司と申します。2015年にGMOペイメントゲートウェイに新卒で入社いたしまして、「PGマルチペイメントサービス」の担当となりました。2017年からセキュリティグループに異動して、PCI DSS、ペネトレーションテスト、AWSの運用などを担当しておりました。2020年から現在のチームで「fincode byGMO」の立ち上げより参画し、現在も担当しております。現在は、要件定義から保守運用まで一通り担当しております。得意分野はスライド記載のもので、直近ではJava、MySQL、AWSをよく触っております。本日はよろしくお願いいたします。米山 決済代行サービスとは はじめに、そもそも決済代行サービスというのはどのようなもので、どのようなメリットがあるのかをご説明します。決済サービスとは、一言で言うとネットEC事業者向けのサービスとなります。ネットEC事業者様は、利用する決済手段ごとに各決済業者と契約し、システムのつなぎ込みなどの開発を行う必要があります。クレジットカード決済だけ利用するにしても、ケースによっては数十社のカード会社と契約する必要があります。これだと手間も時間もかかって非常に大変です。そこで決済代行サービスの出番となります。契約の窓口と決済のインターフェースを一本化することで、契約の手間を削減、そしてシステムの開発のコストを削減することができます。お客様のシステムに簡単に決済を組み込むことができるというのが、決済代行サービスの概要と主なメリットになります。米山 「fincode byGMO」のきっかけ 続いて、「fincode byGMO」のきっかけとして、なぜ新サービスを作ることになったのかについてご説明いたします。まずはEC事業を行う加盟店様の背景からですが、昨今のEC業界ではエンジニアが決定権を持つケースが非常に増えてきております。この傾向は特にスタートアップのEC事業者様、加盟店様で多くみられる状況でした。そのような事業者様、お客様の要望要件を満たすためにはよりエンジニアに寄り添った機能が必要になります。ただ、弊社の既存サービスはもうすでに多くのお客様が利用していまして、インターフェースの大きな変更が難しい状況になっていました。そのため既存サービスでこれを実現するのではなくて、エンジニアファーストなサービスをゼロから作る、ということで「fincode byGMO」が立ち上がりました。何がエンジニアファーストなのかはこの後ご説明していきたいと思います。米山 システム構成 機能のお話の前にシステム構成についてご説明します。テーマについては大きくこの2つで構築いたしました。「クラウドネイティブ」と「サーバーレスへのチャレンジ」ということで、弊社ではオンプレで稼働するサービスが多いですが、せっかくゼロから作れるサービスということもあり、新しい試みとしてこれらのテーマを挙げて構築を進めました。こちらが「fincode byGMO」のシステム構成の全体図になります。少し簡略化はしています。構築スピードとリソースの柔軟性からAWSクラウドを利用しており、フルクラウドで実装しております。AWSで構築しているので、AWSのサービス名が何度か登場しますがご了承ください。なるべくご説明します。各機能の説明は別途お話ししますので、まずは全体のご説明ですが、真ん中のAWSの雲マーク、枠で囲っているところが「fincode byGMO」のシステムになります。ユーザーからのリクエストは基本的にお客様のサーバー、それとブラウザからのリクエストとなります。図の赤線部分です。それらのリクエストから基本的にすべてAPIで受け取って、それらを処理する構成としております。API処理を行うWebアプリケーションバッチはコンテナで稼働しております。データベースはRDS Aurora、こちらはAWSがマネージドしているデータベースのサービスを使っております。コンテナまわりベースもAWSマネージドサービスを使っているので、我々開発者側でミドルウェアをインストールするような作業は不要です。青線部分のところは、SPA、シングルページアプリケーションを提供しておりまして、それをクライアントサイドでレンダリングさせて、動かしているところになります。米山 ではここから、各ポイントの構成についてご説明していきます。まずはAPIリクエストを受け付けてAPI認証、それと流量制御を行っている個所についてご説明します。流量制御って何？という方もいらっしゃると思うのでご説明しますと、決済サービスでは加盟店様のお客様のセールなどによって一時的に大量のリクエストが発生するケースがあります。特定の加盟店様の大量リクエストによって他のお客様に影響を及ぼさない、サービス全体に問題が発生しない、といった仕組みを入れる必要があり、その仕組みを流量制御と呼んでおります。それをこちらの仕組みで実装しております。まずはCloudFrontとAPI Gatewayで、APIのリクエストの管理認証を担うサービスになります。APIのリクエストが正しい経路を通っているか、具体的には確実にWAFを通っているかのチェックを行う監視をしております。API Gatewayの導入も初めてでしたが、先ほどご説明した通りAPIが肝のサービス、APIで基本的な処理をすべて受け付けるサービス特性になりますので、初ながらもがんばって検証しつつ導入いたしました。次にLambdaオーソライザーです。LambdaがAWSのサービスになりまして、任意の開発言語で任意のスクリプトをサーバーレスで実行できるサービスになります。このLambda制御で、先ほどお話しした流量制御の中身の処理を書いております。それをAPI Gatewayにアタッチすることで流量制御を実現しています。最後に DynamoDBです。こちらは流量制御の処理で、1秒あたりのリクエストカウント数など一時的なデータをカウントアップでデータ保持をする必要があります。その一次データ格納に利用しております。キャッシュのイメージが近いかなと思っております。このDynamoDBにTTLという仕組みがありまして、何分以上過ぎたデータは自動で削除するといったものですが、一次データ格納で使っている本サービスではぴったりなので、導入して利用しています。こちらで、データの肥大化を自動で防げるようにしております。以上の構成で、バックエンドまでに到達する前、バックエンドのアプリケーションデータベースに負荷をかけずにこのような構成にしております。API認証・流量制御についての補足になります。先ほど認証流量制御を通過して流れてきたリクエストはALB、Application Load Balancerの略ですが、ロードバランサのシステムでAPIリクエストのURLパスによって処理するコンテナを振り分けております。例えばイメージに書いていますが、「/payments」だったら決済のコンテナ、「/○○」だと別のコンテナといったように振り分ける設定を入れております。またアプリケーションの負荷はCPUなどでモニタリングしており。特定の閾値を超えた場合はAuto Scalingという仕組みを使ってコンテナが自動で増えるような仕組みも導入しております。これも大量決済処理で他の機能に影響を及ぼさないといった目的の構成になります。米山 続きまして、APIのバッチのバックアップアプリについてです。ここはECS Fargateという、AWSがマネージドするコンテナサービスを利用しております。アプリの開発言語はJava、フレームワークはSpring Bootで実装しております。コンテナにすることのメリットとしては、SSHログインして操作するとか、従来のサーバーメンテナンスを一切不要にできるというのが一番大きなところです。必要な時に必要な個数だけコンテナを立ち上げて、使わない時はコンテナごと起動しないという運用ができるので、例えばバッチなどで稼働するタイミングが10分だとしたら10分だけ立ち上がるといった構成にできますので、ランニングコストの最適化ができるというメリットがあります。ECR、こちらはdockerのイメージを保持するサービスになりますが、ECS Fargateで動かすアプリケーションは基本的にこのイメージを保存してアプリ自体のバージョン管理をしているイメージです。イメージ保存をして、アプリのデプロイは基本的にECR、イメージ構築から作成しております。米山 続けてお客様向けの管理画面、アプリケーションとか、Webドキュメントのフロントエンドの構成についてご説明します。フロントエンドのアプリケーションはJavaScriptのフレームワークのVue.jsというアプリケーションで構築しております。こちらはシングルページアプリケーションになりまして、そちらを構築しています。CloudFront、こちらがCDNのサービスになります。S3、これがストレージのサービス、ファイルの保持とかファイルアップでファイル保管をするためのサービスですが、静的コンテンツであればそのWebサービスとしてWebサイトとして動かすこともできるものになっています。「fincode byGMO」では SPAモジュールをストレージサービスのS3に置いて、それをCDNサービスのCloudFrontで外部に配信するといった構築にしています。アプリをビルドしてできたモジュールをS3に置くだけの構成にしていますので、こちらも完全にサーバーレスで動いておりまして、サーバー起動量ゼロという、コストメリットが非常に大きい構成にしております。最後に、弊社のオンプレとの接続方法についてです。AWS上に「fincode byGMO」から弊社の既存サービスのナレッジやリソースを活用する際は、専用線接続のDirect Connectを利用しております。専用線接続にすることによって、通信をセキュアに、レイテンシーの観点でも安定した通信を行うため、このサービスのために工事して構築しました。システムの構成の説明は以上となります。構成については、AWSのベストプラクティスにのっとり、セキュリティ面でもPCI DSSに準拠した構成ではありますが、改善の余地はまだあるので、ブラッシュアップを続けていきたいと思っております。米山 エンジニアファーストをめざして 志野同じく「fincode byGMO」開発担当の志野です。私の方からはまず「fincode byGMO」の強みであり目標でもあるエンジニアファーストというものを実現するための機能や取り組みについてお話ししていこうと思います。自己紹介いたします。エンジニア歴は5年と少しといったところで、2017年から新卒で某企業にてWebエンジニアをやっておりました。その頃はECサイトの開発に携わり、フロントエンドもバックエンドもインフラもといった感じでフルスタックに経験を積んでおりました。そして昨年9月に転職して、弊社GMOペイメントゲートウェイに入社いたしました。入社の時から「fincode byGMO」の開発担当でやってきております。はじめはフロントエンドを主に担当しておりましたが、今年5月からは審査・精算システムという部分のバックエンド側の担当になっております。担当領域は要件定義設計から構造改定、実際に手を動かしての開発と保守運用まで一通り担当しております。 志野改めましてエンジニアファーストについてお話しいたします。「fincode byGMO」は主に3つの軸からエンジニアファーストを目指しました。それはまず「インターフェースを分かりやすく開発しやすいものにすること」、次に「開発時のコーディング時間を極力減らすための機能やサポートを提供すること」、そして最後に「待ち時間を極力減らせるような即時での利用を可能とするオンボードプロセスを提供すること」です。次のスライドからは、そのための機能などを具体的に紹介していきます。まずはテスト環境についてです。「fincode byGMO」ではテストアカウントを即座に発行できます。ユーザー名とメールアドレスとパスワードだけで発行できますので、最短1分程度で発行できるかと思います。「fincode byGMO」というサービスを知って、どんな機能があるのかと気になったらすぐにテスト環境にログインして管理画面を見てみたり、APIを実際に叩いて試してみたりしながら「fincode byGMO」のご利用を検討することができますので、エンジニアにとっては技術選定のフェーズなどで調査がすんなり進んでうれしいのではないのかなと考えております。また、このテストアカウントはテスト環境専用のアカウントとなっておりまして、本番環境用のアカウントとは完全に独立しております。ですので、後々の本番環境への影響の心配は不要ですし、これまでは利用しているサービスによっては本番環境のデータを見せたくないからアカウントを発行してもらえないといったエンジニアや開発者もいたのではないかと思いますが、「fincode byGMO」ではそういった開発者にもテスト環境のアカウントをどんどん発行していただいて、開発をよりスムーズに進めてもらえたらという思いがあります。 志野「fincode byGMO」に限らず開発を行う際にはAPIリファレンスをご参照いただくかと思いますが、「fincode byGMO」のAPIリファレンスはWebで公開しておりますので、資料請求など不要ですぐに参照いただけます。これも技術選定の際に素早く動けるようになるかと思いますので、そういった配慮もしております。また、リファレンス内にはリクエストのサンプルも用意しておりますので、コーディング時間の削減のためにご利用いただければと思っております。現時点ではサンプルはcURL、Python、Node.js、Go言語を用意しておりますが、順次追加予定となっております。ご要望があればどしどしご意見いただければと思います。 志野他にコーディング時間を削減するための機能を紹介しますが、決済画面の実装をサポートする機能を紹介します。左のUIコンポーネントは、加盟店様側で用意されているWebページに決済画面を埋め込む機能です。「fincode byGMO」が用意したJavaScriptを埋め込むだけで簡単に決済画面を組み込むことができます。真ん中のリダイレクト型は、URL発行用のAPIを叩いていただくだけで「fincode byGMO」側で決済画面を作成してそのURLをお渡しするという機能です。お客様へはそのURLに案内していただくだけで決済を行っていただくことができます。右側のモバイルSDKは、スマートフォンアプリに決済画面を実装するための機能です。どの機能もリファレンスに組み込み手順を用意しておりますので、それほど大きくない工数で組み込むことができるかと思います。これらの機能をご利用いただくと、単純に画面の実装をしなくてよくなるだけでなく、カード情報の非通過非保持も実現することができますので、そのあたりの実装コストも削減できるかと思います。 志野続いては「fincode byGMO」のAPI設計の観点からお話しします。「fincode byGMO」が提供するAPIは、エンジニアにとって一般的だと感じられ、分かりやすくなるようにRestfulな作りにしております。RestfulってどんなAPIなのかというと、 URLの決め方やレスポンスの形式などいろいろあるのですが、弊社内で大きく変わった点としてはHTTPメソッドを処理に応じてきちんと使い分けるようになったところです。既存サービスではAPIのパスにアクションと対象を記載したり、同じパスで違う処理を行っていたりといった事がありましたが、「fincode byGMO」では可能な限りアクションはHTTPメソッドで表現しているため、パスがすっきりしているかと思います。また、同じパスで登録と更新の両方の処理を行うようなことがあったのですが、「fincode byGMO」ではHTTPメソッドでPOSTとPUTでそれぞれ分けておりますので、動作がイメージしやすくなっているかと思います。またPUTやDELETEは、冪等性があるHTTPメソッドであるため、多重で叩いてしまっても問題ないといった見分けもしやすくなりますので、一番安全でないPOSTのAPIの呼び出しが減るといった、システムにとってより良い形になるというメリットもあるかと思います。 志野エンジニアファーストについての取り組みの紹介として最後にイベントログという機能を紹介します。APIのアクセス履歴を管理画面から確認できる機能で、リクエストの日時やHTTPステータスコード、リクエストボディ、レスポンスボディなどの基本的な部分に加えまして、処理にかかった時間なども確認することができます。開発している時に自分でログを出力せずとも結果を詳細に確認でき、エラー発生時の原因特定などにも役に立つかと思います。もちろん、この機能は本番環境とテスト環境のどちらでも提供しております。 志野いくつかエンジニアファーストを実現するための機能を紹介しましたが、これらはすべて「fincode byGMO」の開発を行っているエンジニアのメンバーが、同じエンジニアにとってどうなっていればうれしいかということを考えながら作っています。ただ、私たちではまだ思いつけていないような改善点もまだまだあるかとは思っておりますので、ご意見いただければどんどん反映していきたいと思っております。今後も真のエンジニアファーストであるサービスを目指し続けていきますのでご期待ください。 開発体制と裏話 志野続いては、「fincode byGMO」の開発体制や開発秘話などプロジェクトの進め方についてのお話をいたします。まずは開発プロセスについてです。「fincode byGMO」では従来とは異なる開発プロセスでプロジェクトが進行しました。従来では図のように、要件定義は企画営業チームが実施してシステムは設計と実装を実施するという形をとっていましたが、「fincode byGMO」ではエンジニアファーストを謳っておりエンジニアの意見を多く取り入れるため、最も身近なエンジニアとしてのシステムやデザインチームのメンバーが、出された要件に対して意見し、要件を変更しながら進めました。そのため、要件の確定に時間がかかってしまうとか、設計が進み始めてから要件変更になるということもままあり苦労はしておりますが、エンジニアファーストの実現のために必要なコストであると考え、頑張っております。また弊社では、エンジニアは営業や企画職、事務職とは違うフロアで業務を行うことが多いのですが、「fincode byGMO」の開発チームはすべてのチームが同じフロアで業務を行っています。リモートワークもありますので常に同室にというわけにはいかず、チャットツールやWeb会議でのコミュニケーションが実際はメインとはなっているのですが、対面で話した方が早いなと感じた時などにすぐに対面で話せて助かったという場面も非常に多かったです。エンジニアの意見が多く取り入れられている一例として、先ほど紹介しましたイベントログ機能は、開発チームのエンジニアが「この機能は絶対に欲しい」と思ったところから開発が始まりまして、優先度をかなり上げて対応させてもらいました。これは一部の例なのですが、出された要件には、すべての機能でエンジニアの意見が何かしら反映されております。 志野続いて「fincode byGMO」の開発スケジュールについてお話しします。「fincode byGMO」は2021年4月からプロジェクトが開始しました。そして、同年12月に限定公開として本番環境の稼働が開始しまして、2022年5月には一般公開でリリースされました。かなりのスピード感で進めたプロジェクトであるといえるかと思います。2021年9月の開発チームメンバー2人追加というところで自分が入社したのですが、この時点では正直に言ってまだ多くの機能はきちんとは動いておりませんでした。そのような状態から一つ一つ問題を解決していきまして、10月・11月・12月と進むにつれてどんどんきちんとしたシステムに仕上がっていくのが自分にとってとてもうれしかったです。また管理画面の細かいUI/UXの改善などはエンジニアの裁量に任せてもらっておりまして、自分の提案で使いやすいWebページにしていけるのは非常に気持ち良かったなと今思い出しても思います。そういった流れから、12月には自信を持ってリリースできたということを覚えております。 志野続いて、サービス名についてちょっと苦労したなという部分の開発秘話なのですが、「fincode byGMO」は当初サービス名が「fincode byGMO」ではなく、途中からこの名前になりました。はじめは仮のサービス名で開発していて、ほぼその名前で決定のように進行していたのですが、社内の他のチームなどからも様々な意見をいただいて、再度、エンジニアに向けたエンジニアのためのサービスであるということが分かりやすい名前にしようと検討が始まり、現在の「fincode byGMO」の名前に落ち着きました。ただ、開発が始まってしまっていたのでいろいろと修正箇所が出てきてしまいまして、ドメインを取り直したりですとか、GITのリポジトリ名やAWSで利用しているサービスに付けている名前を付け直したりといった対応が発生しまして、その対応にそれなりの工数がかかってしまったという苦い思い出があります。 メディア展開への取組み 志野続きましてメディア展開についてお話しします。「fincode byGMO」では、ProductBlogの運営とTwitterでの情報発信を実施しています。その狙いですが、既存サービスは決済サービスというサービスの性質からどうしても堅苦しいイメージを持たれてしまっていたかと思います。「fincode byGMO」ではそのようなイメージを払拭し、ユーザー、特にエンジニアにとって身近なサービスにしていきたいと考え、これらの取り組みを始めました。ブログの内容を一部紹介しますが、実際に「fincode byGMO」を組み込んでみてその手順などを記載したような記事も用意しております。エンジニアの方はサービスを組み込む際にQiitaなどの記事を参考にしたような経験があるかと思いますが、「fincode byGMO」ではそのような記事を自己完結で用意しており、エンジニアをサポートしております。このような記事以外にもコラムやイベント参加についての記事など様々なジャンルのページを公開していく予定ですのでご期待ください。ブログやSNSでの発信は私たちとしては初の取り組みであるため、記事の内容やTwitterでの発信内容については相談しながら進めています。考えたこととしては、エンジニアの興味をひく内容とはどんなものか、ネタ切れを防ぐためにはどうするか、ブログ・SNSアカウントのキャラクターを作ってみようかとか、アカウントの管理は誰がやるのか、どのアカウントをフォローするのか、ということを検討しているのですが、まだまだ駆け出しですので、今後の更新にご期待下さい。 今後の開発ロードマップ 志野続きまして、今後の開発ロードマップについてお話しします。「fincode byGMO」では、継続して機能拡張を予定しております。現時点で提供しているカード決済以外の決済手段追加や、サンプルコードの対応言語の追加などを優先して対応していく予定です。その他の9月以降の開発スケジュールはまだ社外秘となっておりましてお話しできないのですが、来月頃のリリースの内容ですと、「メールリンク」という、メールを「fincode byGMO」からお客様へ送信して、そのメール内に記載されたURLから決済画面に飛んでいただくという機能や、「3DS 2.0」対応という、より便利にセキュリティを担保できるような機能に対応したりしていきますのでご期待ください。もちろんその他にも、より使いやすいと思ってもらえるような機能追加、より良いと思われるデザイン改善を進めていく予定です。欲しい機能がある方がいらっしゃればご意見ください。絶対対応するとまでは約束できませんが、しっかり検討させていただきます。今後の「fincode byGMO」にご注目ください。 質疑応答/Q&A Q：「fincode byGMO」のTシャツは非売品ですか？ これは非売品です。米山 吉田このTシャツを着て、今後のイベント等にこれからも出張っていきたいと思っています。 Q：新しいサービスを作る社風はどこから生まれていますか？ 吉田弊社はエンジニアだけではなくて営業も含め社内のチーム全員がお客様第一ということを大きな念頭に置きながら常に業務に携わっております。ということは、お客様の悩みとか、今の市場においてどんなお客様がどんな動きをされているか、かつ既存のお客様も踏まえたニーズに常に耳を傾けております。そういった中で、「fincode byGMO」はスタートアップの領域のお客様に対してより分かりやすく、よりスピーディーなプロダクト提供ができないかということで我々も考えまして、今回のプロダクト開発に至っております。なので、社風としましては、やはりお客様第一で動いている会社です。それがエンジニアや営業だけではなく、全員がそういったマインドを持って従事しているというところがまさに社風であり、我々も非常にそこは大事にしているところになります。個人的にもいい社風かなとも考えております。 Q：「PGマルチペイメントサービス」との違いを教えてください 「PGマルチペイメントサービス」も「fincode byGMO」も同じオンライン決済サービスですが、ビジネス規模でいえば、「PGマルチペイメントサービス」は大手のお客様向けのサービスになります。お客様に対して個別に担当の営業の方がつきまして、場合によっては特定の機能を付けるなどの調整も開発に組み込む場合があります。「fincode byGMO」の場合は、どのお客様にも同じ機能をASPとして提供しておりまして、ビジネス規模でいうとスタートアップ向けという違いがあります。機能面でいうと、「PGマルチペイメントサービス」は結構長く運用を続けていますので、一言でいうと多機能で、決済手段などが豊富に揃っている状態です。「fincode byGMO」はこれから拡張していくというところで、機能面の差はあります。それともうひとつ異なる点はインターフェースです。「fincode byGMO」の方は、加盟店様やお客様に提供しているインターフェースの仕様について、今どきの流れに沿った形で提供しています。あと、「fincode byGMO」では、すぐに使える点により重きを置いておりますので、テスト環境とかモバイルSDKの提供などが違うと思っております。米山 Q：「イベントログを使いやすくするために考慮したことなどあれば知りたいです 志野イベントログ機能はエンジニアの方から発案して作らせていただいた機能なので、いろいろ考えてこだわった部分があります。「fincode byGMO」のAPIでは、リクエストボディやレスポンスボディなどは基本的にJSONを介するので、そこのJSONが読みやすいようにハイライトをしたりとか、他のページと構成が異なっていて、画面構成とかも結構考えて作ったりとかしています。また、なるべく多くの範囲が見えるように、文字サイズを小さめに調整するとかの点もこだわって作っていますので、ぜひご利用いただけたらと思います。 Q：景色綺麗です！オフィスですか？ 吉田こちらは渋谷のフクラスで、GMOペイメントゲートウェイのある本社の会議室です。非常にきれいなオフィスなので、ぜひご一緒いただける方がいらっしゃれば、どしどし採用ページを見ていただけたらと思います。 Q：開発チームの規模とか気になります 開発ピークの時とは状況は変わっていますが、いま開発環境で体制としては弊社のメンバーと、開発を一緒にお願いしているパートナーさん、合計で13～14名で進めている状況です。米山 吉田そのぐらいの開発規模のメンバーで、開発ロードマップにもありますように、この8月も含めて3か月に1回、クオーター単位ぐらいで新しい機能をどしどし開発していきたいと考えています。そういった開発要員の中で、この2人を中心としたエンジニアがモノづくりに励んでいるという状況です。 Q：スライドの開発体制はウォーターフォールになるでしょうか？ 吉田ウォーターフォールとアジャイルの中間の形で進めています。弊社の場合、完全なウォーターフォールだけで進めているわけではなく、機能改善を含めてアジャイル的に進める場合もあります。今回はまったく新規開発でのプロジェクト推進だったので、フェージングにはポイントを置きながらも、開発のスピードを上げなければいけないということで、ウォーターフォールとアジャイルの中間的な進め方をしております。今後も、スピードを重要視しながら、かつ品質を維持させていかなければいけないので、開発の進め方については逐次メンバーとも協議をしながら進めています。 Q：クラウドでの開発で、オンプレとの開発と比べて大変だったことはありますか？ 技術的には、個人的にはないです。クラウドにして良かったと思うことが多いです。困ったことはどちらかというと運用面で、開発標準が弊社の中であまり揃っていなかったり、実績がなかったりというのがあり、前例がないところにルールを決めながら作ったというのがあります。こういった時どっちを選べばいいのかといったような開発標準作り、ルールで決まってなかったところが苦労しました。そのあたりも整備されつつあるので、課題は解消されつつあります。米山 志野私はもともとフロントエンドの担当だったのでフロントエンド寄りの話になってしまいます。先ほど説明にもあったように、「fincode byGMO」のフロントはS3にVue.jsをビルドしたものを置いて動いているのですが、そこの仕組みが新しいもので、あまりリファレンスがない、調べてもあまり出てこないようなもので、何かしら不具合が出た時に苦戦した思い出があります。一例としては、トップページにはアクセスできるが、それ以外のページにはアクセスできない、エラーが出てしまうということが何度か発生しました。Vue.jsはindex.htmlという大元のHTMLファイルからいろいろなjsファイルを読み込んでいろいろなページを表示するという仕組みになっていて、どんなパスにアクセスしても必ずindex.htmlにアクセスして欲しいのですが、CloudFrontとS3という仕組みを使った結果、指定したパス、例えば「/login」にアクセスしようとしたらloginというファイルをS3の中から探そうとしてしまっていて、実際はVue.jsの仕組み的にはloginというファイルは存在しないのでエラーが出てしまうということが起きていました。CloudFrontでS3から配信する仕組みを使う場合はコツが必要で、CloudFront側でloginというファイルとか、何かしらのファイルが見つからない、403 Errorが返った時にはindex.htmlに向ける、複雑であまりしない動きをさせる必要があって、そこで苦戦したけどなかなか原因が分からなかった、そういったことはありました。 Q：少人数で短期間に開発するにあたって、工夫したことや苦労したこと等ありますか？ 現在進行形で工夫していることとして、「fincode byGMO」はサービスとしてまったく新しいものですが、弊社の既存の決済サービスは非常にナレッジがある状態です。「PGマルチペイメントサービス」や他のサービスも実績があるので、そういったナレッジを使いつつ開発することで、まったくゼロベースではないというか、仕様がある程度分かった状態で作ることができたということが非常に大きいところと思っています。ただ、まったく新しいものを作るという意識は捨てないようにしようと思っているので、コピー＆ペーストは絶対になしとか、そういった意識はしつつ、ナレッジを持ってこられるところは持ってくるという意識をして、開発スピードを担保しているところではあります。米山 志野工夫したことが2つあって、1つはなるべく機能を汎用的に作るように常に意識し続けるということです。そこを意識したことで、意識していなかったら機能をもう1つ追加になりそうだったところを0.3個追加みたいな感じでなんとかなったという場面がありました。あとは、開発の手が若干空いたタイミングで、なるべく各メンバーができることを増やすようにと意識して進めています。例えばフロントエンドのメンバーがバックエンドのAPIもいじれるようにとか、そういった環境を整えるとかいうことを意識してやってきて、そのおかげでうまく進んだというところがあるように感じています。 Q：SPAを採用した理由などあれば知りたいです 理由は、新しい技術を触ってみたいというのが大きいところだったと思います。Vue.jsというフレームワークで作っているのですが、あと2個候補があり、その中で早く開発できて、安定して動きそうなものということで進めておりました。進めている最中に、AWSの構成の話になりますが、S3にCDNを置くことで完全サーバーレス環境として動くのではないかということが分かってきて、それがSPA採用のより強い理由となりました。米山 志野自分が参画した時には、すでにその仕組みで作られていたので、採用した理由などは知りませんが、ただ単純にサクサク動くので採用してよかったのではないかと考えております。 Q：フロント画面担当者の方に質問です。画面パフォーマンスで気にかけたことがあれば教えてください 志野ちょっと難しいのですが、私が入社した時にはすでにCloudFrontでSPAと、パフォーマンスには意識された仕組みになっていると思っていたので、根本的なところに関してはあまり意識していません。実際動かしてみても、思ったよりサクサク動くと思って、結構問題ないと思っておりますので、そういう改革的なことはまだあまりやってない状態です。ただ、定期的にパフォーマンスのチェックはしていて、不要なライブラリを読み込んでいないかなどをコマンドを叩いて確認するといったことは実施していますので、今後問題が発生したら対応していこうと思っております。 Q：ProductBlogって書くテーマだったり、誰が書いたり、どう運営されているのでしょうか？ ProductBlogは社内のメンバーが書いていますが、メンバーはあまり限定していなくて、企画担当や営業担当とかで書くネタを探しています。システムが書く時は基本的には技術的な内容を担当していまして、そこも我々開発メンバーが書くのでは自作自演感があるので、当開発に入ってない同じ部署、チームのメンバーにお願いして、今度こういう機能をリリースするのだけど触ってみてくれということで実際に実装してもらうとか、割と生の声を書いてもらうような書き方にして、原稿を書いております。原稿は、しかるべきフローを経て決まった人が投稿するようなことになっております。米山 吉田開発者ではない人間が加盟店さんに成り代わってそういう立場で実装してみて、それでその実装感を記事に書いてもらうようなことをやっています。 Q：ビジネスサイド、開発メンバーが同じフロアで働ける環境による弊害などはありませんでしょうか？ 私はまったくなく、気持ち良く働かせていただいております。米山 志野しいて言えば、Web会議をしている時に、電話の声とかが入りがちでちょっと喋りにくいぐらいです。 吉田非常に和気あいあいとやる環境だったので、コミュニケーション良くできたのがよかったかなと思います。 Q：中途でPGに入社して開発を担当してPGってどんな会社だと思いましたか？ 志野ずっと「fincode byGMO」の開発チームにいますので、チームの印象かもしれませんけど、エンジニアの裁量が非常に大きいというか、そこがすごくいいなと感じました。UI/UXを自分の裁量でいいように作っていってOKみたいな感じになっていたので、やりがいがあるというか、自分が作っているっていう気持ちが非常に強く感じられて、そういった意味で良い会社だと感じております。 Q：監視系はAWSのツール以外には何か使っていますか？ AWS以外では、基本的にはあまり使っていません。サービスの内部監視としてDBの監視はアプリで実装しているので、そちらはAWSとは切り離されてアプリの監視、DBのログの監視をしている状態です。基本的にはAWSのCloudWatchというサービスでアラート監視をしているので、それ以外の監視は、外部監視を含めて特に今のところ入れていない状態です。米山 さいごに ご視聴・ご参加いただき、ありがとうございました。参加いただいた方からは金融システムの裏側はあまり公開されることがないので参考になりました、興味深かったなど、温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/cH1y-qspl3Q

6/19（日）「JJUG CCC Spring 2022」がオンラインにて開催され、GMOインターネットグループはセッションスポンサーとして協賛・登壇しました！日本最大のJavaコミュニティイベントとして、毎年2回、春と秋に開催されている「JJUG CCC」。異なる分野で活躍するJava技術者が集まる場として、Java関連の技術や事例に関するセッションが行われ、全セッションの総視聴者数は約900名に上りました。 登壇レポートvol.02では、GMOインターネットグループのテックリードである、成瀬允宣によるセッション「イベントソーシング入門 in Java――イベントストーミングから Akka persistence を使った CQRS+ES 実装まで」をまとめたレポートをお届けします。イベントについて：https://developers.gmo.jp/19185/ 登壇者 GMOインターネットグループテックリード　成瀬 允宣（@nrslib） セッション概要 常に変化するビジネス環境に迅速に対応できるよう、いま「マイクロサービス」を取り入れてサービスを開発する企業が増えています。 従来は、モノリシック（一枚板）なアーキテクチャでひとつのデータストアに「アカウント機能」、「支払い機能」、「オーダー機能」など様々な機能を保持してサービスを提供していました。それに対してマイクロサービスは「アカウント機能」、「支払い機能」など、個別に開発された小さなサービスを組み合わせて、それぞれがデータストアを持ち、ひとつのサービスを提供しています。 変化に強くて柔軟性の高いマイクロサービスですが、システム分割によりDB連結（JOIN）ができなくなるなど弊害もあります。 そこへのアプローチに、サービス毎に分かれている個別のデータストアから必要な情報を受け取ってJOINができるデータベースをつくるコマンドクエリレスポンシビリティセグリゲーション（CQRS）という手法があります。 さらにイベントのデータを保存するデータストア「イベントジャーナル」をつくり、DB全体で過去の状況を再現できる「イベントソーシング（ES）」を行うことで、マイクロサービスの課題を解決して、サービス開発のスケーラビリティにつなげています。 本セッションは、そんないま注目されている「Event Sourcing（イベントソーシング）」の理解から、イベント設計のモデリング手法「Event Storming（イベントストーミング）」の実践、リアクティブシステムを構築できるツールキット「Akka」と「Akka persistence」を使った「CQRS+ES」実装までを学べる、イベントソーシング入門です。 セッション全編 https://www.youtube.com/watch?v=Bt_kXHlNL98 イベントソーシングとは？ 【従来のデータベース】 現在のスナップショットのデータを保持しているのが「State Sourcing（ステートソーシング）」です。 【イベントソーシング】 それに対して「イベントソーシング」は、イベントを保存したデータストアです。「event_data」にはシリアライズ化されたデータが入っており、「Event type」で1行づつイベント毎にデータを保存しています。 開発者間で記述したソースコードの変更履歴を記録することができる「Git」をイメージして頂くと分かりやすいと思います。システムを差分で管理してイベント履歴を保持していき、最終的に全ての履歴を再生することで、最新データ（＝State（ステート））を手に入れることができます。 イベントソーシングの利点 Pub / Sub パターンがつくりやすい Gitのような差分管理システムで履歴が完全に残るため、ひとつのデータソースから、各自が履歴となるイベントから端末上に必要なファイル（現在のスナップショット）をつくるといった、それぞれの開発者が読み取るためのView（ビュー）をつくっています。 同じことがシステムでも出来ます。各システムは、ひとつのイベントの履歴やイベントを保持したデータストアからイベントを受け取り、それぞれに必要なビューをつくることができます。データストアには最初から現在までの完全な履歴があるのでリプレイしてそれぞれのシステムにとって欲しいデータをつくることも可能となります。 このイベントデータを収めたデータストアを「ジャーナル」、読み取り側のデータを「リードモデル」と呼んでいます。リードモデルを作るにあたって「ジャーナル」に修正が起こらないこと、これはイベントソーシングの大きなメリットのひとつです。「ジャーナル」にはイベントを保存するシステムがあります。そのため新しいシステムをつくるにあたっても、このイベントを保存するシステムに影響は起こりません。 イベントを保存する側を「Publisher」、そのイベントを購読する側を「Subscriber」（クライアント）として、ジャーナルからリードモデルを作って、それぞれシステムを作っている開発チームがいます。 「Subscriber」は、あくまでジャーナルのデータを使っているだけです「Publisher」は、「Subscriber」のためにデータを修正する必要はありません 「Subscriber」が欲しがるすべての履歴が「Publisher」に残っています。イベントソーシングはPub/Subシステムを作りやすくするのです。 ◎Pub/Subパターンとは イベント駆動型プログラミングのデザインパターン。Publisher（発行者）が発行したイベントをBroker（仲介者）が取りまとめ、Subscriber（購読者）に伝達します。イベントはBrokerが管理しているため、PublisherとSubscriber同士は疎結合となります。 マイクロサービスの課題解決につながる 複数の規模の小さなサービスを組み合わせてひとつの大きなアプリケーションを構成している分散・疎結合なアーキテクチャ、それが「マイクロサービス」です。 システム毎にデータストアが分離しているため、クライアントがマイクロサービスのデータを使う際に課題になるのがSQLのJOINができないことです。そこでイベントソーシングは、Pub/Subシステムで、各ジャーナルのイベントをクライアントが購読して自分（クライアント）にとって都合の良いリードモデルを作ることが可能になります。 Pub/Subシステムを利用して、クライアントがイベントジャーナルを自由に活用することで、DB連結の「JOIN」できないといった問題も解決できます。マイクロサービスの利点である柔軟性の高い開発に貢献して、よりスケーラブルにサービス開発を行うことが可能になるのです。  実践！イベント設計「イベントストーミング」 イベントソーシングで、どのように「ドメインのイベント」を定義して保存するべきか。そこで使えるのが「Event Storming（イベントストーミング）」という手法です。 これはAlberto Brandolini 氏が提唱した付箋紙を使ったワークショップ形式のモデリング手法。付箋にドメインで発生するイベントを書き出して、タイムラインに沿って配置することでビジネスプロセスの全体像も明らかにすることできます。 上記は、最終的な完成図になります。実装では、この図がそのままコードに落ちます。ツールはオンラインホワイトボード「Miro」を使用します。今回のお題はECシステム、「ECで注文すると、どういうことが起こるか？」です。イベントストーミングはこうしたユースケースを軸に行うのがお勧めです。最初のきっかけである「商品を注文した」からスタートしましょう。 手順1：思い付くイベントを書き出す（動画 7:00～） https://www.youtube.com/watch?v=Bt_kXHlNL98&t=420s ECで注文後に起きるイベントをオレンジの付箋で書き出します。すぐ議論する内容ではない、けれど確定までに処理する情報（＝留意点）は、「ホットスポット」という紅色の付箋で記述していきます。 手順2：イベントを時系列に並べる（動画 8:55～） https://www.youtube.com/watch?v=Bt_kXHlNL98&t=535s 「商品の注文をした」→「注文受付メール送信」のように、イベント（オレンジ）を発生する時系列順に並べていきます。 手順3：カラーパズルを並べる（動画 11:00～） https://youtu.be/Bt_kXHlNL98?t=660 次にイベント（オレンジ）以外の、カラーパネルを並べていきます。 それぞれ色によって意味づけされています。 カラーパズルにはルールがあります。 ルール（1）：下図の矢印の順番で色をつながなければいけない ルール（2）: 「イベント」（オレンジ）には必ず、「コマンド」（意味：そもそものきっかけ）（青） と、「Aggregates」（黄色）または「システム」（ピンク）が必要（矢印の順番） 下記では「商品を注文する」（青）→「Aggregates」（黄色）→「注文した」（オレンジ）とカラーパネルをつなげました。この3つは密着させるように配置しましょう。 次のステップ「注文受付メールが送信された」（オレンジ）ですが、ルール①の通り、「イベント」（オレンジ）→「イベント」（オレンジ）は繋げられません。 そこで「コマンド」（青）を追加。「イベント」（オレンジ）から「コマンド」に行くために、「ポリシー」（紫）か「システム」（ピンク）、「ReadModel」（黄緑）の、いずれかを通ります。 よく使用されるのが「ポリシー」（紫）です。「ポリシー」は、「自動的に」「いつでも」という「暗黙の方針（明示的な合意がない場合）」という意味付けです。これで「商品を注文した」（イベント）から→「注文受付メールが送信された」（イベント）までをつなげることができました。 進めていくと複数のイベントをつくる条件分岐も起こります。定められた順番に沿ってカラーパネルでつなげて、完成を目指しましょう。 ◎ 成瀬式！地球儀について システムとは関係ないが現実で起こりえる曖昧な部分を包み込んでくれるのが、この「地球儀」です。これは成瀬式ですが、よく使用するので作ることをおススメします！ 手順4：「集約」（Aggregates）を埋めていく（動画 19:20～） https://youtu.be/Bt_kXHlNL98?t=1160 発生するイベントをカラーパネルでつなげました。現在、黄色はすべて「Aggregates」になっているかと思います。ここに何が入るのか？ ヒントは目的語を見てみてください。 コマンドは「商品を注文する」なので、「Aggregates」（黄色）には「注文」を入れました。この言葉は後で変更することができます。そのため、参加メンバーで合意がとれている言葉を自由に入れて大丈夫です。 そして同じ意味を持つものを、まとめていきます。ビューモデルに関しては、システム的には関係ないため先を繋げません。また外部システムも一旦、置いておく意味で、自分のシステムにつなげておきましょう。 ◎ 成瀬式！集約について 上記の図は保存して残しておくことをおススメします！システム開発では、開発者やドメイン知識を持っているエキスパートたちなど、それぞれ持っている知識には差があります。上記の図は、それ自体がワークフローになっており、その知識がマージ（まとめられたもの）されたものなので、すごく重要な図になります。図のコピーを作成して新たにメンテナンスしていきましょう。 こうして集約（Aggregates）の振り分けが完了しました。 手順5：コンテキスト毎に分ける（動画 21:27～） https://youtu.be/Bt_kXHlNL98?t=1287 「イベントストーミング」もいよいよ終盤になりました。最後にコンテキストを分けていきます。コンテキストについては説明が難しいため「請求系」「通知系」と…ざっくりした認識でイメージできれば、まずは大丈夫です。これが「イベントストーミング」の一連の流れになります。 Akka persistenceを使ったCQRS+ES実装 https://youtu.be/Bt_kXHlNL98?t=1585 それでは出来上がった図からシステムを作っていきます。イベントソーシングをサポートしたライブラリを使えば、イベントストーミングの図がそのままシステムになります。 リアクティブシステムを構築できるツールキット「Akka」とそのプラグイン「Akka　persistence」を使い、イベントソーシング（ES）を実装していきます。AkkaはScalaのライブラリなのでJavaでも動かせます。 コードはAkkaビギナー向けに変えておりGitHubでも公開しています。 【GitHub コードはこちら】 「注文をする」から順番にコードを見てみましょう。 コマンド コマンド部分で最初に用意すべきオブジェクトはCommandRequestというインターフェースです。 public interface OrderAggregateProtocol { sealed interface CommandRequest { OrderId orderId(); } } この図（商品を注文する）のコマンドに従って実装していきます。今回だとCreateOrderRequestになります。 Record構文で、フィールドは全て不変なクラスを使っています。 public interface OrderAggregateProtocol { sealed interface CommandRequest { OrderId orderId(); } /* Create Order */ record CreateOrderRequest( OrderId orderId, AccountId accountId, OrderDetail detail, ActorRef<CreateOrderReply> replyTo) implements CommandRequest { } sealed interface CreateOrderReply {} record CreateOrderSucceeded(OrderId orderId) implements CreateOrderReply {} record CreateOrderFailed(OrderId orderId, OrderError error) implements CreateOrderReply {} } コマンドを実装したCreateOrderRequest。以下のID、オブジェクトを持っています。コマンド送信元に返答を送るため、replyToという返答を伝えるオブジェクトがフィールドに定義されています。「Akka」はアクタープログラミングなので、オブジェクトにメッセージを送る（replyToにメッセージする）ことで戻り値を返すのと同じことを実現しています。 /* Create Order */ record CreateOrderRequest( OrderId orderId, AccountId accountId, OrderDetail detail, ActorRef<CreateOrderReply> replyTo) implements CommandRequest { } オブジェクト指向プログラミングとの対比を取ると、メソッドの呼び出しがメッセージ、戻り値がリプライメッセージとなります。リプライは、今回の例でいえばCreateOrderSuceededとCreateOrderFalledが該当していて、それぞれ成功と失敗を示しています。 sealed interface CreateOrderReply {} record CreateOrderSucceeded(OrderId orderId) implements CreateOrderReply {} record CreateOrderFailed(OrderId orderId, OrderError error) implements CreateOrderReply {} イベント イベントもインターフェースを用意して実装していきます。マークアップインターフェース（下記、青枠①）はAkka Javaの都合上、実装しています。動画ではドメインにおけるイベントなので DomainEventという基底オブジェクトを宣言することも提案されていました。 青枠① public interface OrderEvents { sealed interface Event extends CborSerializable { OrderId orderId(); } } イベントを実装したOrderCreated（オーダーが作成されました）オブジェクトは、以下のデータを保持しています。 record OrderCreated(OrderId orderId, AccountId accountId, OrderDetail detail) 　　implements Event { } 集約（Aggregates） 最後に、集約（Aggregates）です。 集約（Aggregates）はこのようなコードになっています。 public record Order(OrderId orderId, AccountId accountId, State state) implements AggregateRoot { public static Either<OrderError, OrderEvents.OrderCreated> create( OrderId orderId, AccountId accountId, OrderDetail detail) { return Either.right(new OrderEvents.OrderCreated(orderId, accountId, detail)); } public static Order applyEvent(OrderEvents.OrderCreated event) { return new Order(event.orderId(), event.accountId(), State.CREATED); } public Order applyEvent(OrderEvents.Event event) { if (event instanceof OrderEvents.OrderCreated) { return new Order(orderId, accountId, State.CREATED); } throw new IllegalStateException("Unexpected event: " + event.getClass().getName()); } public enum State { NONE, CREATED } } 作成するときはEither型ですが、右側の値を正しいものとするので、メソッドが正しく実行された場合にはOrderEvents.OrderCreated（オーダーを作成した）というイベントを返却しています。 public record Order(OrderId orderId, AccountId accountId, State state) implements AggregateRoot { public static Either<OrderError, OrderEvents.OrderCreated> create( OrderId orderId, AccountId accountId, OrderDetail detail) { return Either.right(new OrderEvents.OrderCreated(orderId, accountId, detail)); } ロジックも、right （OrderCreatedを作成）して返却しているのが分かるかと思います。今回のケースでは現段階で失敗が発生するケースがなかったため、常にEither.rightメソッドで結果を返却して成功としています。エラーが起きる場合はleftでエラーを返しましょう。 以下が、そのイベントを適用する部分です。イベントを受け取り、それにしたがって処理を行います。 public Order applyEvent(OrderEvents.Event event) { if (event instanceof OrderEvents.OrderCreated) { return new Order(orderId, accountId, State.CREATED); } throw new IllegalStateException("Unexpected event: " + event.getClass().getName()); } record型は値のミューテーションができないため、インスタンスを再生成しています。「Createdイベントを受け取り→stateをCREATEDにしたオブジェクトを作成する」イメージです。 if (event instanceof OrderEvents.OrderCreated) { return new Order(orderId, accountId, State.CREATED); } コマンド、イベント、集約（Aggregates） を、まとめるオブジェクト ここまでのコマンド、イベント、集約（Aggregates）をまとめるオブジェクトを解説していきます。コマンドを受け取って、そのコマンドを注文に渡して、イベントを保存するというオブジェクトです。 実装は、以下の通りです。 public class OrderAggregate extends EventSourcedBehavior<OrderAggregateProtocol.CommandRequest, OrderEvents.Event, Order> { ---/* 集約（Aggregates）が空の時 */ @Override public Order emptyState() { return null; } /* コマンドを受け取る時 */ @Override public CommandHandler<OrderAggregateProtocol.CommandRequest, OrderEvents.Event, Order> commandHandler() { return newCommandHandlerBuilder() .forAnyState() .onCommand(OrderAggregateProtocol.CreateOrderRequest.class, (__, command) -> { var result = Order.create(command.orderId(), command.accountId(), command.detail()); if (result.isRight()) { return Effect().persist(result.right().value()) .thenReply(command.replyTo(), order -> new OrderAggregateProtocol.CreateOrderSucceeded( order.orderId()) ); } else { return Effect().none() .thenReply(command.replyTo(), ___ -> new OrderAggregateProtocol.CreateOrderFailed( command.orderId(), result.left().value())); } }) .build(); } /* イベントが保存される時 */ @Override public EventHandler<Order, OrderEvents.Event> eventHandler() { return newEventHandlerBuilder() .forAnyState() .onEvent(OrderEvents.OrderCreated.class, (__, event) -> { var order = Order.applyEvent(event); return order; }) .onAnyEvent((order, event) -> order.applyEvent(event)); } } それぞれ実行される処理 上のコードでは「コマンドを受け取る時」「イベントが保存される時」「集約（Aggregates）が空の時」と3つに別れているのが理解できると思います。以下で、それぞれ実行される処理を見てみましょう。 コマンドを受け取る時 @Override public CommandHandler<OrderAggregateProtocol.CommandRequest, OrderEvents.Event, Order> commandHandler() { return newCommandHandlerBuilder() .forAnyState() .onCommand(OrderAggregateProtocol.CreateOrderRequest.class, (__, command) -> { var result = Order.create(command.orderId(), command.accountId(), command.detail()); if (result.isRight()) { return Effect().persist(result.right().value()) .thenReply(command.replyTo(), order -> new OrderAggregateProtocol.CreateOrderSucceeded( order.orderId()) ); } else { return Effect().none() .thenReply(command.replyTo(), ___ -> new OrderAggregateProtocol.CreateOrderFailed( command.orderId(), result.left().value())); } }) .build(); } 着目すべきはonCommandの部分です。第一引数にOrderAggregateProtocol.CreateOrderRequest.classを受け取っています。このコードは OrderAggregateProtocol.CreateOrderRequestメッセージを受け取ったら、第二引数のラムダ式（青枠②）を実行するという意味になります。 青枠② .onCommand(OrderAggregateProtocol.CreateOrderRequest.class, (__, command) -> { var result = Order.create(command.orderId(), command.accountId(), command.detail()); if (result.isRight()) { return Effect().persist(result.right().value()) .thenReply(command.replyTo(), order -> new OrderAggregateProtocol.CreateOrderSucceeded( order.orderId()) ); 今回のケースではまずコマンドのデータを利用してOrder.createメソッドを呼び出しています。Order.createメソッドは次のコードになります。 ＜Order.createメソッド＞ 　　public static Either<OrderError, OrderEvents.OrderCreated> create( 　　　　OrderId orderId, 　　　　AccountId accountId, 　　　　OrderDetail detail) { return Either.right(new OrderEvents.OrderCreated(orderId, accountId, detail)); } Order.createメソッドの結果のイベントはEffect.persistメソッドによって永続化されます。永続化が成功すると次のイベントハンドラへ移行します。 return Effect().persist(result.right().value()) .thenReply(command.replyTo(), order -> new OrderAggregateProtocol.CancelOrderDueToDiscontinuationSucceeded( order.orderId())) イベントが保存された時 見るべき場所は青枠③です。オーダーが作成された時、このイベントを受け取ったら（OrderEvents.OrderCreated.class）、ラムダ（＿, event）-> {…}を実行します。eventにはOrder Createdイベントのオブジェクトがバインドされてきます。 青枠③ @Override public EventHandler<Order, OrderEvents.Event> eventHandler() { return newEventHandlerBuilder() .forAnyState() .onEvent(OrderEvents.OrderCreated.class, (__, event) -> { var order = Order.applyEvent(event); return order; }) .onAnyEvent((order, event) -> order.applyEvent(event)); } ラムダで、Order.applyEventにeventを渡して、オーダー(order)を生成するメソッドを実行しています。 var order = Order.applyEvent(event); 以下がapplyEventメソッドになります。 applyEvent を実行するとOrderが作成され、インスタンス化されて返却されます。 public static Order applyEvent(OrderEvents.OrderCreated event) { return new Order(event.orderId(), event.accountId(), State.CREATED); } 返却された値を最新のstateとして扱い、リターン（return）するといった形になっています。 .onEvent(OrderEvents.OrderCreated.class, (__, event) -> { var order = Order.applyEvent(event); return order; }) 集約（Aggregates） @Override public Order emptyState() { return null; } 今回のケースでは空の状態をnullとしています。以上が、 コマンド、イベント、集約（Aggregates）をまとめるオブジェクト の解説になります。セッションでは「コマンド定義からコーディングまでの動き」も紹介しています。そちらも併せて、ご覧ください。  イベントソーシングの原理 ロジックを実行する側が「AggregateAdaptor」（Adaptor）にコマンドをリクエストします「AggregateAdaptor」がOrderのcreateメソッドを呼び出し、イベントを受け取ります（2.）で作成したイベントをpersistしますデータストアにOrderCreatedのイベントが保存されます（2.）のイベントをOrderに引き渡し適用することでフィールドの値をミューテーションしますオーダーのステート＝中身＝データがOrderCreatedのデータなどにより書き換えられます イベントソーシングの機能 イベントを保存する以外に、イベントソーシングは下記の機能も持っています。 リプレイ機能 過去のイベントを読み出し、アグリゲートを再構築する機能です。これにより最新のステートを取得できます。 スナップショット機能 アグリゲートのスナップショットを取り、インスタンスを再構築するためにイベントを何度も再生するという処理を効率化させることができます。スナップショットの実行処理についてはセッション内で詳しく解説しています。（動画 37:08～） まとめ イベントソーシングはシステムをスケーラブルにしますマイクロサービスの課題解決につなげる手法のひとつですデータストアが分かれてしまうので、JOINができないという課題をイベントソーシングでPub/Subにすることで解決につながりますドメインをモデリングするのは、イベントストーミングが有効ですイベントストーミングの図を使って「Akka」で実装できます検証した限り（他のマイクロサービス課題も含めて）トータルで、学習コストが少ないのが「Akka」でした Q＆A 質問1：スナップショットについて 主催注文のように終了が明確なものだとスナップショットは取りやすいですが、終了がない終了までが長い場合はどうするか。変更履歴の数でカウントもできますか？ スナップショットを取るかどうか判定するコードにはシーケンスナンバーがあって、この値は何個目のイベントか？をカウントできる数になります。セッション内ではイベントの型によってスナップショットを取得する話をしてきましたが、そのシーケンスナンバーを使って何個目のイベントか？という判定も入れることができます。成瀬 質問2：開発における問題点 主催イベントソーシングでの開発する際、開発量やデータ量の増加など問題点はありますか？ データ量は増えます。本来、イベントソーシングで出来たジャーナルデータと、読み込みのリードモデルを用意するため、1チームで管理していると重複してデータが存在しているように感じます。開発量に関しては、個人的にあまり意識していないです。覚えることも多いため認知負荷はかかりましたがコード自体はクラスをいくつか用意して、それらを使うので、普段の記述と特段、変わらないという印象です。成瀬 質問3：イベントデータのリカバリーについて 主催間違ったデータが出来てしまった場合、リカバリーは難しいですか？ イベントの中身がおかしいとリード側でエラーを発生することがあります。その場合、元となるイベント側でエラーが起きないように修正する処理が必要になります。シリアライズ化されたデータを修正することになるのでツールが必要になります。また、リード側に問題がない場合、「エラーを治すための修正をしました」というイベントを入れる方法もあります。打消しのイベントですね、Gitのリバートと同じイメージです。成瀬 さいごに 今回、セッションに参加された方の中には「イベントソーシング初心者でも考え方や、メリットを理解できて良かった」という話や、「コードが分かりやすかった」という声などが寄せられました。 成瀬氏も「海外の資料を読んで挑んだ」と話していた「イベントストーミング」については初めて知った方が多かったようです。「イベントストーミングはユースケースの整理にも良さそう」 との声もありました。 本セッションはノーカット版として成瀬の個人チャンネル「なるセミ」でも配信していますので、そちらも是非ご覧ください。 今回、お伝え出来なかったPub/Subの詳しい実装については、また次の機会をお楽しみに。「JJUG CCC Spring 2022」ご参加いただき、誠にありがとうございました。 連載記事はこちら https://developers.gmo.jp/19420/

こんにちは！GMOインターネットの濱本です。今回はセキュリティで必要な「OSINT」について紹介させていただきます。 1.OSINTとは まずは初めに「OSINT」についてご説明させていただきます。「OSINT」とは「Open Source Intelligence（オープンソースインテリジェンス）」の略なのですが、一般的に公開されている資料や情報源からデータを収集、分析などをする諜報活動の一種です。 サイバーセキュリティの分野において、なぜこの「OSINT」が重要なのかを説明するためには、「サイバーキルチェーンモデル」についても認識しておく必要があるためご説明させていただきます。 2.サイバーキルチェーンモデルについて 「サイバーキルチェーンモデル」とは、攻撃者の行動を以下7つのステップに分解したものとなります。 No攻撃の段階概要1偵察インターネットなどから組織や人物の調査し、対象組織に 関する情報を取得する2武器化偵察の結果を元に、エクスプロイトやマルウエアを作成する3デリバリなりすましメールやマルウエアを添付したメールを送付し感染させるこで、対象組織の内部に侵入や通信の確立などを実施する4エクスプロイト対象者にマルウエア添付ファイルを実行させたり、マルウエア設置サイトに誘導させるなどしてエクスプロイトコードを実行させる5インストールエクスプロイトの成功により、標的（PC）がマルウエアに感染する6C&CマルウエアによりC&Cサーバと通信させ、感染PC を遠隔操作し、追加のマルウエアやツールなどをダウンロードさせることで、感染を拡大する、あるいは内部情報を探索する7目的の実行探し出した内部情報を、加工（圧縮や暗号化等）した後、情報を持ち出し、証拠を隠滅します 攻撃者は上記7つのステップで情報の搾取などを実施するとされており、7つのステップの最初にあたる「偵察」の段階で使用される手法の一つが「OSINT」となります。攻撃者は「OSINT」などで得た情報から攻撃先の特定や必要なマルウェアの作成など次のステップである「武器化」へと繋がっていき、実際に攻撃を行ってきます。 攻撃者がどういった手法や情報を元に攻撃を仕掛けて来るのか、ということを攻撃者よりも先に知っておくことで事前に対処や対策を行うことでサイバー攻撃を防止することが出来るため、今回は「OSINT」の中でも比較的簡単なものをご紹介します。 3.SHODAN（CENSYS）について 実際にサイバーセキュリティにおける「OSINT」がどういったものか、今回はSHODANというサイトを元に説明をさせていただきます。 【URL】https://www.shodan.io/ 上記URLにアクセスいただくと、下記のような画面が表示されるかと思います。 上記画面が表示されましたら、画面上部の「Search」と記載されいる箇所にサーバーIPなどを入力しましょう。SHODANにて収集済みのデータや情報がある場合には、以下のようなに表示されます。 この時点で、該当のIP（サーバ）に関しては22番ポートや123番ポートが開いていることが確認できます。 また、該当の環境に脆弱性などがあった場合には以下のような形で画面左下に「Vulnerabilitie」として考えられる脆弱性などが表示される場合があります。 攻撃者はこういった情報を「偵察」の段階で収集し、攻撃を仕掛けてくるのです。では今度は、実際に攻撃が行われている実例などをお見せしたいと思います。 なお、SHODANと同様のサイトの一つとして「CENSYS」という別のサイトもあります。 【URL】https://censys.io/ SHODAN側で検出されない場合であっても、上記CENSYSなど別サイトで検出される場合もありますので、ご注意下さい。 4.攻撃を受けた例 さきほど、SHODANにて22番ポートが空いているサーバがあることをお見せしましたが、実際のサーバ側のログを見てみると以下のような攻撃と思われる接続を確認することが出来ました。 上記は22番ポートを使用して動いているSSHの接続ログなのですが、明らかに自分ではない接続元のIPアドレスからアクセスが行われていることが確認できたため、接続元を確認してみたところ、下記海外からのアクセスであることが分かりました。 IPアドレス国192.226.244.9カナダ186.109.86.184アルゼンチン212.192.24.36チェキア（チェコ） 22番ポートが空いている、という情報だけでも不信なIPアドレスから攻撃などが来ることが分かります。先ほどお見せした脆弱性のある別環境の場合には、より確実に内部に侵入するため該当の脆弱性を突く攻撃を実施してくると考えられます。攻撃者はそういった情報を「OSINT」として情報収集したのち、「武器化」しながら攻撃を仕掛けてくるのです。 5.まとめ いかがだったでしょうか。 今回は「サイバーキルチェーン」という攻撃者側の視点も交えつつ、「SHODAN」というサイトを使用した「OSINT」という手法を説明させていただきました。 「SHODAN」などのサイトで公開されている情報に関しては、攻撃者側にとっても有益ではありますが、私たち「守る側」としても非常に有益です。それは、外部から自分たちの管理している環境が「どう見えているのか」ということを常に確認、把握しておくことで脆弱性への対策や攻撃を検知し、攻撃者のゴールである「目的の実行」を防ぐことに繋げていくことが出来るからです。 本説明が少しでもみなさんのセキュリティ改善に貢献できれば幸いです。

2022年6月21日（火）～23日（木）に日本国内最大のドローン・eVTOL（空飛ぶクルマ）展示会「Japan Drone 2022」が幕張メッセにて開催されました。GMOインターネットグループはプラチナスポンサーとして協賛し、最大規模で出展しました！今回は、ブース内ステージ「ホワイトハッカー＋暗号化通信・認証技術が守るGMOインターネットグループのドローン・IoTセキュリティ」の書き起こし記事となりますので、ぜひご覧ください。イベント告知：https://developers.gmo.jp/18770/ 登壇者（敬称略） GMOサイバーセキュリティ byイエラエ株式会社 取締役COO伊藤 章博GMOグローバルサイン・ホールディングス株式会社 CTO室 室長浅野 昌和 ブース内ステージ「ホワイトハッカー＋暗号化通信・認証技術が守るGMOインターネットグループのドローン・IoTセキュリティ」 GMOサイバーセキュリティ byイエラエ株式会社について まずは、サイバーセキュリティを担っている、GMOサイバーセキュリティ byイエラエ株式会社についてご紹介させてください。伊藤さんお願いします。 GMOサイバーセキュリティ byイエラエの伊藤でございます。弊社は、誰もが犠牲にならない世界を創るというコーポレートメッセージをもとに、最強の攻撃力、最高の品質、最低価格という形で、ホワイトハッカーの攻撃力を利用して脆弱性のない世界を創っていこうと進んでいる会社です。どういうことをやっているかというと、まず、セキュリティの診断、チェックをするホワイトハッカーの人数が120名で国内最大手です。脆弱性診断、セキュリティチェックをやっている対象数は6千件を超えています。ペネトレーションテストなどで成果が出せなかった率は10％以下で、大きな脆弱性を数多く見つけています。2021年には、未知の脆弱性、CVEとして認定されたものを新たに15件発見しました。ハッキングコンテストで世界1位となったこともあり、ハッキングコンテストで好結果を持っているホワイトハッカーが数多く所属している会社です。今回のIoT・ドローンの観点でいうと、まずハードウェアとしてのチェック、それからドローンと通信するインターフェースのチェック、それからドローンで動いているファームウェアのチェックをします。それだけではなく、ドローンにデータを通信しているクラウドや、データのしまい場所としてのクラウドのセキュリティチェックを行うとか、ドローンを動かすのにスマホを使う、クラウドとスマホがつながっているというケースもあるので、スマホアプリ診断も行って、ドローンを使ったビジネス環境全般を脆弱性診断する、セキュリティが大丈夫かどうかをチェックしています。伊藤 ちなみに、1本目のステージでは経済産業省の奥田さんとお話をされていましたけども、一緒に協業されていて、面白い企画があるということをうかがいました。 ドローンの脆弱性とは何かとか、どこに脆弱性があるかが分からないけどセキュリティチェックしなければいけないという世評もある中、それらの診断にどのぐらいお金がかかるのか分からないというお声をいただいていたので、今回経済産業省と我々を含めた診断会社が連携して、脆弱性診断を無償で受けられる制度を立ち上げました。ぜひご活用いただければと思います。伊藤 どの段階で申し込んだらよろしいですか？ 例えば、今の段階でドローンの設計図ができただけだとか、そろそろ組み込まなければいかないといったような様々なプロセスの中でお申し込みいただける制度になっているので、設計図が大丈夫かとか、あるいは部品が大丈夫かとか、ドローン全体が大丈夫かとか、こういった様々なケースで利活用いただけるような制度になっています。伊藤 GMOグローバルサイン株式会社について ありがとうございます。続きまして、暗号セキュリティを担っている、GMOグローバルサイン株式会社についてご紹介しましょう。浅野さんお願いします。 浅野GMOグローバルサインの浅野と申します。よろしくお願いいたします。私どもGMOグローバルサインがどういう会社かというのをご紹介したいと思います。まず、私どもはセキュリティの中でも電子認証、電子証明の分野を担っております。具体的には電子証明書を発行して、通信の暗号化や認証を実現するサービスを提供しております。電子証明書については、日本を本社拠点として、全世界に展開している唯一の電子証明書ベンダーです。日本はもちろん、グローバルで、ヨーロッパ・アジア・北米・南米に拠点を持っておりますので、どこからでも証明書のサービスやサポートを受けることができる、こういったことが非常に大きな特徴になっている会社です。また、CA/Browser Forumという団体があります。これは全世界でCAベンダー（電子証明書を発行するベンダー）や、Googleやマイクロソフトなどのブラウザを提供するベンダーが集まって、電子証明、電子認証の標準化を定める団体ですが、こちらにも参加しています。もう少し具体的に、ご提供しているサービスについて説明します。電子証明書の発行をメインにしているなかで、特に大きな割合を占めているのがSSLサーバ証明書です。これは皆さんも意識せずにお使いいただいていますが、ウェブサイトに接続する時にアドレスバーの横に鍵マークが出てくると、それは通信が暗号化されている、サーバ側にサーバ証明書が設定されている状態なんですね。このSSLサーバ証明書において、私どもは日本No.1のシェアを持っている会社です。そのほかにもいろいろな用途の証明書を発行しています。証明書の発行だけではなく、証明書を期限が来て更新する、あるいはいらなくなったから失効する、といったことを管理する仕組みも、ライフサイクル管理ということで提供しています。それから、少し違う分野では、マイナンバーカードを使った本人確認のサービスとか、あるいはeKYCと呼ばれる、よく金融機関で本人確認のため使用されるサービスもやっています。あと、一番最近伸びているのが「電子印鑑GMOサイン」です。これはよく言われる電子契約のサービスで、紙の契約書の代わりに電子的データで契約書を取り交わすというものです。コロナ禍を契機に非常に大きく伸びている分野です。ID管理については、複数のサービスに一つのID・パスワードで入れるいわゆるシングルサインオンの仕組みをご提供しています。こういった事業をやっているGMOグローバルサインがなぜドローンの展示会に出展しているのかということですが、我々は今までインターネットで培った技術を使って、IoTと呼ばれる分野でのセキュリティ強化に取り組んでおり、ドローンについてもIoTの中の１つだと考えています。ドローンはクラウドとの間でお互いに通信しながら飛んでいくというのがこれから主流になると思いますが、こういった通信を暗号化して、誰かに内容を盗み見られたり改ざんされたりしないようにする。あるいは機体とクラウドの相互認証、つまり機体とクラウドが通信する時に、相手が本当に自分が意図した相手であるかどうか、ドローンになりすまされてクラウドに不正なデータを送りつけたりとか、あるいはドローンが正しい送信先であると思ってデータを送ったら実は全然違うシステムでデータを不正取得されてしまったり、ということがないように、お互いを認証するための技術を提供しています。 実際に導入された例はありますか？ 浅野はい。今回機体を展示させていただいていますが、ドローンベンダーの一つであるプロドローン様と一緒に実証実験を行っています。具体的には、展示してある機体に私どもが発行した電子証明書を搭載していただいて、実際にクラウドと相互に認証しながら、通信を暗号化して、安全にデータをやりとりするということを実現しています。 今後、そういった認証を受けた機体がどんどん増えていくということですね。GMOサイバーセキュリティ byイエラエと、GMOグローバルサインのご紹介をさせていただきましたが、最後に、国内屈指の技術力と経験を誇る両社が、ドローンやeVTOLをはじめとしたIoTセキュリティへ取り組んでいくことについて、今後の展望と期待をおうかがいしたいと思います。 セキュリティは、できあがったものに対してだけにやっていくのではなくて、できあがる前に「何がセキュリティ的に気を付けなければいけないのか」、あるいは作り上がったものに対して攻撃者目線で考えた時に「何が攻撃できるのか」という観点を、まずはチェックすること。これが重要ではありますが、実は本質的にはその作った状況、セキュアである状況を守り続けなければいけないと思います。我々で支援したものに対して、浅野さんのところでしっかりと守り続ける、そういった役割分担が美しいと思っています。伊藤 浅野まさに、いま伊藤さんがおっしゃった通り、我々はセキュリティという同じ分野ですけども、それぞれに違う得意分野を持っています。いまお話があったように、セキュリティは点で考えるものではなくて、線で考えていく。いかにずっと守り続けていくか、こういったところでまず診断するというところを、GMOサイバーセキュリティ byイエラエでやって、我々の方でそれに対してきちんと対処していく。こういったことを線で繋いでいくことをやっていければと思っています。 ありがとうございました。ぜひ力を合わせて、安全安心な空の未来を実現していきたいと思います。 アーカイブ公開 今回のブース内ステージ「ホワイトハッカー＋暗号化通信・認証技術が守るGMOインターネットグループのドローン・IoTセキュリティ」の映像はアーカイブ公開もしていますので、以下より是非ご視聴ください。 https://www.youtube.com/watch?v=5S6JLZpbbto さいごに この度は会場へお越しいただき、また、レポート記事をお読みいただきありがとうございます。 JapanDrone2022の開催レポートは、「Vol.01～Vol.04」を掲載しております。ぜひご一緒にご覧いただければと思います。 https://developers.gmo.jp/20337/ https://developers.gmo.jp/20526/ https://developers.gmo.jp/20553/

2022年6月21日（火）～23日（木）に日本国内最大のドローン・eVTOL（空飛ぶクルマ）展示会「Japan Drone 2022」が幕張メッセにて開催されました。GMOインターネットグループはプラチナスポンサーとして協賛し、最大規模で出展しました！今回は、ブース内ステージ経済産業省「開発段階におけるIoT機器の脆弱性検証促進事業」の書き起こし記事となりますので、ぜひご覧ください。イベント告知：https://developers.gmo.jp/18770/ 登壇者（敬称略） 経済産業省商務情報政策局サイバーセキュリティ課長奥田 修司GMOサイバーセキュリティ byイエラエ株式会社 取締役COO伊藤 章博 産業分野におけるサイバーセキュリティ政策について 伊藤経済産業省が本事業を立ち上げた背景、政策の内容についてお聞かせください。 まず事業の説明をする前に、経済産業省としてこのIoT機器のセキュリティについてどのように考えてきたのかを簡単にご紹介します。IoT機器はこれまでの様々な開発の中で、セーフティについては意識をしている人が多かったのですが、セキュリティについては、アンケート調査などをみると1/4ぐらいの人が何らかのセキュリティのインシデントを経験しているのが実態です。例えば自動車でのリコールや、心臓のペースメーカーで脆弱性からリコールになったという例が起きていますし、ネットワークカメラではメーカーに対する訴訟も行われています。開発側が脆弱性の対応に後追いで追われていくということで非常にコストもかかってきます。そこの対策をしっかり最初の段階からセキュリティ・バイ・デザインという形で実装していくことが大事だと考えています。その中で、経済産業省として皆さんへ意識してもらいたいことは、「IoTセキュリティ・セーフティ・フレームワーク」という考え方の枠組みです。いろいろなステークホルダーがいるので、その間のコミュニケーションを円滑にしてもらうための枠組みを作りました。サイバー空間でいろいろなデータのやりとりがされるようになる中、IoT機器は、実際のフィジカル空間とサイバー空間の間をつなぐ層として様々なことを実現していきます。いわば三層構造の第二層として、信頼性をどのように確保していくかが大事なポイントです。フィジカル空間から得られるデータが正しいデータなのか、正しくサイバー空間に展開できているのか、逆にサイバー空間からフィジカル空間へ影響を及ぼす制御をする時に、そこの制御は正しく行えるのかといったことを意識していかないといけない、ということです。ではどのような考え方で実行すればよいのかですが、まず一つは、様々なリスクを分析して、リスクの重みに合わせて対策をとるということです。例えば死亡事故が起こってしまうような場合、ペースメーカーみたいな話ですと、回復困難性を高くとみておかないといけないですし、回復困難性の度合いをどのように定めるのかということがポイントです。もう一つは経済的な影響。非常に広く普及しているものであれば、リコールになった時に経済的な影響が大きいことや、もしくはその機器が動かなくなってしまった時の経済的な影響が非常に大きいことがあるので、これら2つの軸でリスクを分析しながら、対策を考えていくということです。対策については観点が4つあります。第1の観点は、まさに機器そのものがどのぐらいの性能を有していないといけないのか、機器に対する要求事項。第2の観点は、運用中の確認要求。運用中にどのように使っていけばよいのかということ。第3の観点は、運用する人に対する要求。第4の観点は、社会的な制度。例えば、ドローンでいうと、ドローンそのものにすべての責任を押しつけて、とてもセキュアなものを作ろうとすると、とてもコストがかかるわけです。それは、すべてを第1の観点に押さえ込むということではなくて、きちんと責任を分けながら、誰がどの役割を担って、全体としてきちんとセキュリティを担保されたものを作っていくのかということを考えていかなくてはいけない、ということです。ドローンそのものに求められる性能はなんだ、ということもあるし、運用のルール、例えば人が多いところには飛ばさないといったことを決めていくってこともこの1つの関係でしょうし、実際にドローンを操作する人の資格みたいなことは第3の観点に入ってきます。第4の観点は、保険制度のようなもので、全体として経済的な被害をどのようにカバーするかということまで考えて、全体として考えていきましょうということがこのフレームワークの考え方の基本になっています。これは分かりにくい話なので、ユースケースを作りました。いろいろなIoT機器のユースケースを作りましたが、1つの例として、ドローンのユースケースを作って公開していますので、もしご関心があれば「IoT-SSF ユースケース」で検索してもらうとすぐに出てくると思います。ここから先が今日ご紹介する事業につながってくるのですが、いまご紹介したような4つの観点で見ていく時に、第1の観点は当然重要になって、機器そのものにどのぐらいの信頼性を持たせるのかということですけれども、それに関して我々はいろいろな検証事業をしっかりやりながら、機器の信頼性を確保していこうということを実施しています。去年まで実施した事業として、攻撃型を含めたハイレベルな検証サービス、IoT機器の実機に対する攻撃を含めてきちんと検証して信頼性の高い製品であるということを世の中にお示しできる枠組みや、検証の手引きを作成しました。また、いろいろな方と議論している中で、検証についても信頼性のある事業者でないと安心して検証を任せられないということで、信頼のある事業者をどのように決めていけばいいのか、もしくはそれを世の中の人に知っていただけるのか、ということを議論してきていました。そのような議論が進んでくれば進んでくるほど、では開発段階でどのようにしていけばいいのかということが問題になってきます。特に中小企業の皆様にとっては、コストのかかる話になってくるので、どこまで何をやればいいのかということも含めて、中小企業の方々がセキュリティ・バイ・デザインを実現する開発とは何をすればよいかということを、しっかりと考えていきたいということが、今回の事業の一つの大きなポイントになります。実際に事業の前提となっているところをもう少し説明しますと、開発段階で実際に対策を行っている事業者は多くないというのが現状です。ではどのようなところをどこまで実施できているのかということが気になりますが、現状では脆弱性による損害が開発企業に生じてくるということが実際に起こっているわけでして、金額も1千万円を超えるような被害額になっているようなケースも国内のアンケートでは出てきています。このようなところをしっかりと考えながら、開発段階から脆弱性についてきちんと検証しながら開発を進めていくということが良いのではないかと。検証サービスが出てくると、ユーザー側にとってみれば、自分たちが使う前に検証サービスの方で検証してもらって、これは良い、これは悪いということになれば、良いものを使えばいいことになりますが、開発側からすると、開発したあとにそんなことを言われても困るということもあるので、開発段階でしっかり考えていく必要が出てきます。今回我々が事業の中でやりたいと思っていることと、中小企業に対しても協力をお願いしたいことがあります。まだまだ対策が進められている中小企業はそんなに多くないと思っているので、現状どこまでやられているのかということと、それがどのぐらいの普及をしているのかということを、きちんと把握をしながら、ここまではみんな統一的にやるべき、ここから先はリスクに応じて段階的にレベルを上げていくところだと描き出していく必要があります。そこで、中小企業の皆様がいま開発していることをぜひ情報提供いただきたい。例えば設計書や仕様書、ソースコードやファームウェア、もしくは実機をいただいて、それを委託している検証事業者に実際に検証していただいて、どのぐらいの対策が進められているのかということを明らかにします。同時に我々としては、中小企業の皆様の開発段階におけるガイドラインを示しながら、一方で検証事業者にも、大企業のようにあれもこれもやるというわけにはいかない中小企業向けの検証はどのようなことを考えなければならないのかというのをガイドラインとして示して、その2つがうまくマッチングするようなことを考えているところです。奥田 伊藤結果として、協力いただいている中小企業の皆様にも、脆弱性診断がアウトプットできるということですよね？ はい。開発段階の脆弱性診断を今回は経済産業省の事業として実施するので、中小企業の皆様にとっては情報提供していただいたり、実機を提供していただいたりということはありますが、費用をかけずに、我々の事業の中で、GMOサイバーセキュリティ byイエラエさんのような検証事業者に検証いただくことになります。なので、結果として、設計書・仕様書といったものを検証させていただいた場合には、開発の遅れや修正にかかるコストを低減するということで、設計段階できちんと修正点が見つかってくるということがあります。また、結果として開発される機器全体がセキュリティのレベルアップ、アシュアランスのレベルを向上することにつながっていき、開発段階できちんと検証してどこに脆弱性があるのかということを明らかにしながら開発の次のステップに進んでいけるということが、ご協力いただく中小企業の皆様にとっては非常に大きなメリットになるのではと考えています。奥田 伊藤次のステップは、脆弱性診断を実施しないと可視化できないところを、この制度で1度実行してみるということで、メリットはありますね。 考えたことがないという方も、ぜひご応募いただいて、1回見てもらうということが最初のステップとしてはすごく大事だと思います。奥田 GMOサイバーセキュリティ by イエラエ について 伊藤ご説明ありがとうございました。続きまして、私どもの簡単なご説明になります。GMOサイバーセキュリティ byイエラエという会社でございまして、特徴としては、最強のホワイトハッカー集団によるIoT診断を提供させていただいているということです。バイナリを読んだりとか、ファームウェアを読んだりとか、インターフェースを読んだりとか、テクニカルなことができます。案外IoT機器は、ドローンもそうですけど、サービスの中の1個なのです。ドローンだけで動いているサービスでなくて、そこにはクラウドが連携されている、データを収集するための、それからドローンを動かすためのスマホアプリとかプロポとかコントローラーとか、これらを一括して皆様と一緒にセキュリティの設計から考えていける、そういった特徴を持っているのがGMOサイバーセキュリティ byイエラエという会社です。では、改めて、脆弱性検証事業を行う背景や思いがあればお話しいただければと思います。 脆弱性検証促進事業の背景と思い 先ほどお話ししましたように、我々としてはIoT機器のセキュリティレベルを上げていくという中で、検証事業を普及させていこうと考えているわけです。その中で、中小企業の皆様も一緒になって取り組んでいける環境作りをしていきたいということがあります。製品開発が終わってから検証してもらって気付くということではなくて、開発段階における検証、これをどのように実施していけばいいのかというのを明らかにしていきたいと。一方で、セキュリティ側からだけ見ていると、とてもレベルの高い、中小企業がついていけない検証を求めていっても仕方がないので、いまそれぞれ中小企業の皆様がどの程度まで検討されていて、対策をとられているのかを我々としてもしっかりと把握をしながら、その次の段階として何をすべきかをきちんと描き出すことによって、徐々に日本の開発段階におけるセキュリティの段階を挙げていきたいという思いがあるので、中小企業の皆様にご協力をいただいて、事業を進めていきたいというところです。奥田 伊藤先ほどの説明の中に、損害額1千万円～1億円という数字がありましたが、これはどのような金額の算出なのでしょうか？ ケースによりますが、イメージしやすいのはリコールが発生してしまうというもの、もしくは自社製品を使い続けると問題が起こるので製品回収したり、ソフトウェアのパッチを開発して展開して使ってもらったりということが一緒になってきますので、そこに非常にコストがかかります。もしくは、ケースによってはお客様に対するお詫びの費用も当然発生する可能性がある、これらを含めて非常にコストがかかってきますし、弁護士費用も含めて、後追いになればなるほどいろんな費用がかかると思っていただければと。奥田 伊藤さらに、評判リスクや事業のレピュテーションリスクなどを換算すると、もっと損害は大きくなります。 そうですね、そこはなかなか先ほどの金額にはカウントできないところもあります。実際にGMOサイバーセキュリティ byイエラエさんがこれまで取り組まれていて、お客様の対応で苦労された事例はありますか？奥田 伊藤先ほど奥田さんの説明にあった「セキュリティ・バイ・デザイン」が非常に重要です。我々が困るケースはリリースの最後に脆弱性診断を行い、「リリースに間に合わせるためにここまでにやってください」という、最後にセキュリティを無理やりやっているところ。我々から見ると、「仕様書を先に見せてもらえたらそこで問題が潰せたのに」というようなケースが結構多いのです。ことが起こっている、あるいはポイント・オブ・ノーリターンが過ぎて工場出荷前という段階でご相談いただくと後戻りが大きくなるので、設計開発段階、まさにセキュリティ・バイ・デザインを考えるところから開発して作っていくところまで、一気通貫の中でこのような脆弱性診断を行い、我々みたいなセキュリティのエンジニアを混ぜていただいて物事を考えると、手戻りが少なくてセキュリティ対策ができると思うのですが、やはり後ろになってしまうことが困るところです。 今回の事業の中でも、実機を提供いただくこともありますが、設計書だけしかなくてもぜひ応募いただいて、その段階から見ていくことが大事です。奥田 事業のスケジュール 伊藤本事業は中小企業にもメリットが高いと思うのですが、どのようなスケジュール感で進んでいくのでしょうか？ いま、まさにお声掛けをさせていただいて、中小企業の皆様から応募いただくというフェーズになっていまして、個別の検証期間は1か月程度です。この検証期間で徐々にケースを蓄えていくということを考えていまして、個々の事業者は1か月程度で検証結果が出て、フィードバックされると思っていただいてよいですけど、事業全体としては今年度末に開発段階で中小企業がどのように考えればいいのかというガイドライン、それと検証事業者のガイドラインをまとめていくスケジュール感で動いていければなと思っています。奥田 伊藤事業者にとっては、脆弱性診断が無料で受けられるということで、メリットがかなりある政策だと思うのですが、応募の空き枠はどうなっているのでしょうか？ 計画の半分程度までは事業者様に応募いただいている状態で、残り半分を埋めていくという段階です。できるだけ早く、対象になる事業者を決めて次のフェーズへ進んでいきたいと考えています。奥田 情報の管理について 伊藤事業者にとっては機微な情報を経済産業省に共有していくという制度でもあるのですが、情報の管理はどのような状況でしょうか？ 確かに、実際に販売前の開発途中の非常に企業秘密にあたるようなものを提供いただいて、それを検証していくということになりますので、検証事業者の信頼性が非常に大事だと思っています。今回の事業でいうと、そのような情報をきちんと管理できる事業者に対して検証をお願いするということにしています。その一つとしてGMOサイバーセキュリティ byイエラエさんもありますが、信頼できるというだけでなく契約の中でも情報の扱いをきちんとやると、我々とGMOサイバーセキュリティ byイエラエさんとの契約の中で結ばせていただきますし、そのようなことをきちんと実施しますということを、ご協力いただく中小企業の皆様にも提示しながら進めていきます。奥田 伊藤我々も、情報管理の工夫として、入退室の管理、人の制限、情報の制限、この3つのレイヤーにおいて、皆様の情報をしっかりと守りながら本事業に参画させていただいていますので、ご安心いただければと思っています。提供いただいた設計書や機器の返却方法はどのようにお考えでしょうか？ まず、提供いただいて、脆弱性の検証をしますので、脆弱性が見つかってくると思います。それは、提供いただいた中小企業の皆様にお返しいたします。具体的にここに脆弱性があるということをお伝えします。それ自体は我々の方で、個別の企業名が分かるという形で公表することはありません。ただ、一般化したうえで、こんなことがありますという形では使うかもしれません。それから、預かった設計書や実機は当然お返しすることになるので、個別の契約の中できちんと取り決めさせていただきます。ただ1点だけ、実機の方はお預かりして検証する中でどうしても機器を壊しながら検証するみたいなことが必要になってくるので、廃棄してしまうことを前提に実機はご提供いただく必要があります。その点はご留意いただければと思います。奥田 伊藤ありがとうございます。 いろいろな種類の検証があって、たくさん進めていただくことになりますが、GMOサイバーセキュリティ byイエラエさんの場合、こんな検証が得意で、ぜひうちに来て欲しいといったことはありますか？奥田 伊藤我々は未知の脆弱性を検証していくということが得意分野です。未知のものを診断する時に何が必要かというと、攻撃者目線です。ドローンなどのIoT機器について、攻撃者から見てどんな攻撃をするとメリットが出るのかや、攻撃する入口（エントリーポイント）がどこかを、一般的な診断項目だけではなくて、攻撃者の観点からいうとどこなのかをチェックしていくということは有用性が高く、得意分野かなと思っています。小さいところをやるよりは、一番狙われがちなところからやる方が費用対効果もあるし、最終的には狙われがちのところを修正することが費用対効果の高い改修だと思います。「優先順位の付けやすさを攻撃者目線でやっていく」というところに、我々のストロングポイントがあります。今回、かなり応募される事業者も多いと思うのですが、対象事業者が具体的に対応すべきことは何でしょうか？ 検証させていただくために必要な材料をご提供いただくということが一番のメインになりますので、例えば設計書や実機、ソースコードなどをご準備いただいて提供いただくという形になります。そのあと、スケジュールの打ち合わせをさせていただいて、準備を進めていただきます。奥田 伊藤検証した場合に、何か標記のようなものが発行されるのでしょうか？ この事業の中では、我々として特に何かこの事業に参加しましたということを公表する予定はありません。将来的には検証した既製品であることをうまく世の中にアピールできる制度作りは必要になってくるとは考えていますが、この事業の中ではそこまでは対応できていません。奥田 伊藤ちなみに、GMOインターネットグループでは、脆弱性診断を受けていただいた際に認証マークを発行しようと検討を進めています。コストをかけて診断していただいて、それが一般の消費者の皆様に、この会社はセキュリティに気を遣っているということをうまく表示できると、単にセキュリティの担保だけでなくて、ものが売れる、ブランディングができる、その世界までいくと、セキュリティももっと進むと思っています。その一助となるマークとして検討しています。 事業者の方でこういうものを付けていただけると非常に浸透していくと思います。奥田 伊藤ありがとうございます。せひ、このようなマークが普及することで、結果的に「この会社がセキュリティに気を遣っている」と思っていただける世界観が作れると嬉しいと思い、進めています。本事業は、事業者が引き続き検証したいと思った場合、補助金のような仕組みがあるのでしょうか？ 事業の先に この事業自体は今年のある切り口でワンショット切り取って、中小企業の現状を把握しながらガイドライン作りを進めていくことになりますが、中小企業の政策の中でいえば、IT機器の政策でいうと、「ものづくり補助金」の制度があるので、これらを積極的に活用していただくことで、検証の費用をカバーしていただける仕組みになっています。検証は1回だけやればよいというのではなく、継続的に検証しながら製品のセキュリティレベルを上げていくことが必要になってくると思うので、我々の各種の補助制度をうまく使っていただきながら継続していただけるとありがたいと思います。奥田 伊藤今回の検証事業で一番良いところは、どこのポイントで何をやるのかがかなり明白になることです。継続的にやっていく時に、1回1回ゼロベースでやるのではなくて、例えば「仕様書レベルではここでやっておこう」、逆に「実機レベルではバージョンアップだからここでよい」などが見える化できるのが、サステナブルな事業検証というか、セキュリティの環境を作っていく中で重要であると思うので、今回の事業を1回活用いただいて、どこが更新ポイントなのか、どこがいいのかを見定めていただけるといいですね。 そうですね。「うちはあまりセキュリティを考えていないからこの事業に応募するのはどうかな？」と思っている方こそぜひ応募いただければと思います。奥田 伊藤リスクがない形でできる制度であると思うので、ぜひご活用いただきたいですね。本日はお話しいただきましてありがとうございました。対象事業者、経済産業省、検証事業者の三者いずれにもかなりメリットがある制度だと思っています。引き続き検証事業者もがんばりますし、対象事業者の方々にもぜひ応募いただきたいと思います。 ぜひいいものを一緒になって作っていければと思いますのでよろしくお願いします。奥田 アーカイブ公開 今回のブース内ステージ経済産業省「開発段階におけるIoT機器の脆弱性検証促進事業」の映像はアーカイブ公開もしていますので、以下より是非ご視聴ください。 https://www.youtube.com/watch?v=j8XcyAJ3ghs さいごに この度は会場へお越しいただき、また、レポート記事をお読みいただきありがとうございます。 JapanDrone2022の開催レポートは、「Vol.01～Vol.04」を掲載しております。ぜひご覧いただければと思います。 https://developers.gmo.jp/20337/ https://developers.gmo.jp/20526/ https://developers.gmo.jp/20557

みなさん、こんにちは。GMOインターネット株式会社の斉藤です。この記事は前回の「sshfsが開発終了になったので代わりにRcloneを使ってみる」の続きになります。今回はRcloneでConoHaオブジェクトストレージを操作してみたいと思います。 ConoHaオブジェクトストレージ 最初にConoHaオブジェクトストレージについて簡単に紹介いたします。 このサービスはGMOインターネット株式会社が提供しているホスティングサービスConoHaのサービスの一つです。ストレージサービスの一種で「上限無制限で容量を追加できる」「データ転送料金が無料」「多重データ保護」と言った特徴を備えています。 オブジェクトストレージへのアクセスはREST APIを通じて行います。なのでcurlなどのコマンドラインツールでも良いですし、各種プログラミング言語のSDKも揃っていますので、それらを使ってアクセスするのがよく使われる方法だと思います。 Rcloneから接続してみよう 前回からのおさらいですが、Rcloneはリモート接続を行う前に設定をする必要があります。リモートストレージ毎に「プロバイダー」と呼ばれるコネクタが用意されていて、それぞれ固有の設定を持っています。ConoHaオブジェクトストレージでは「Swift」というプロバイダーを使用します。これはConoHaオブジェクトストレージがOpenStackと言うクラウド基板をベースとしており、そのオブジェクトストレージがSwiftと言う開発名だからです。 https://rclone.org/swift/ 設定 設定を進めるにあたって、前回と同じようにRcloneの対話的コマンドを使うのですが，その前にOpenStackの認証に必要な環境変数をシェルに登録しましょう。 ConoHaのコントロールパネルにログインして、左側のメニューにあるAPIを選びます。 ConoHaコントロールパネルの「API」メニュー ここで必要になるのは、 ユーザ名 パスワード Account Service(のURL) リージョン名 テナントID になります。リージョン名はURLにあるconoha.ioの前の部分で「tyo1」などになります。これらをシェルの環境変数に設定します。以下はbashの例です。ターミナルから以下をそのまま入力します。もちろんシェルスクリプトなどにまとめても良いですし、.bash_profile等に書いてシェル実行時に設定されるようにしても良いでしょう。 export OS_USERNAME=gncu****** export OS_PASSWORD=[PASSWORD] export OS_AUTH_URL=https://identity.tyo1.conoha.io/v2.0 export OS_REGION_NAME=tyo1 export OS_TENANT_ID=[TENANT_ID] 設定できたか確認するために以下を実行してみましょう。 env | grep OS_ 環境変数が表示されればOKです。 次にRcloneの設定を行います。以下を実行してください。 rclone config ストレージの種類を選ぶ際に、30番の「OpenStack Swift (Rackspace Cloud Files, Memset Memstore, OVH) (swift)」を選択します。 $ rclone config [←ターミナルからrclone configと入力して開始します] No remotes found, make a new one? n) New remote s) Set configuration password q) Quit config n/s/q> n [←nを入力。新規にリモート設定を作成します] name> conoha-ojs [←リモート設定の名前を入力します。よく使うので短い方が良いです。後で変更可能] Option Storage. Type of storage to configure. Choose a number from below, or type in your own value. 1 / 1Fichier \ (fichier) 2 / Akamai NetStorage \ (netstorage) 3 / Alias for an existing remote \ (alias) 4 / Amazon Drive \ (amazon cloud drive) (中略…) 46 / seafile Storage> sftp Storage> swift [←swiftと入力します] Option env_auth. Get swift credentials from environment variables in standard OpenStack form. Choose a number from below, or type in your own boolean value (true or false). Press Enter for the default (false). 1 / Enter swift credentials in the next step. \ (false) / Get swift credentials from environment vars. 2 | Leave other fields blank if using this. \ (true) env_auth> 次の設問は2の「Get swift credentials from environment vars.」を選びます。 認証情報を先ほど設定した環境変数から取得すると言う意味になります。 Option env_auth. Get swift credentials from environment variables in standard OpenStack form. Choose a number from below, or type in your own boolean value (true or false). Press Enter for the default (false). 1 / Enter swift credentials in the next step. \ (false) / Get swift credentials from environment vars. 2 | Leave other fields blank if using this. \ (true) env_auth> 2 残りの設問は全てオプションなので、Enterキーを押し続けてスキップします。 最後に以下の確認が表示されますが、これにyで答えて設定は完了です。簡単でしたね！ -------------------- [conoha-ojs] type = swift env_auth = true -------------------- y) Yes this is OK (default) e) Edit this remote d) Delete this remote y/e/d> Current remotes: 接続する rcloneにはいくつかのサブコマンドがあり、これでファイルを操作します。 オブジェクトストレージの文脈では、ストレージ上にあるものを一般的に「オブジェクト」と呼びます。ファイルとは呼びません。ただここではわかりやすくするため「ファイル」と表記します。 rclone [サブコマンド] [パラメーター] しかし、オブジェクトストレージには現在何もファイルがありません。なので、rclone ls conoha-ojs: のようなコマンドを叩いても何も出てこないはずです。ただ、エラーも出ていないはずなのでこれで接続はおそらくうまくいっています。rclone copy等のコマンドで適当なファイルをオブジェクトストレージに送ってみましょう。ファイルの名前が表示されるはずです。 マウントする もちろんマウントすることもできます。ローカルに適当なディレクトリを「マウントポイント」として作成して、以下のコマンドを実行します。 rclone mount --daemon conoha-ojs: [マウントポイント] オブジェクトストレージはREST APIで操作することが前提となってはいますが、マウントできるとローカルのファイルシステムのように操作できるのでとても利便性が高いです。 もちろん、オブジェクトストレージはLinuxなどのファイルシステムとは互換性がありません。先ほどお話ししたようにストレージ上に存在するものは「ファイル」ではなく「オブジェクト」ですし、パーミッションやディレクトリも無いのです。 なので完全な代替にはなりません。操作がしやすくなるだけで、利用者側はオブジェクトストレージの特性をきちんと把握しておく必要があるでしょう。 おわりに RcloneからConoHaオブジェクトストレージを扱ってみました。最初の設定も簡単ですし、とても使いやすいクライアントです。オブジェクトストレージには他にも多くのクライアントがありますので、用途に合わせて選んでみると良いですね。 それではまた次回お目にかかりましょう。 [PR] 私が働いているGMOインターネット株式会社ではエンジニアを含め採用を強化しています。 募集職種 | GMOインターネット株式会社採用 「いきなり応募するもなぁ」と言う方は、Twitter DMで私に直接ご相談いただいても構いません。社内の雰囲気、開発現場の雰囲気、人間関係、待遇など、社内の人物からリアルな情報を知りたいという方はお気軽にどうぞ。

2022年6月21日（火）～23日（木）に日本国内最大のドローン・eVTOL（空飛ぶクルマ）展示会「Japan Drone 2022」が幕張メッセにて開催されました。GMOインターネットグループはプラチナスポンサーとして協賛し、最大規模で出展しました！今回は、ブース内デモンストレーションコンテンツ 「ホワイトハッカーによるサイバー攻撃手法デモ」の書き起こし記事となりますので、ぜひご覧ください。イベント告知：https://developers.gmo.jp/18770/ 登壇者（敬称略） GMOサイバーセキュリティ byイエラエ株式会社　高度解析部 高度解析課課長三村 聡志 ブース内デモンストレーションコンテンツ「ホワイトハッカーによるサイバー攻撃手法デモ」 早速ですが、GMOサイバーセキュリティ byイエラエについてご紹介していただけますか？ GMOサイバーセキュリティ byイエラエは、「誰もが犠牲にならない社会を創る」をテーマに、創業以来、脆弱性診断に注力をしております。「最強攻撃」、「最高品質」、そして「最低価格」、イメージとしては、皆様とよりよいものを、我々としては診断というものを使って、皆様と一緒により良いものを世の中に出していって、より良い世の中を創っていきたい、こういうことを行っている会社です。弊社は現在120名と、国内トップクラスのホワイトハッカーを含む数多くのセキュリティエンジニアを抱えております。また、ハッキングコンテストで世界1位ということですが、ここに書かれていないほかのコンテスト等でも好成績を収めている社員がいます。皆様の中にはイエラエセキュリティという名前でご存知の方もいらっしゃるかもしれないですが、2022年4月にGMOインターネットグループにジョインしまして、現在はGMOサイバーセキュリティ byイエラエとなっています。三村 ホワイトハッカーとはどういうお仕事ですか？ ホワイトハッカーという単語はマーケティングでよく使われますが、イメージとしては、企業に対していろいろ攻め込んでくる攻撃者の知見を持って、それを皆様と一緒に安全なものづくりをするために、どういうことをしたらよいか、あるいはどういう攻撃の穴があるか、を調べるとか、またそれをどのように直せばいいかというところに知識を活用できる人たちのことです。攻撃をする者が悪いことで使う知識を、守る側に使える人たち、いわば正義の味方です。三村 三村さんは、その中でどんな職種についていますか？ 私は高度解析部高度解析課課長ということで、ドローンを解析している側の人間でございます。私のいる課では、主にIoT機器、ドローンやそれ以外でもテレビやゲーム機、車載機器など診断して、安全にするといったことを行っております。三村 ホワイトハッカーのハッカーコンテストは、どういう形で行われるのですか？ いろいろな形がありますが、例えばアメリカのDEF CONだと、ハードウェアとして銀行のATMが本当に置いてあります。それに攻撃をして、中からお金を取れたらもらっていいから、どうぞやってくれと。チャレンジャーは好きに椅子に座って、パソコンを操作してお金が出せたらもらって帰る。そんな感じのコンテストがあります。三村 攻撃するからこそ分かる脆弱性について、穴を埋めていくのがホワイトハッカーの仕事だということですね。 はい。そういうことになります。三村 今回のデモについて説明して下さい。 デモの説明に入る前に、まずドローンの状況をご説明します。国内のドローンビジネス市場の想定年間平均成長率は22.8％増とありますが、様々な展示等見ていただければお分かりのように、ドローンの利用がどんどん増えていっています。業界でも、物流、農業、点検等々、様々な分野で利用が進んでいます。ドローンが最近高度化・自動化が進行していて、それに合わせてサイバー空間とフィジカル空間の融合も進んでいます。イメージとしては、以前はプロコンを手に持ってドローンを運転するのが主流でしたが、近年はPC等と接続して、フライトプランをドローン側に入れ込んであげると、ドローンがそれに従って自由に飛ぶものがあるほか、コントローラー側もスマホ等でカメラの映像がこちらに届いて、スマホの画面上にまさしくゲームみたいな感じでドローンが制御できるといったことが進んでいます。言い換えると、インターネットやパソコン同士が通信するのと同じネットワークに、ドローンがつながるようになってきたということ。それは、つまりセキュリティ上のリスクが複雑化しているということ、今までIoT機器がインターネットにつながると何か問題が起きますよ等々、色々なところで言われたりもしているのですが、それがそのままドローンの世界にどんどん入り込んできていると。そういうイメージを持っていただければ間違いでないかなと思います。三村 IoT機器であるドローンが、まだセキュリティ部分ではちょっと追いついていないのではないかと。 そうですね。IoT機器が色々なシステムに接続して、ドローンの未来もどんどん広がっていくというのはもちろん非常に素晴らしいことだと思っていますが、その時に攻撃者も穴を狙おうとする。ということで、安全を付加した状態でどんどん良くしていくということが重要になってきます。先行している例だと自動車です。皆様も自動車を運転していて、カーナビゲーションが「この先の道が混んでいます、なのでルートを変えましょう」などと案内することがあると思います。これは、カーナビが外のシステムに対して、様々なルートで通信して実現しています。自動走行など、自動車もネットワークにつながって、より良く、より面白いものができあがっていきますが、ならばどうすれば安全になるだろうか、問題があるのだろうかという検討がかなり先行して進んでいます。ドローンも今後、そういう形になっていくだろうと考えられます。また、ドローンによる事故も色々報告されています。事象としては海外が多いですが、日本でも、最近法改正などが進んで、さらにドローンの利活用が進むということで、脅威が日本でも発生する可能性はあると考えています。では、ここから、サイバー攻撃リスクの話に入ります。ドローンに対するサイバー攻撃リスクは代表的なものが2つあります。データ漏えいと不正操作です。まずデータ漏えいです。プロポやスマホなどからドローンが操作できるようになるという話をしましたが、例えばカメラ映像とドローンの位置情報が本来の操作者以外の攻撃者によって入手できる状態になると、何が考えられるか。機密エリアでドローンを使って確認していた場合、それらの情報が攻撃者に渡ってしまうと、機密エリアの情報を得るためのツールとして悪用されてしまうということもあるでしょう。もう一つが不正操作です。ネットワーク経由でフライトコントローラーに何らかの命令を送れるようになっている場合、もしここに脆弱性があると、不正な操作指令を送り込んで実行できるということになります。また、ファームウェアのアップデートをする時に、本当にそのファームウェアが正しいものかということを検証してあげないと、攻撃者が細工した偽のソフトウェアを書き込まされてしまって、悪意のあるファームウェアが実行されてしまう可能性もあります。三村 例えば、商用として、農業や防犯、セキュリティもあるでしょうけど、乗っ取って何をしたいか、ハッカー目線ではどんなことが考えられますか？ DEF CONなどで「自由にやっていいよ」と言われたら、ドローンを使って、従業員しか入れないエリアに従業員の後ろをついて入っていくことをやるかもしれません。三村 他人のドローンを使ってすることができるということですね。 はい。また、自律運転も法改正によってどんどん広がっていくと思われますが、例えば荷物を配達するドローンを攻撃して、送り先を書き換えて受け取ることもあるかもしれません。様々な不正操作による影響もあるということになります。ドローンに想定されるサイバー攻撃例をお話ししてきましたが、これらをまとめると、「通信の強制切断」「不正な制御信号の送信」「情報の窃取」「GPS偽装」の4つです。このうち、今からデモで行うものは、「不正な制御情報の送信」と「情報の窃取」です。ファームウェアはArduPilotで、一般的に入手可能でオープンな規格のものを使って、一般的な構成として作成してあります。そこに私がPCを使って、ドローンを攻撃してみようというデモです。三村 皆さんがお持ちのドローンに、第三者が影響を及ぼすとしたら、乗っ取りをするとしたら、こういうことが考えられますよというデモンストレーションというわけですね。 はい。再現手順は以下の4つです。1.ドローンが接続されているWi-Fiに接続　→墜落or何らかの方法で奪取したドローンから情報を抜き出した想定2.Wi-Fi内でネットスキャンを実施し、攻撃対象のドローンのIPアドレスを特定3.攻撃コードを実行4.DisArm処理がドローン側で実行され、正規の操作者の意図にかかわらず動作が停止今回のデモでは、1と2は完了しているものとして、3と4を今から実行しようと思います。三村 商用に使うにあたっていろいろな方が危惧されているセキュリティへの不安があるかと思います。例えば、皆さんがお持ちのドローンにこういう攻撃を仕掛けられたら皆さんどう思うか、考えていただきたいと思います。 （ドローンが飛行開始） 今から攻撃をしてみたいと思います。三村 （PCからの操作で、飛行中のドローンが床面に落ちる） 一般的に、攻撃を行おうとする場合はその場でプログラムを組もうとするのではなく、あらかじめ準備をしておいて、現地に行ってコマンドを実行してみて、動いたら儲けものといった感じで行われることが多いです。三村 これぐらい、簡単に世界中から攻撃されるリスクがあるというわけですね。 そうですね。先ほど行ったものは、同一ネットワーク上からの攻撃でした。なので、複数台が協調動作していて、同じネットワークに接続されているという時に、例えば1台ドローンを落として、何らかの方法で入手して、ファームウェアを解析して接続方法を入手すれば、ほかのドローンに手を出すことも可能になるかもしれません。また、今回のデモではお見せしていませんが、クラウド側も今回のデモ環境でもし不備があり、こちらも侵入できると、今度はクラウド側からもドローンを攻撃することができる、つまり、私がここにいなくても、なんなら地球の裏側からでもドローンを落とすことが可能になります。では、どうすればよかったのか？これが一番重要なポイントになります。クラウドとドローンのところに鍵が2つ付いています。ドローン側でいうと、IP経由のコマンド送付の時に、本当に正しい人からのコマンドかどうか、認証認可をしっかりやって欲しいのです。今の例でも、正規の運転士がドローンを上げるところまでやって、本来であれば第三者である私が先ほどはDisArmコマンド（モーターを緊急停止させる命令）をドローンに送りました。その際にドローンが、本当にプロポや正規のドライバーから送付されたコマンドか、あるいはこちらから送ったコマンドかをまったく区別せずに、すべて正規のコマンドだとして届いた順に実行してしまいます。そのために、私のDisArmコマンドもそのまま実行されて落ちた、という内容でした。なので、ちゃんと認証認可、そしてポートや不必要な機能の制限、これはぜひ行っていただきたいと思います。まさしくパソコンと一緒です。もう1つ、クラウド側です。今回、デバイス間の通信も通るようになってしまっていたという問題もありました。同じようにドローン間でできると、ドローンを落としてしまうことができるので、例えばクラウドの先にオペレーターがいるのであれば、ドローン－クラウド間は通ります、ドローン相互間は最低限の通信だけ通ります、などときちんと制限を掛けることで、きっちり設定をして守る必要があります。今回、発見した脅威は以下のものです。------------------------------■ドローンに対する脅威・遠隔からの攻撃（乗っ取り）・アップデート機能の悪用・遠隔制御機能の悪用・入出力の脆弱性------------------------------ ■クラウドに対する脅威・ドローンなりすまし・入出力脆弱性------------------------------ これ以外の問題も様々なドローンを解析すれば、ほかの問題もいろいろ出てくるだろうと考えています。ここからはサービスの説明になってしまいますが、まず1つ、セキュアな開発プロセスです。皆様のドローンを診断したいという時に、テストの段階でご依頼する方がいらっしゃいますが、その前の実装や設計、ドローンをこういう形で作りたい、ドローンを使ってこういうことをしてみたいという時に、最初にご相談いただければ、「安全にその機能を実現するためにはこういうふうにしたらいいです」「例えば暗号であればこのように使うと安全です」、または「危険です」等々のアドバイスがきちんとできます。また、後だと手戻りが発生してしまう。これも最初の方であれば手戻りなく、スムーズに開発ができることになります。三村 費用がかさむというよりも、先に外側よりも内側の鍵を閉めておきたいということですね。 そういうことです。また、IoTデバイスセキュリティ診断サービス。こちらは、実物がある時に診断をご依頼いただければという形ですが、イメージとしては、例えば「OEM元で製作された実機が来て、うちでこれを売りたいが、果たしてこれは安全なのだろうか？」とチェックする時、もしくは「いま手元にある製品について他社様から問題が報告されてきた、少し不安だけど自分のところはどうなのだろう、チェックしてもらいたい」という時に、こちらのサービスを使っていただければと考えております。サービス内容としては、以下の3つがあります。------------------------------ ①IoTペネトレーションテスト私も通常時はエンジニアとしてやっていますが、実際にドローンをバラして中のケーブルを出したり、ファームウェアのコードをアセンブラレベルで読んで問題がないかをチェックしたりするものです。②クラウド診断先ほどのドローンでは、ドローンの管理基盤がクラウド側にありました。いくらドローンが安全でも、クラウド側、管理側が安全でなければ攻撃されてしまう。ならばクラウド側も守りましょう、というものです。③スマホアプリ診断スマホでドローンが操作できるという時に、そのスマホアプリから先ほどの2つについて侵害するような情報がないかどうか。スマホアプリを悪用することで先ほどの2つに対して何か影響が出てしまうと問題ですので、スマホアプリも診断しましょうというものです。------------------------------ 三村 デバイスセキュリティ診断サービスをやると、認証のマークやバッジが与えられることになっていくと思いますが、それがおそらく世界基準になっていくのかなと思いつつ、気になるのは費用面です。導入に対して二の足を踏むところだと思いますが、何か良い案はありますか？ 経済産業省が、中小企業の皆様を対象にIoT機器等に対する脆弱性診断を無料で行う事業を実施しています。日本国内に安心安全なデバイスをどんどん広げていきたいという趣旨で、私どもと同じような複数の診断会社の皆様と経済産業省とでタイアップして、無料で診断をします。三村 安全かつ安心な空の未来を、皆さんと一緒に創っていただきたいと思います。今日はお忙しいところありがとうございました。 アーカイブ公開 今回のブース内デモンストレーションコンテンツ「ホワイトハッカーによるサイバー攻撃手法デモ」の映像はアーカイブ公開もしていますので、以下より是非ご視聴ください。 https://www.youtube.com/watch?v=EoKQ8cSk3xg さいごに この度は会場へお越しいただき、また、レポート記事をお読みいただきありがとうございます。 JapanDrone2022の開催レポートは、「Vol.01～Vol.04」を掲載しております。ぜひご一緒にご覧いただければと思います。 https://developers.gmo.jp/20337/ https://developers.gmo.jp/20553/ https://developers.gmo.jp/20557/

　SharePointのリストには複数選択が可能な列を追加できます。直接リストへ人を介して入力する場合は特に問題はありませんが、Power AppsやForms、他のリストからPower Automateなどを介してデータを登録する場合には一工夫必要となります。今回はこのSharePointリストの複数選択列への対応方法を紹介します。 リストの作成 　まずはデータ保存場所となるリストを作成します。このような感じで、好きな食べ物列には複数選択を許可しておきます。 リストに直接入力する場合は入力フォームから簡単に複数選択の項目が入力できます。 Power Appsとの連携 　次はPower AppsからSharePointのリストへ複数選択項目を入力します。一番簡単な方法はリストのウィザードから複数選択に対応したアプリを作成してしまうやり方です。 早速ウィザードを実行します。 いきなりアプリが作成されて、すでに入力フォームは複数選択対応済みです。 実際に複数選択項目が登録されます。 フォームの詳細を見てみると、コンボボックスの「SelectMultiple」プロパティーをtrueにすることで複数選択を可能が可能になっています。もちろん受けて側のSharePointリストが複数選択可能になっている必要があります。 Formsとの連携 　次はFormasを利用した場合です。Formsからの回答をSharePointのリストに保存するためのPower Automateのフローは簡単に作成できます。ただし、複数回答を可能にしたアンケートの場合受け取るフローには工夫が必要となります。まずはFormsでアンケート作成します。複数回答をONにしておきます。 入力項目を決め打ちしてうのであれば、このフローでよいのですが、これだとFormsからの複数選択項目に対応できません。 複数選択項目に対応するために、一旦ここまでの状態でテスト実行をします。 テスト実行状態でFormsから回答を行います。 Power Automateのフローで実行結果を確認します。「出力」-「未加工出力の表示」を選択します。すると、Formsからの回答内容が「body」項目に記載されています。ここで必要となるのが、"r47a5bb119a544a5a823dbca6da8a284a"この部分です。この項目名にFormsからの複数回答の内容が格納されています。 項目名が取得できたら、「選択-データの操作」アクションを追加します。 「開始」にはjson(outputs('応答の詳細を取得する')?['body/r47a5bb119a544a5a823dbca6da8a284a'])この数式を入力します。Formsからの応答で複数選択項目の部分になります。 「マップ」にはValue　@item()　とそれぞれ入力します。 @item()　は配列に格納された回答です。　こちらは保存したタイミングで「項目」に表示が変化しますが問題ありません。 最終的にこのようなフローになります。 実行してみましょう。Formsで回答して。 フローは問題なく実行されました。 Formsからのデータとして登録されています。 SharePointのリスト同士の連携 　最後にSharePointのリストの内容を他のリストにPower Automateを利用して登録する方法を紹介します。利用シーンとしては、入力専用のリストにデータが登録されたタイミングで保存用のリストにデータをコピーするなどです。このように保存用のリストを作成しておきます。 元のリストに項目が作成されたときをトリガーとします。「変数を初期化する」アクションで、種類を”アレイ”とした変数を定義します。変数に複数回答項目が格納されます。 「選択」アクションを追加して、「開始」には先ほど定義した変数を指定します。 「マップ」にはValue　@item()?['Value']　とそれぞれ入力します。 保存をすると「Valkue」に表示が変化しますが問題ありません。 最後に保存用のリストへデータを書き込みます。 全体としてはこのようになります。 実行してみましょう。入力用のリストに新規登録します。 保存用のリストに複数項目としてコピーが登録されました。 　以上、SharePointリストの複数選択列に対応した入力方法をいくつかのパターンで紹介しました。リストは高機能で手軽に利用できる簡易データベースです。Power Automateなどとの組み合わせて簡単にクラウドシステムの開発ができるようになっています。様々な状況にも対応できるような仕組みがMicrosoft365には用意されています。使いこなすほどにその生産性の高さやよく考えられた仕組みが理解できるようになります。

こんにちは。GMOインターネットの新里です。グループ会社でもあるワイン屋さんのシステム開発に関わることになりました。色々なシステム・開発を行ってきましたが、インターネットだけで閉じた世界ではなく、ワインという物が絡む世界は初めてで、なかなか面白いですね。その一部をご紹介します。 大量のワイン 数十万種のワインが世界中にはあるようです。僕自身、普段は近くの酒屋さん・スーパーでデイリーワインをたまに飲むくらいで、実際に関わるまでワインにはこんなに種類があるとは思いもしませんでした。そもそも、ワイン向けのシステムというのも関わったことが無いので、在庫管理・倉庫・ワインセラー...etc 初めて知ることで、興味津々です。 ワイン屋さんでは「置きワイン」というシステムを提供していて、保有している数千種類ものワインを管理しています。そのシステムに関わる事になりました。 2021年のボジョレー解禁に合わせてBartTimeで行われた、ボジョレー祭りにて ワインって名前だけじゃないの？ 普段はIPA（India Pale Ale）のビールばかり飲んでいて、ワインについては全くの無知でした。フランス・チリ・西海岸・イタリア...が主な生産地なのかな？くらいに思っているくらいです。こういう物理的な商品・在庫は何か一意になる商品コードや名前で管理するのが普通で、ワインは名前だけで一意になると思っていましたが大間違いだったのが最初の驚きポイントでした。 例えば...Mazis Chambertinでも、Armand Rousseau, Olivier Bernstein, Bernard Dugat-Py, Faiveleyなどの生産者で全く違うワインになることは驚きでした。実際にラベルを見てみると、全く別物であることが分かります。 他にも生産年でも異なっていたりします。つまり、「生産年・名前・生産者」でどうやら一意にワインを特定できそうです。使っているブドウ・土壌はもちろん、畑の場所（緯度・軽度・高度）・斜面といった光の当たり具合などによっても味わいが異なると教えて貰ったり、なかなかワインの世界は深そうです。 レガシーシステム ワインリストをメニューとしてお客さま（レストランさんなど）が見れるシステムを運用しているものの、古くから放置されていて、困ったことにほぼ手つかずの状態でした。各社、こういったレガシーのサービス・放置されて誰が管理者なのか？分からないシステムがある所は多いでしょう。ここではザックリ次のような状態でした。 サーバ：Cent OS 6.4Ruby：1.9 (Ruby on Rails)MySQL：5.5 RoRは、RoRというより素のRubyな感じで、他のミドルウェアのバージョンも非常に古い状態です。もちろん、スマホでWebとして見ることは出来ません。資料らしき物も無いので、コードを読んで中身を理解するしかありませんね。Bootstrap/jQueryは使っていましたが、これも非常に古いバージョンであったり、DBには主キーがなかったり、そもそもコードの管理もない...と「これは一体どういうことだ？」といった感じでした。前述したワインの一意性はどこにあるのか？と最初に思ったものの、DBは主キーも無い野ざらしの状態でした。何かをOS上のパッケージ類をアップデートすると止まってしまう可能性もあるので、なかなかセンシティブな感じです。 新バージョンに改定 皆さんだったら、こういったシステムをどうするでしょう？このまま気合で古い・デバッグも難しい環境のままメンテナンスすることも不可能では無いですが、負の遺産を先延ばしているに過ぎません。もちろんセキュリティ的なリスクもあります。システムは生き物と一緒と僕は考えていて、ちゃんと相手をしないと腐って使い物にならなくなります。そこで、思い切ってシステムを丸ごと作り変えることにしました。 全構成を入れ替えたあとの、現状のシステム 現状のシステム構成はDocker上にDB・Web(nginx)・App(Python)・DB(MySQL)・ワインラベルのメディアデータを別途管理・コード＆デザインをgithub上で管理が出来るように、全て最新にして入れ替え＆スクラッチで制作しました。もちろんPC・モバイル・iPad/Androidに対応するようフロント側も全て使えるように入れ替えですね。一気に構成が現世に近づいてきました。開発はデザイナーチームとシステム側は僕が1人で対応した感じです。 ちなみに、レガシーなシステムの入れ替えは、システムサイドからの十分な説明が必要になると考えています。例えば、古いシステムであっても利用者が居ない場合やコストだけで価値を産まない物は、そのまま放置するかクローズするという判断もあるでしょう。逆にこれからも利活用する場合は、現状の問題点・将来的な可用性について説明を行って、コストをかけて入れ替えるという説明が必要になるという訳です。システム入れ替えにおいて、必ずしも新しい物が良いわけではなく、明確な理由と説明が必要になるという訳ですね。 次は... このワインの管理の他にも色々と着手はしていますが、「ワインのラベル画像が大量にある」ということに気づきました。提供するワインのラベルの写真を撮っておいてあるので、この画像類を使って「スマホでワインの写真を撮ったら、どういうワインなのか？特定する」といったことが出来そうです。 次は実験的にワインのラベルを機械学習して特定してみたいと思います。 https://developers.gmo.jp/20787/

こんにちは、GMOインターネット長谷川です。今回は社内新卒研修でハンズオンを行ったConoHaVPSと Gatsby SSGでのブログサイト構築に関してお話して行こうと思います。 Gatsby.jsとは Gatsby is the fast and flexible framework that makes building websites with any CMS, API, or database fun again. Build and deploy headless websites that drive more traffic, convert better, and earn more revenue!https://www.gatsbyjs.com/ 端的に言えば表示の高速なWebサイトを簡単に作成出来るフレームワークです。 Gatsby.jsのプロジェクトにはgatsby-starter-blogというプロジェクトがあり、テンプレートを使って簡単にblogを作成出来ます。 Gatsby blog github page gatsby-starter-blogの仕組みとしてはReactベースで設定等記述して、それをBuildすることで静的なファイルを生成し高速表示かつセキュリティーにも強いサイトを作成します。 ConoHa VPSのDockerイメージを使ってBlog構築 Gatsby.jsの環境を一から自分で用意するにはnode.jsのバージョンやパッケージなど、気にしなければいけない部分が数多くあります。 今回はConoHaのDockerVPSイメージとnode.jsのコンテナを使ってGatsby製blogを作成していきます。 【Step１】ConoHa VPSのDockerイメージを活用する ConoHa VPSではVPSの作成時に元となるイメージを指定することで、様々なミドルウェアやアプリケーション、OSを立ち上げた瞬間から使用出来ます。 今回は、Dockerのイメージを指定してVPSを立ち上げてきましょう。まず、VPSのスペックを選択し下段のアプリケーションタブからDockerを選択しましょう。 ConoHa コントロールパネル1 rootパスワードを設定し、次へのボタンでVPSを作成します。 ConoHa コントロールパネル2 【Step２】blogのテンプレートを書き換え Dockerで環境を作成する前に必要になるファイルやテンプレートの書き換えを行いましょう。作成されたVPSにログインし、以下コマンドで作業用ディレクトリを作成します。 cd /root # 作業用ディレクトリ作成 mkdir blog cd blog # gatsby-starter-blogのテンプレートを持ってくる。 git clone https://github.com/gatsbyjs/gatsby-starter-blog cd gatsby-starter-blog/ 上記のgit cloneの部分で持ってきたgatsby-starter-blogのテンプレートを編集して行きます。まず、blogの表示名と自己紹介をデフォルトから自分に編集していきます。 # 念のためバックアップ cp gatsby-config.js gatsby-config.js.org # お好きなエディタでgatsby-config.jsを編集していきます。 vim gatsby-config.js gatsby-config.js module.exports = { siteMetadata: { // blogのタイトルですお好きなものに編集しましょう。 title: `ConoHa Blog`, author: { // blog著者の名前を自分の名前に変えましょう name: `mikumo-konoha`, // ここは自己紹介 summary: `I like Conoha VPS`, }, // blogの説明 description: `ConoHa VPS & Gatsby blog`, // siteのURL（ドメイン等を設定したら変更しましょう、ひとまずはデフォルトのままにしておきます。） siteUrl: `https://gatsbystarterblogsource.gatsbyjs.io/`, social: { // twitterのアカウント名 twitter: `ConoHaPR`, }, }, plugins: [ `gatsby-plugin-image`, { resolve: `gatsby-source-filesystem`, options: { path: `${__dirname}/content/blog`, name: `blog`, }, }, { resolve: `gatsby-source-filesystem`, options: { name: `images`, path: `${__dirname}/src/images`, }, }, { resolve: `gatsby-transformer-remark`, options: { plugins: [ { resolve: `gatsby-remark-images`, options: { maxWidth: 630, }, }, { resolve: `gatsby-remark-responsive-iframe`, options: { wrapperStyle: `margin-bottom: 1.0725rem`, }, }, `gatsby-remark-prismjs`, `gatsby-remark-copy-linked-files`, `gatsby-remark-smartypants`, ], }, }, `gatsby-transformer-sharp`, `gatsby-plugin-sharp`, // GoogleアナリティクスのIDをお持ちの方はこちらに入れます。（なければそのままでOK） // { // resolve: `gatsby-plugin-google-analytics`, // options: { // trackingId: `ADD YOUR TRACKING ID HERE`, // }, // }, { resolve: `gatsby-plugin-feed`, options: { query: ` { site { siteMetadata { title description siteUrl site_url: siteUrl } } } `, feeds: [ { serialize: ({ query: { site, allMarkdownRemark } }) => { return allMarkdownRemark.nodes.map(node => { return Object.assign({}, node.frontmatter, { description: node.excerpt, date: node.frontmatter.date, url: site.siteMetadata.siteUrl + node.fields.slug, guid: site.siteMetadata.siteUrl + node.fields.slug, custom_elements: [{ "content:encoded": node.html }], }) }) }, query: ` { allMarkdownRemark( sort: { order: DESC, fields: [frontmatter___date] }, ) { nodes { excerpt html fields { slug } frontmatter { title date } } } } `, output: "/rss.xml", title: "Gatsby Starter Blog RSS Feed", }, ], }, }, { resolve: `gatsby-plugin-manifest`, options: { // 以下のname, short_nameに関しても変更しましょう。 name: `ConoHa Blog`, short_name: `ConoHa`, start_url: `/`, background_color: `#ffffff`, // This will impact how browsers show your PWA/website // https://css-tricks.com/meta-theme-color-and-trickery/ // theme_color: `#663399`, display: `minimal-ui`, icon: `src/images/gatsby-icon.png`, // This path is relative to the root of the site. }, }, `gatsby-plugin-react-helmet`, // this (optional) plugin enables Progressive Web App + Offline functionality // To learn more, visit: https://gatsby.dev/offline // `gatsby-plugin-offline`, ], } profileの写真を変更します。SCPコマンドやSFTP、wget等を使用してサーバに入れておいたprofile用のpngをrenameしてテンプレートのものと差し替えます。（今回は以下のサイトから取得してきます。）https://conoha.mikumo.com/guideline/?btn_id=material_guideline # 今回は美雲このはの画像をwgetして取得します。 # https://conoha.mikumo.com/guideline/?btn_id=material_guideline pwd # 作業ディレクトリ /root/blog/gatsby-starter-blog # wgetでprofileにする画像を取得してきます。 wget https://conoha.mikumo.com/guideline/images/fanfic/fanfic_31.png # mvコマンドでGatsbyテンプレートで使用するprofile画像の名前に変更します。 mv fanfic_31.png profile-pic.png 【Step３】blog投稿コンテンツの用意 gatsby-starter-blogではmarkdownのファイルから記事を生成する機能があり、blogの記事はmarkdown記法で記述することが出来ます。コンテンツ用のディレクトリを用意して、その中に投稿をmarkdownで書いていきます。 pwd # /root/blog/gatsby-starter-blog mkdir markdown-contents cd markdown-contents/ vim index.md index.md --- title: Test ConoHa blog date: "2022-05-10" description: "This is a ConoHa blog test post." --- キーは変更せず 上から投稿のタイトル、日付、説明となります This is Test Post ``` echo "markdown記法でcodeも使えます" ``` 【Step４】Dockerfileとdcoker-compose.yamlの準備 ディレクトリを移動しDockerfileとdocker-compose.yamlを作成していきます。 pwd # /root/blog/gatsby-starter-blog/markdown-contents cd .. vim Dockerfile vim docker-compose.yaml Dockerfile FROM node:16 # gatsby-cliのインストール RUN npm install -g gatsby-cli RUN gatsby new my-blog-starter https://github.com/gatsbyjs/gatsby-starter-blog # デフォルトの投稿コンテンツの削除 RUN rm -fr /my-blog-starter/content/blog/* # COPYでデフォルトのprofile-pic.png,gatsby-config.jsを上書きさせます。 COPY profile-pic.png /my-blog-starter/src/images/profile-pic.png COPY gatsby-config.js /my-blog-starter/gatsby-config.js この時点ではデフォルトのテスト投稿に関して削除、その後porfile-pic.pngの書き換えとgatsby-config.jsの書き換えを行っています。実際の投稿記事等のコンテンツはdocker-compose.yamlでディレクトリ同期の設定を書きていきます。 docker-compose.yaml version: "3.3" services: gatsby: build: context: . dockerfile: ./Dockerfile container_name: gatsbyenv ports: 　　　# コンテナ8000番portとホスト側の8080番portを繋ぎます。 - 8080:8000 tty: true volumes: # bind mountでホスト側のコンテンツディレクトリとコンテナ側のコンテンツディレクトリを同期 - type: bind source: ./markdown-contents target: /my-blog-starter/content/blog/markdown-contents # コンテナ実行時にgatsby developコマンドで検証用サーバの立ち上げ command: > sh -c "cd my-blog-starter && gatsby develop --host=0.0.0.0" 【Step５】docker-composeを使ってコンテナの立ち上げ ConoHa VPSのDockerVPSイメージではdockerコマンドと共にdocker-composeコマンドも使えます。今回はdocker-composeコマンドを使ってDockerイメージの作成とコンテナ立ち上げを行っていきます。 pwd # /root/blog/gatsby-starter-blog # Dockerfileとdocker-compose.yamlがあることを確認します ls -la |grep docker # -rw-rw-r-- 1 user user 405 Jun 17 03:41 docker-compose.yaml ls -la |grep Docker # -rw-rw-r-- 1 user user 293 Jun 17 03:41 Dockerfile # docker-composeコマンドを使ってDockerfileからコンテナイメージの作成とコンテナの立ち上げを同時に行います。 # -d でコンテナをバックグラウンドで立ち上げます。 docker-compose up -d # コンテナを落とすときは同じディレクトリで以下コマンド docker-compose down 上記のコマンドでコンテナが立ち上がったと思いますので早速サイトを確認しましょう。http://VPS_IP:8080/ でサイトが立ち上がっていると思います。（サイトが見れないときはVPSのコントロールパネルの接続許可ポートの部分を確認してみてください。） サイト表示のport番号を変えたいときはdocker-compsoe.yamlを変更してみてください。 完成したblog 完成すると上記のように表示されます。投稿内容に関してもmarkdownから生成され綺麗に表示されています。 markdownから生成された投稿 おわりに Gatsby&Dockerを使用したblogの作成どうでしたでしょうか？コンテナを使うことでnode.jsのインストールやその他ミドルウェアのインストールの手間を気にすることなくblogの作成に注力出来たと言った印象を持っていただけると幸いです。テンプレートは基本的なところまでしか変えていないので、ぜひ細部まで完成出来るようチャレンジしてみてください。！！ ドメイン設定、SSL設定等の手順については今回割愛させていただきましたがConoHaVPSでは簡単にドメインの設定ができますのでご活用ください。