技術情報 の記事一覧

暗号通貨取引所「GMOコイン」、NFTマーケットプレイス「Adam by GMO」、オリジナルグッズ作成・販売サービス「SUZURI by GMOペパボ」におけるNFT連携機能——GMOインターネットグループ各社は、プロダクトという形でブロックチェーン技術をビジネス実装し、その価値を世の中に届けています。 GMOインターネットグループが2022年12月6日（火）～7日（水）の2日間、渋谷フクラスおよびオンラインにて開催したテックカンファレンス「GMO Developers Day 2022」のKEYNOTEセッションでは、ブロックチェーンをはじめとした分散システムを研究する京都大学 首藤 一幸教授をゲストモデレーターに迎え、GMOインターネットグループ株式会社の佐藤 史彦、GMOペパボ株式会社の黒瀧 悠太とともに、ブロックチェーン技術をビジネス実装する意義や課題について議論しました。  登壇者 モデレーター 首藤 一幸京都大学学術情報メディアセンター 教授 スピーカー 佐藤 史彦GMOインターネットグループ株式会社グループ研究開発本部 次世代システム研究室 室長黒瀧 悠太GMOペパボ株式会社SUZURI事業部 シニアエンジニアリングリード  （左から）ゲストモデレーター首藤氏、GMOインターネットグループ 佐藤、GMOペパボ 黒瀧 Ethereumを中心としたプロダクト開発・実証実験 佐藤が所属する次世代システム研究室は、GMOインターネットグループの事業領域で、様々なプロジェクトの技術支援・開発・解析などを行い、ビジネスの成功を支援する部門。近年は、ブロックチェーン技術の研究に注力しています。2015年末頃から技術調査を開始し、2016年2月には、スマートフォンゲームアプリのバックエンドの仕組みにブロックチェーン技術を適用することを発表。これを皮切りにブロックチェーン技術を社会実装するための研究を本格化し同年12月には、ブロックチェーン上に分散型アプリケーションが構築できるEthereum採用のPaaS型ブロックチェーンプラットフォームのβ版を公開しました。 「当初はプライベートブロックチェーンのソフトウェアをベースにプラットフォームを提供しようとしていましたが、紆余曲折あり、ParityのEthereumクライアントを使ってパーミンションド・ブロックチェーンPaaSを構築することになりました」（佐藤）GMOインターネットグループはこのプラットフォームを利用して、認証を受けた本人のみが受取可能な宅配ボックスの実証実験をセブン情報システムズと共に実施。さらに、チケットの転売防止に応用する提案なども行ったといいますが、実際の利用に至るまでは進められず、現在サービス自体はクローズしている状況です。しかし佐藤は、「こうした活動によってEthereumを中心にブロックチェーン技術を検証してきた。 この経験は、その後に開発するプロダクトにもいきている」とします。 GMOインターネットグループが取り組んできたブロックチェーン技術の歩みを伝える、佐藤 佐藤は、暗号資産関連の取り組みとして、GMO Trustが発行するステーブルコイン「GYEN」についても紹介しました。GYENは、ニューヨーク州規制当局の認可を得た世界初の日本円ステーブルコイン。基盤はEthereumからスタートしましたが、現在はそれ以外の基盤への展開を進めているところです。GYENが取引所に上場した2021年3月当時は、NFTアートが盛り上がりを見せており、GMOインターネットグループもNFT事業に参入することを決定した時期でした。このとき、NFTに関するシステム開発を一手に引き受けたのが、次世代システム研究室でした。佐藤は「いかに早く盛り上がっているタイミングでプロダクトをリリースするかが重要だった。我々のEthereum技術をいかし、4か月という短期間で『Adam by GMO』を立ち上げた」と説明します。「ブロックチェーン・ネイティブの領域を押さえるだけではなく、これまでのEC体験と同じように、一般の方でも日本円/クレジットカードで購入できるといった使い勝手を同時に実現しなければなりませんでした。これが難しく、かなり悩んだところです。試行錯誤を経て、なるべく使い勝手を優先する形で、オフチェーン処理にウェイトを寄せた設計で開発を進めました」（佐藤） SUZURIにおけるブロックチェーン活用の取り組み 黒瀧は、オリジナルグッズを誰でも作って販売できるサービス「SUZURI byGMOペパボ」の技術責任者という立場で現在、開発に携わっています。2017-18年頃には、「SUZURI People」というクリエイター支援に向けた月額制コミュニティーサービスを運用していました（現在は閉鎖）。実はもともとSUZURI People立ち上げの裏には、2016年頃からのICOブームを受け、ブロックチェーンを使ってクリエイターがトークンを発行し、ファンがそれを買うことでクリエイターを応援できるプラットフォームをつくるという構想があったといいます。 「SUZURI People」立ち上げを振り返る、黒瀧 「当時、社内のエンジニア2-3人でとりあえず本屋に行ってブロックチェーン関連の書籍を複数購入。これを読みながら、個々人がまず自分でICOをして、社内でトークンを配るという一連の流れを社内でやってみました。その後に、DEX（分散型取引所）におけるBancor Protocol（流動性を担保するための価格変動アルゴリズム）を社内でつくり、クリエイターさんに実証実験へ参加してもらいました。いろいろあってリリースができないという判断になり、SUZURI Peopleのような形で運用することになりましたが、こうした裏側があったのです」（黒瀧） しかし、ブロックチェーン技術をプロダクトに実装する取り組みは続いています。2022年5月にGMOペパボは、SUZURIの一機能として、NFTコンテンツからオリジナルグッズを作成できる機能をリリースしました。この機能は、ユーザーがブロックチェーンウォレットであるMetaMaskの情報と連携させることで、ウォレットのアドレスに紐づくNFTの画像を利用してSUZURI上でアイテムの作成ができるようになるというものです。今後は、クリエイター向けの機能としてだけではなく、「NFTの保有者で、かつ、NFTコンテンツの商用利用許諾を受けた方」も、より適切な形でオリジナルグッズを作成・販売できるような仕組みを整えていく予定です。 ブロックチェーン技術が社会に浸透するために必要なこと セッションでは、こうしたブロックチェーン技術に関するGMOインターネットグループ各社の取り組みを踏まえて、3名によるパネルディスカッションが行われました。以下ではその様子の一部をご紹介します。 首藤これまでの取り組みをはじめたきっかけや、その後どのような壁や困難にぶつかったか、それをどう乗り越えたのか、お話しいただきたいと思います。 皆さんに使ってもらえるように、いかに使いやすくするかというところが一番の課題でした。ブロックチェーンをはじめとするこの世界は、分散型、非中央集権的なムーブメントがあります。使いやすさと分散型のあいだにあるギャップを埋めることは、非常に難しいです。たとえば、セルフカストディ型のウォレットは、一般の方にとっては使いにくく、なかなか手を出しにくい。Adamの開発時には特に大きな問題になりましたね。佐藤 首藤MetaMaskにウォレット管理が集中してしまうことには、私からすると残念感があります。ただ、MetaMaskですら皆さんに使ってもらうのが難しいということもわかります。誰をターゲットにするのか、どの視点で見るのかによって、やらなきゃいけないことは変わってくると強く感じました。さらにコンシューマー寄りの仕事をされている黒瀧さんから見て、いかがでしょうか。 これからブロックチェーン技術がさまざまなところに浸透していくための鍵のひとつは、キラーアプリだと考えています。ウォレットのアプリとしてはMetaMaskがありますが、ウォレット以外のアプリもどんどん浸透していくことを期待しています。あとはFat Protocolという話もあるように、パーミッションレスで使えるプロトコルが今後増えていくことで、それに伴い開発者が増えていくこともポイントだと思っています。プロトコルレイヤーと、アプリケーションレイヤー両方の可能性がもっと広がっていくと良いですね。黒瀧 首藤それが商売にならないと発展しないという難しさもありますよね。 今ではWeb3関連のスタートアップも出てきていて、ITの世界に入るきっかけがWeb3だという若い人も多いと思います。一方で、Webアプリーケーションを10年くらい勉強してつくってきた私のような世代の人たちも、ブロックチェーンで何ができるのか、各業界でどうやってビジネスにしていくか考えているところだと思うので、世代ごとの知見をいかしてこれからさまざまなものが出てくることを楽しみにしています。黒瀧 首藤京大や東工大の学生にもブロックチェーン関連のプロジェクトにコミットしている人がけっこういますし、GMOのCVCであるGMO Web3のミーティングに参加していると、20代前半の人たちが、驚くほど新しいことを考えている様子を目の当たりにします。 Web3やブロックチェーン系のハッカソンに何回か参加したことがあるのですが、10代後半から20代前半の大学生・高校生の参加者が多かったです。懇親会で話してみたところ、自分が思っているよりもずっと真剣に未来のことを考えている方が多いと感じました。黒瀧 私の部署ではブロックチェーンをテーマにしたインターンシップをやってますが、熱量の高い学生が全国から集まってきています。若い人への期待感は感じますね。佐藤 インターネット技術黎明期との相違 セッションも終盤に差し掛かったなかで、会場参加者から3人に質問が寄せられました。 会場からも質問が寄せられて、議論が深まりました ブロックチェーン技術は、インターネット技術と比較されることがあります。今、ブロックチェーンは黎明期といわれていますが、インターネット技術黎明期と比べて、相違点や似ている点はありますか。 首藤私は研究業界にいるためかなり基礎的なことから考えてしまいますが、たとえばビットコインやEthereumは、何かすると世界中に影響が及んでしまうので、自分の範囲で局所的に実験をすることが困難です。昔のインターネットに比べて冒険しにくい構造があるように思っています。 インターネット黎明期は、オープンソースが今ほど一般的ではありませんでした。しかし、今ではソースコードがオープンなものも増えていますし、ブロックチェーンの場合は、そもそもプログラムや仕組みだけでなく、実際に流れているデータから世界でどういうことが起こっているのか、外から見えやすい環境にあります。もちろん技術を習得する必要はありますが、やる気があればなんでもやってみれるという点は、当時とは少し違うように感じています。佐藤 一方で、セキュリティの基準が最近すごく高まっていると感じています。当初はWebアプリーケーションのフレームワークも使わずに書いたものをとりあえず動かしている状態で、攻撃されてもあまり大きな問題にならないような状況だったと思いますが、攻撃者がさまざまなWebサービスを攻撃するようになってきたことで、Webサービスをつくる際にはWebアプリケーションのフレームワークを使って、意識して守るところは最小限に押さえ、堅くつくるというやり方が主流になってきました。そして、Web3は、攻撃されたときの金銭的な損失が今までのWebサービスと比べてより大きくなります。守りを意識して慎重に開発を進めなければ痛い目を見るので、セキュリティ的な観点ではハードルは高くなっているように思っています。黒瀧 首藤Web3の鬼門は、価値がネットワークに載るという点にありますね。その価値を守る必要性が高まったというところだと思います。 最後に、参加者から寄せられた「ブロックチェーン関連のスタートアップに対して、GMOとしてどのようなことを期待しているか」という質問に対して、佐藤は「我々の価値観や観点とは異なる部分。それをもとにどのような未来をつくっていくかという期待感を見せていただけることを期待している」、黒瀧は「これまで取り組んでこなかった企業が急にブロックチェーンでビジネスをやろうとしても、さまざまな理由から方向転換しづらい面がある。スタートアップには、ゼロから始められるという強みがある。スタートアップの方々には、長い将来を見据えたうえでさまざまな分野での応用事例をつくっていただき、スタートアップ同士や、歴史の長い企業とのコラボレーションが進んでいくとよい」とそれぞれコメントし、本セッションを締めくくりました。 Web3のムーブメントが拡大し、注目の集まるブロックチェーン技術。さまざまな業界や世代のプレイヤーが参入し、今後さらに盛り上がっていくことを期待したいです。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/-HuH_4HCMA4

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューション部の梅崎です今回はローカル5G案件でfree5GCを物理サーバー上で動かしどれだけのトラフィックをさばけるのか試しました free5GCを試してみた -Vol.01 https://developers.gmo.jp/23934/#%E6%AC%A1%E5%9B%9E 構成 free5GC の全コンポーネントを入れた物理サーバー(10Gbps接続✕2)を一台UERANSIM の UE & gNB 相乗りの VM を5台ずつ、3台の物理サーバー(10Gbps接続)へMEC見立ての物理サーバー(iperfの対向役)を一台 主に使ったもの 5Gコア free5GC この時点のものリンク１リンク２5Gアンテナ/端末シミュレーター UERANSIM v3.2.6リンク OS Ubuntu 22.04.1 LTSトラフィック生成ツール iperf version 2.1.5free5GC 側のサーバーCPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GBUERANSIM 側の物理サーバーCPU: Intel(R) Xeon(R) CPU E5-2670 v3 × 2ソケット（計24コア/48スレッド） メモリー: 128GBorCPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GBUERANSIM の VMCPU: 8個メモリー: 1GBMEC見立ての物理サーバー CPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GB トラフィック印加試験 1台のVMのみ # MECへUEごとにのトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 100M -c ${受け側のIP} -P 1 -u #受け側 iperf -s -i 1 -u 100Mbpsのときは問題ないですが 600Mbpsのときはそもそも、UERANSIMのVMからパケットが500Mbps前後しか出ない状態でした色々試したところ400Mbpsのトラフィック一本ならパケロス等も無いようで今回の構成のUE一台ごとの上限は400Mbpsのようです 15台のVM(UDP) # MECへUEごとにトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 100M -c ${受け側のIP} -P 1 -u #受け側 iperf -s -i 1 -u 100Mbpsを15台分は特に問題なく 100Mbps * 2本が15台分は一瞬3Gbpsになるもののすぐにセッションが切断されてしまいました 15台のVM(TCP) 次にTCPでも同様なことを試してみました # MECへUEごとにトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 300M -c ${受け側のIP} -P 2 #受け側 iperf -s -i 1 UDPをTCPにするとアップロード側が合計で最大7Gbps程度になり正直TCPよりUDPの方がスピードが出そうだと思っていたのですがTCPの方が圧倒的に多くのトラフィックを捌けていて驚いています…… 15台のVM(UDP、チューニングをしてみる) ちょっとTCP側と違いあまりチューニング方法が出てこなかったのですが一つそれらしいコマンドを見つけたので試そうと思います # UDPはソケットバッファを増やすとパフォーマンスが良くなるとのこと sysctl -w net.core.rmem_max=4194304 sysctl -w net.core.wmem_max=4194304 # MECへUEごとにトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 100M -c ${受け側のIP} -P 1 -u #受け側 iperf -s -i 1 -u 100Mbps*2を15台の動作はあまり変わらないという結果でした ここで気がついたのですが合計トラフィックが3Gbpsを超えたところでパケットがMEC役のサーバーへ届かなくなり その後、しばらくしfree5GCのサーバーへ来るトラフィックが3Gbpsを割り始めるとパケットがMEC役のサーバーへ到達するようになりました 15台のVM(TCP、 UL/DL双方向) ちょっとUDPは挙動が怪しいですが、これ以上はチューニングを頑張らないとならなさそうなので一旦TCPの方を試していきます ここまではUEからみてUL方向のトラフィックのみだったので今度はTCPUL/DL双方向にしたところ # MECへUEごと、UL/DL双方向にトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 500M -c ${受け側のIP} -d #受け側 iperf -s -i 1 ULが4.5Gbpsほど、DLが3.5Gbpsほどになりましたただ、ULのみのときと同じく数分放置しているとセッションが切れてしまうUEが数台出てくる状態です 15台のVM(TCP、DL方向) 次にUEからみてDL方向のトラフィックをテストしてみます # MECへUEごと、UL/DL双方向にトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 500M -c ${受け側のIP} -r #受け側 iperf -s -i 1 DL方向のトラフィックも7Gbps程度はでるようでしたこちらも数分放置しているとセッションが切れてしまうUEが数台出ていました 15台のVM(TCP、UL方向、7Gbps以下) 最後に今までの上限トラフィックより少ないトラフィックだとUEのセッションが切れないようになってくれるか試してみます # MECへUEごと、UL/DL双方向にトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 400M -c ${受け側のIP} #受け側 iperf -s -i 1 最初は問題なく400Mbps*15台の6Gbpsほどを処理できています ただ、こちらも一時間放置したところいくつかのUEのセッションが切れてping届かなくなっていました まとめ free5GCを物理サーバー上に構築したところ今回のサーバースペックだとTCPがUL/DL合計7～8Gbps程度、UDPがULで3Gbps程度出るようですがトラフィックを流し続けているとUEのセッションが不安定になってしまうという結果でした ただし、この不安定さの原因がUERANSIM側なのかfree5GC側なのか、はたまた相性の問題なのかが不明なので今後はUE/coreの別実装でもテストする必要があるかなと思います 最後に 安定性はさておくと現状のローカル5G環境として利用する分には捌けるトラフィックは十分かなと感じています 次回は実際のRANをfree5GCにつなげてみて安定性等々を試していこうかと思います

こんにちは。GMOインターネットグループ株式会社 フロントエンドエンジニアの山名です。この度、弊社の新卒採用サイトのフルリニューアルを担当させていただいたので、その際に新卒なりに意識したことなどをご紹介していきます！ 執筆の背景 冒頭でも少し触れましたが、この度GMOインターネットグループ株式会社の新卒採用サイトをフルリニューアルするとのことで、企画から公開までフロントエンドとしてプロジェクトに参画させていただきました。 自分が配属されてから約3ヶ月、案件としてサイトの構築から担当するのは初めてだったこともあり、何もかも手探りの状態で制作を進めました。 そんな中でも、「ここはこうしよう」「これはこっちの方がいいはず」と自分の知識を総動員しつつサイト構築を行っていたのですが、今思えば結構大事なことを考えていたのかもしれないなぁと思っています。 ということで今回は、新しくなった新卒採用サイトの告知がてら新卒一年目がサイト構築で意識したあれこれをご紹介していこうと思います！ サイト構築で特に意識したこと4選 ここからはサイト構築で特に意識したことを4つご紹介していきます！ 1.チーム内のルールから逸脱しすぎない やって当然と言われそうですが、なんならここが一番大変だった気がします。 今までの個人制作では、厳密なルールなどは決めずに好きに作っていましたし、入社後担当していた商材の保守案件では元々チーム内のルールに沿って作られたものを編集するだけなことが多かったため、いざ1から作るとなるとどうしても自分の手癖が出てしまって苦労しました。 ある程度好きに作ってもいいよとは言われていたのですが、クラスや変数の命名規則、基本的なディレクトリ構成に関しては、今後の保守に関わってくる部分なのでコーディングをする際にはこういった部内ルールを守るようにしていました。 また、GMOインターネットグループ株式会社のサイトとして公開される以上、グループ共通のヘッダーやロゴの扱いに関しても厳しいルールがあるため、そういったことも含めて構築するサイトがチーム内のルールから逸脱しすぎないように意識していました。 // 例 // クラス名はBEMで書く // JavaSvcriptで制御するものには接頭辞に「js-」をつける <section class="mainvisual"> 　　<div class="mainvisual_movie"> 　　　　<video src="◯◯"></video> 　　</div> 　　<button class="mainvisual_movie_play js-movie_play">PLAY</button> </div> 2.誰が見ても分かるコード やって当然（2回目）です。それでもやっぱり難しいのですが... ”誰が見ても分かるコードを書く” ということに関しては、サイト構築の際だけじゃなく常日頃から気をつけていることになるのですが、やっぱり後々誰が触るかわからない以上自分だけがわかるコードじゃダメだと思っています。 そんな中で今回のサイト構築、自分1人で作っていくため誰が見てもわかるようなコードなのか判断が難しく、処理を書いては見返したり、クラス名や変数名がしっかりそのものを表しているか確認したり、モジュールは適切に分けられているか確認したり... とにかく一度自分が書いたコードを何度も確認することで、なんとか分かりやすいコードを目指しました。実際できているかは分かりませんがなんとか自分の癖は薄められたんじゃないかなと思います。笑 // 例 // モーダルウィンドウ表示部分の一部処理 // 変数の中身と処理の内容がわかりやすい（はず） const $movie_play = document.getElementsByClassName('js-movie_play'); const $modal = document.querySelector('.js-modal'); const $modal_movie = document.querySelector('.js-modal_movie'); const $modal_close = document.querySelector('.js-modal_close'); const $modal_back = document.querySelector('.js-modal_back'); for (let i = 0; i < $movie_play.length; i++) { $movie_play[i].addEventListener('click', () => { 　　　　const src = $movie_play[i].getAttribute('value'); 　　　　$modal_movie.setAttribute('src', src); 　　　　$modal.classList.add('is-active'); 　　　　$modal_back.classList.add('is-active'); }); 　・・・　 } 3.デザイナーとの連携 次にデザイナーさんとの連携です。 新卒採用サイトのリニューアルにあたり、同期のWebデザイナーがサイトデザインを担当していたのですが、コンセプトが「枠組みを壊せ」なだけあってダイナミックでおしゃれなデザインを作ってくれていて、それに合わせてアニメーションの提案やデザインの調整等の連携を積極的に行っていました。 分からないことや確認したいことも含めて些細なことをこまめに共有し合うことで、生産効率がかなり向上していたように思います！ 4.自分らしさを出す このままでは部内ルールに沿って、もらったデザインをコーディングしているだけなんですが、やっぱり自分らしさは少し出したい！といことで、企画から公開までの流れでちょくちょく自分なりに提案をさせてもらっていました。 結果的には、前述したアニメーションの提案やSEO対策、サイトの軽量化や運用に関わる部分で自分なりに考えた構築ができた気がします。 こうして自分らしさを少しずつ出しながら進めていくことで、終始楽しみつつモチベーション保って制作ができていたので、改めて大事なことだなぁとしみじみ感じました。 終わりに いかがでしたでしょうか。 分からないことだらけのサイト構築で、デザイナーや先輩方に助けていただきながらではありますが中々のものができたんじゃないかなーと思ったりしています。 実際にリニューアルしたサイトはこちらになります。 気になる方は是非見てみてください！ また、GMOインターネットグループ株式会社では、現在「次世代リーダー」を募集しております。 詳しくは上記サイトからご確認いただき、是非エントリーしてみてください！

GMOインターネットグループでは、2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day 2022」を開催しました。「GMO Developers Day」は、GMOインターネットグループの最新技術を活用した新しい挑戦や、世の中が抱える課題解決への取り組みを、事例を交えて紹介するテック（技術）カンファレンスです。開催3回目となる今年は「Add on 技術の拡張で、新たな世界へ」をコンセプトに、初のオフラインとオンラインのハイブリッド開催で、全34セッションをお届けしました。GMO Developersではそんな大盛況を収めた同イベントのセッションを紹介していきます。初回は、初日KEYNOTEを飾った『CTO対談～技術責任者会議～』の模様をお届けします。 登壇者 スピーカー 三谷 隆GMOペイメントゲートウェイ株式会社 専務執行役員CTO 安藤 健一郎GMOリサーチ株式会社 取締役CTO 栗林 健太郎GMOペパボ株式会社 取締役CTO  モデレーター 稲守 貴久GMOインターネットグループ株式会社　グループ研究開発本部 マネージャー GMOペイメントゲートウェイ 三谷 GMOリサーチ 安藤  GMOペパボ 栗林GMOインターネットグループ 稲守 2022年、グループ各社CTOが集う技術責任者会議が発足  GMOインターネットグループにはインターネットインフラ事業をはじめとして広告・メディア・金融・暗号資産と様々な事業会社・開発組織があります。  これらの技術力を強化し、グループシナジーの最大化を図るため、今春から開発者の最高意思決定機関として「技術責任者会議」が組成され、グループ各社CTOは、毎週1回程度の頻度でミーティングを行っています。  このセッションでは、GMOインターネットグループから、GMOペイメントゲートウェイ株式会社の三谷 隆、GMOリサーチ株式会社の安藤 健一郎、GMOペパボ株式会社の栗林 健太郎と、この技術責任者会議のボードメンバーである3人のCTOが登壇して、GMOインターネットグループの開発体制における現状から、これからの展望について議論を交わしました。  モデレーターはGMOインターネットグループ株式会社（以下GMOインターネットグループとする）で、グループ研究開発本部 マネージャーを務める稲守 貴久が担いました。  それぞれのCTOは技術責任者会議が発足してから、どのように感じているか。参加者が同じCTOという立場のため、「自分一人の悩みが話せるようになった」と言うのは三谷。安藤も「横の繋がりが作りやすくなった」と歓迎します。  栗林は、「GMOインターネットグループは100社ぐらいあって、色んな会社に凄い技術者がいるが、それが知られていない」と話し、横連携ができるようになったことで、そうした社内の「ヤバいエンジニアをもっと広めたい」と言います。  各社それぞれの違いから議論が深まる そんな交流を深めているCTO同士の対談は、「質問1000本ノック」（実際に1000問あったわけではありません）からスタート。「山と海なら海派である」というライトなものから、「現在、開発組織で課題がある」といった会社組織にまつわるもの、「マネジメントよりコードを書いている方が好きだ」というCTOらしい質問に次々と回答していきました。  質問1000本ノックに次々と回答する3人  その中で、「開発組織で課題がある」という質問には3人がいずれも「○」と回答。詳しく話を聞いてみると、実は全員が同じ「人材採用」に課題を感じていました。3人とも「やりたいこととは山ほどある」と異口同音に語りつつ、人が足りなくても採用や評価が難しいという意見で一致しました。  ただ、「CTOの最大の仕事は技術者採用だ」との質問には全員が「×」。栗林は「採用はかなり大きな仕事」としつつ、外部に対して自社の技術的な方向性、能力、サービスの方向付けをすることが重要だと指摘。「テクノロジーによるカルチャーを体現し、それを作り上げていくのが重要な仕事」と話します。  安藤は、「一緒に働いている人が幸せになって欲しいし、楽しく働いて欲しい」と話しつつ、「転職するのもありだし、そういうときにその人の市場価値が高まるような状態になるように、お互い切磋琢磨して向上できるような環境にしていきたい」としています。  採用面の質問では、CTOの面々は「スペシャリスト」よりも「ゼネラリスト」を採用したいと回答していました。三谷は、「決済をずっとやっていたスペシャルの人が欲しいというのはありますが、なかなかそういう人はいない」とスペシャリストの少なさを指摘しますが、そもそもGMO-PGには多くの決済系システムが稼働しており、エンジニアも揃っています。そのため、システムやコードが「先生」となって学ぶことができるので、ある程度のコードを触った経験があって、それが好きで、「チャレンジしたい強い思いがある人であればいい」と言います。  安藤は、特定のシーンでスペシャリストが欲しいという状況はあるといいますが、必要な技術、人物像がその時どきで少しずつ異なるため、「いろいろやりたいという人の方が結果的にいい」と指摘します。  栗林は、「スペシャリストは"どれだけ深掘りできるか"というのに対して、ゼネラリストは"どれだけ横に広げられるか"」と話し、スペシャリストが専門性を深掘りするのと同様に、ゼネラリストは幅を広げることを求めます。「技術を極めたり、影響力を広めたり、できることを増やしたり、そういうマインドを持って欲しい」というのが栗林の考えです。  「Web3はこれからインターネットの主流になる」という問いに対しては、三谷と栗林が「×」と回答。栗林は、「色々なWebが並列するのでは」という意見。Web3のキーワードとして「分権化」があり、それだけでは主流にはならず、Web2的、Web3的と言った形で並列するという考え方です。  3人並んだCTOは、それぞれB2BのGMO-PGとGMOリサーチ、B2CのGMOペパボと立ち位置が異なります。そうした各社の違いについて問われた三谷は、「決済の裏側のB2Bの仕事が多いので、堅い面も半分ぐらいはある」としつつ、全てを「堅く」してしまうとコストがかさんでしまうため、内製化によって「省力化できるところは省力化して、それ以外はきちんとやって、メリハリを付けている」というのがカラーだといいます。  GMOペパボは、コンシューマ、小規模事業者向けですが、レンタルサーバーなどインフラやプラットフォームに近い業務のため、「そんなに派手なところがあるわけではない」と栗林。とはいえ、「僕もインターネットが好きでこの業界に入っていますし、インターネットが好き、プログラミングが好き、自身もクリエーターという人が（社員には）多いので、和気あいあいと好きなことをみんなで楽しみながらやっている」というのがカラーなのだといいます。  各社それぞれの違いから議論を交わす3人  さいごに 最後に参加者への一言を求められた3人。三谷は、エンジニアが成長するための3つコツとして、まず「厳しい非機能要件のプロジェクトなどに携わること」を挙げます。システムのデザインは、非機能要件が厳しいほど難しくなるので、そこにチャレンジすることで成長してほしいといいます。  2つ目のコツとして、「成長している市場や業界、将来性のある会社に身を置いてほしい」と（三谷）。こういったところは変化が激しいので、何をすべきか、将来を見越してどうシステムなどを作るか、といったデザインが非常に重要になるためだそうです。  3つ目はサービスやシステム、プロジェクトを担当する中で、「単に自分の担当領域だけに閉じこもるのではなく、全体に興味を持って知ろうとすることを心がけてほしい」と言います。書籍で学ぶだけでなく、自身が関わっているプロジェクトやサービスなどで担当以外に興味を持てば、周囲にはその道のプロがいるので、聞いて、吸収して次に生かせるようになって成長していってほしい、というのが三谷の考えです。  安藤は、日本CTO協会の理事に栗林が参加していることから、参加者や視聴者にCTOが居れば加入して一緒に話したいとコメント。栗林は、GMOインターネットグループの技術力、事業内容の面白さを「知ってほしい」と強調。100社以上というグループ企業には、「どこかに刺さる企業があるはず」と栗林は話し、エンジニアにとって楽しめたり成長できたりする場がどこかにあるとして、GMOインターネットグループにチャレンジしてほしいとアピールしていました。  アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=dF-GHc-YzLg&t=405s

こんにちは。GMOインターネットグループ株式会社 セキュリティエンジニアの赤瀬です。私は2021年に新卒入社し、現在はセキュリティチームでWebアプリケーションの脆弱性診断を行っています。まだ脆弱性診断を始めて2年目のひよっこエンジニアです。脆弱性の勉強＋知識の定着を兼ねて今回記事を執筆することになりましたので書いていきます。 はじめに 開発経験がある人でもない人でもエンジニアをやっている人が一度は聞いたことがあるであろうクロスサイトスクリプティング（以下、XSS）には大きくわけて反射型、蓄積型、DOM-Based XSSの3種類があります。簡単に上記3種類の説明を（ほんとにさらっとだけ） 反射型XSSユーザからのリクエストに含まれるスクリプトをそのままレスポンスに出力してしまい発動するXSS蓄積型XSSユーザが入力したスクリプトがWebアプリケーションに保存され、別のユーザがその保存箇所を読み込んだ際に保存されたスクリプトが発動するXSSDOM-Based XSSJavaScriptを使ってブラウザに表示しているHTMLを操作する場合に、攻撃者の用意した意図しないスクリプトが発動するXSS その中でも今回は、蓄積型XSSについて実際にWeb画面で挙動を紹介できればと思います！ 1.注意事項 検査により、意図せずにシステムの停止や不具合を引き起こしてしまう可能性があるため、紹介する手順を試してみたい場合は本番に影響を及ぼさない検証環境か、それ専用に作られたテストサイトでの作業をお勧めします。自組織が管理しないWebアプリケーションへの検査は、場合によっては不正アクセスとして違法となる可能性があります。 2.蓄積型XSS XSSとは、Webサイトに攻撃者がスクリプトを登録しておくことで、一般のユーザにそのコードを実行させること。攻撃例をあげると、Cookieの情報を抜き取ったりするなどがあります。今回紹介する蓄積型XSSというものは、攻撃者がWebサイトに直接スクリプトを登録し、そのWebサイトの一般利用者が該当のページを読み込むたびにそのスクリプトが実行されてしまうものです。 百聞は一見にしかずということで、実際にどういうのか見てみましょう。※今回は自分のローカル環境にECサイトっぽいものを作成して利用しています。※CSSなど凝ったものを作っていないのでサイトの見た目はご容赦ください。 ということで早速画像のような商品登録画面があるとします。今回は、商品登録を管理者ページでしかできないようなサイト仕様にしました。 普通の利用者が見る商品一覧ページはこんな感じです。最低限の実装って感じですね（自分で作ったんですけど）。 ということで、先程の管理者ページに何らかの方法で攻撃者がアクセスし商品登録できると仮定してスクリプトを仕込んでいきたいと思います。わかりやすいように下記のデータを商品として登録していきます。 商品名：スクリプト商品説明：’任意’ <script>alert(1);</script>価格：500円 無事登録することができました。本来、ここで<>のような記号が入力値にあった場合にそもそも登録できないようにしたり、特殊な意味を持つ記号をサニタイジングして登録する必要があります。 スクリプトを登録することができたので、一般利用者がサイトを利用する際にどういう挙動になるか見てみましょう。利用者は普通のECサイトだと思い商品一覧ページにアクセスします。すると先程登録したスクリプトが読み込まれ処理が実行されるので画像のようにJavascriptのホップアップがあがりました。 3.Cookie拾ってみる 上記を応用してJavascript内にCookieを表示させセッションIDなど取得してみようと思います。といってもやり方は先程同じで登録するデータの値を下記に変更するだけでCookieを取得することができます。 商品名：クッキー商品説明：’任意’ <script>alert(document.cookie);</script>価格：500円 登録できたので商品一覧ページにアクセスしてみます。 すると画像のようにPHPSESSIDをまるっと取得することができました。 少し見辛いですが、商品一覧ページのレスポンスを見てみるとスクリプトがそのまま登録されています。これにより利用者がサイトを読み込むたびにスクリプトが実行されてしまい、Cookieの情報を窃取されてしまいます。Cookieを窃取されてしまうとアプリケーションをのっとられたり、クレジットカード番号などの個人情報を不正に閲覧される可能性があります。 4.対策 3.の中でも少し触れましたが対策方法はいくつかあります。 今回はこんな対応方法があるよ！というのを一部紹介するので、その他の対策方法や、実装方法について詳細気になる方は是非調べてみてください。 対策方法 そもそも＜＞などの特殊な意味を持つ記号を登録しようとした際にエラーとして登録できないようにする。例）電話番号の入力欄は数字のみ許可。ふりがなは半角カタカナのみ許可。など入力データをそのまま登録せず、登録する際にサニタイジング処理を行う。サニタイジングとは「無害化」という意味で＜＞、＆などの記号を「&lt」「&gt」などに置換することでスクリプトとして処理が実行されないようにすることです。 5.おわりに いかがでしたでしょうか。文章だけだとわかりづらい脆弱性の挙動も、Webサイトの画面を見ながらだと意外とわかりやすい気がしてきませんか？この記事を読んでくださった方が自分の作成したサイトや今後開発を行う際に、入力値のサニタイズなど気にかけるようになってくれれば幸いです。

11/27（日）「JJUG CCC Fall 2022」がハイブリッド形式で開催され、GMOインターネットグループはセッションスポンサーとして協賛・登壇しました！今回はGMOペイメントゲートウェイ株式会社が登壇したスポンサーセッション「カード決済基幹システム　レガシーの克服と無停止更改の挑戦」について、登壇レポートをお届けいたします。イベント告知：https://developers.gmo.jp/26265/本記事はこちらのスポンサーセッションの書き起こしとなります、ぜひご覧ください。 はじめに 登壇者紹介 GMOペイメントゲートウェイ株式会社システム本部IT戦略ビジネス統括部 プロセシング部 羽鳥 樹 羽鳥樹と申します。新卒でインターネット広告の営業としてキャリアをスタートしました。仕事の中で広告配信システムに触る機会があり、当時はまだ珍しかったWebアプリケーションに感動し、こういうものを作れるようになりたいと一念発起し、転職してプログラマーのキャリアをスタートしました。転職先はクレジットカード会社や金融業界を主なお客様としていたので、そこでクレジットカード業界の基本的な知識とシステム開発のノウハウを身につけました。その後、2016年にGMOペイメントゲートウェイに入社しました。前職の経験を生かし、今回お話しするシステムやクレジットカード会社様向けのシステムの開発に従事しております。一方で、これまで主に決済を処理するシステムに携わってきましたが、今後はいわゆるWebプリケーションの開発にも携われるよう、チャンスを探していこうと思っております。 会社概要 弊社は商取引において必ず発生する「決済」のインフラを、幅広い業界のお客様に提供させていただいております。主力事業は決済代行事業で、インターネット上でビジネスをするお客様に向けて様々な決済手段を提供させていただいております。今回お話しするシステムも、決済代行事業のシステムとなります。ほかに、後払い等の金融関連事業や、マーケティング支援サービス等の決済活性化事業も提供しております。 1.システム概要 まずはシステムの概要からお話しさせていただきます。今回お話しするシステムは、弊社システムの中でクレジットカード決済を一手に引き受けているシステムとなります。カード決済基幹システムと呼ぶことにいたします。お客様である加盟店会社は、弊社のサービスを決済フロントシステムのAPIを呼び出すことでご利用されています。決済フロントシステムは、カード決済をはじめ、QRコード決済や電子マネー決済といった、様々な決済手段を提供しております。そのうちカード決済については、カード決済基幹システムのAPIを呼び出すことで実現しています。カード決済と一言で言っても、弊社システムの先にはアクワイアラという加盟店管理を担うカード会社様や、カード会社様との窓口を提供するネットワーク会社様などがあり、それぞれ接続方式や電文フォーマットに差異があります。これらの差異をこのシステムは吸収しております。フロントシステムはこのシステムのAPIを呼び出すだけで、その背後にある複雑さを意識せずに、カード決済を実行することが可能です。カード業界では、FEPなどと呼ばれています。FEPはパッケージ製品を使うケースが多いですが、弊社はすべてJavaでスクラッチで開発しております。2013年頃から稼働しておりますが、当時でも比較的古いとされる実装が多く残っているので、いわゆるレガシーシステムに分類されると思われます。 2.更改プロジェクトについて 更改プロジェクトは、2020年4月より開始しました。当初はサーバーの保守期限切れのため、サーバーの更改のみが範囲でしたが、流通取引総額の拡大に伴い、その次の更改となる5年後の取引量を処理できないということが懸念されました。この表は、当社グループ連結の流通総額となりますが、更改プロジェクト開始前の5年で年平均成長率は27％、更改プロジェクト開始から現在まででは、年平均成長率が35％となっており、取引件数も同様に成長しております。また、クレジットカード決済はその大部分を占めており、カード決済基幹システムに掛かる負荷も上がり続けていました。当初案はサーバーのスケールアウトで対応することを検討しましたが、アプリケーションの保守運用をしている中で、ボトルネックと思われる個所がいくつか見つかっていました。それらを解消することでアプリケーションの処理性能を向上させることができると判断し、サーバーのスケールアウトは後回しにして、まずは改修を実施することにいたしました。 3.処理性能向上について ボトルネックとして挙がったのは3点で、いずれもDBに関するものです。まずはレガシーシステムにありがちな、必要以上に多いDBアクセスです。詳細は後ほど説明いたしますが、生存期間の短いデータをRDBで永続化しているというケースになります。次は、SELECT FOR UPDATEによるレコードロック待ちです。最後は、スケールに比例するSQL実行の長時間化となります。いずれも、性能に大きく影響を及ぼすもので、また取引量の増加に伴い影響も大きくなるものでした。これらは影響が顕著になりシステムへの影響も見過ごせない段階になってから改修しようとしても、いずれも一朝一夕に改修できるものではありません。こうした背景もあり、影響が顕著になる前であり、システム更改をプロジェクトとして行うこのタイミングでアプリケーションも改修を実施することになりました。課題はすべてをRDBで解決するアーキテクチャに起因しているため、解決方法として挙がったのはインメモリDBの使用でした。DBへの負荷を分散し、スループットを向上させるのに適切と考えたからです。インメモリDBとしては定番として名前が挙がり、社内でも使用実績があったRedisが候補として挙がりましたが、私自身がアプリケーションサーバーのPayara Microをほかのプロジェクトで使用した時に、その一部機能として使用した経験があったこと、また改修内容を検討する中でインメモリDB自体に業務処理を乗せて実行させるということが想定されました。このような理由から、Javaで作成したロジックを乗せられるインメモリDBとして、HAZELCASTを使用することに決定しました。 4.HAZELCAST HAZELCASTは、Pure Javaで開発された、In Memory Data Gridの製品となります。IMDGと略したりします。IMDGの他の製品では、Apache GeodeやOracle Coherenceがあります。HAZELCASTはアプリケーションサーバーのPayaraやVert.xなどで使用されています。In Memory Data Gridとは、クラスタリングされた複数のサーバーのメモリに分散してデータを保持することで、高速なデータへのアクセスとスケーラビリティを実現させる技術です。データアクセスするアプリケーションは、複数のサーバーにデータを保持されているにもかかわらず、あたかも1つのDBにアクセスしているように見えます。続いて、こちらは基本的なHAZELCASTの使い方となります。HAZELCASTのAPIを使用して、まずMapを取得します。取得した型はIMapという型で、こちらはConcurrentMapを継承しています。ConcurrentMapはjava.util.Mapを継承しているので、普段使い慣れているMapのput、Get、removeといったメソッドを使って操作することができます。また、Map同様にジェネリクスでKey、Valueの型を指定可能なので、任意のクラスを指定することも可能です。この例では、Customerというクラスを定義して、Valueにしています。普段はネットワーク越しにデータをやりとりするので、独自クラスを定義する場合にはjava.io.Serializableを実装する必要があります。HAZELCASTのクラスタ内の各ノードのIPアドレスやポート、そのほかMapに関する各種設定は、hazelcast.xmlというファイルで定義します。 5.処理性能向上のための改修 ▸ 処理性能向上のための改修① まず、多過ぎるDBアクセスの解消を目指しました。現行システムは加盟店単位の流量制御と、カード会社単位の流量制御をいずれもRDBで実現していました。取引処理中に流量の集計用テーブルにレコードをインサート、加盟店単位の流量をCOUNT()で集計し、流量のチェックを実施、さらに送信するカード会社を決定してレコードをアップデート、カード会社単位の流量を再びCOUNT()で集計し、チェック、処理の終わりにレコードの削除と、流量制御のために3回コミットが発生していました。取引量×3回コミットが発生するので、取引量とともに増加していくコミット回数はDBの負荷を上げ、処理遅延に繋がっていました。一方で処理におけるデータの生存期間は非常に短いため、そもそもRDBで処理するのは適当ではないと判断し、DBへの負荷軽減を目的にHAZELCASTに移行することに決定しました。改修は、処理をすべてそのままHAZELCASTに移行しました。HAZELCASTではSQLを使用できることがわかったので、現行と同様の処理にできると判断しました。具体的には、加盟店IDとカード会社コードでそれぞれ独自のクラスのフィールドに定義し、現行と同様に取引処理時にMapに登録、加盟店IDで集計してチェック、カード会社コードを決定したら反映、カード会社コードで集計してチェック、最後にMapから削除というふうに改修しました。処理を移行するにあたり、カウンタを使うことも検討しました。HAZELCASTにはIAtomicLongというクラスも用意されていて、カウンタとして使用することもできますが、カウンタだとインクリメントしたあとにプロセスが停止するなどの理由でデクリメントされず、件数が戻らないというケースが懸念されました。HAZELCASTではMapにTime To Live値、いわゆる生存期間を指定できます。このため、Mapであれば万一そのようなことが起きても時間が経過すれば件数が戻るので、この方法がベターと判断しました。通常、許容限度の流量はある程度余裕を持つので、カウントが戻らないことで大きな障害に繋がるというケースはまれだと思いますが、カウンタが戻らないということはあるべき形ではないと考え、このような修正としました。 こちらはコードの例です。左側が独自に定義したクラスです。フィールドに加盟店IDとカード会社コードを定義しています。右側は集計するSQLの例です。ちょうどSQLのWHERE句を書いています。valuesの引数にPredicates.sqlで指定した条件を与えると、条件に合致する値のコレクションを取得できます。このコレクションのサイズを件数として取得するようにしました。 ▸ 処理性能向上のための改修② 次に、SELECT FOR UPDATEによるロック待ちの解消です。カード決済基幹システムに接続するシステムごとに最大流量が決まっており、これを制御するための仕組みでSELECT FOR UPDATEを使用していました。先ほどカウンタについて少し触れましたが、この処理ではまさにRDBを使用してカウンタのインクリメント、デクリメントをしていました。テーブルには接続システムごとのレコードが登録されており、カウンタがあります。このカウンタを複数スレッドがシーケンシャルに更新できるように、SELECT FOR UPDATEでレコードをロックしてからインクリメントして更新、チェックが終わったらSELECT FOR UPDATEで再びレコードロックしてからデクリメントして更新、というふうに処理をしていました。システム単位で1レコードを使用するので、取引が集中すると複数のスレッドが同時にロックを試みるため、ロック待ちが発生していました。また負荷が上がるほどロック待ち時間が長くなるため、改修が必要と判断しました。改修内容としては、前ページの改修と同じく、接続システム単位で現在の件数を集計して流量をチェックするようにしました。 ▸ 処理性能向上のための改修③ 最後に長時間SQLの解消です。カード決済基幹システムには期限切れ取引の取消処理というものがあります。これは取引の処理後に一定の有効期限内に確定要求を送信元システムから受けないと、カード会社に取消要求を送信して取引自体なかったことにする機能です。送信元システムとの取引の整合性を明確に保つために、確定要求を受けない限りは取引を成立させないというものです。DBのトランザクションにおけるコミットのようなものと考えていただければと思います。この処理は、取引発生時に取引期限管理用テーブルにレコードを登録し、確定要求を受けると確定の状態に更新。その後、取引期限完了テーブルから定期的に確定に更新されていないレコードを期限切れ取引として抽出して、カード会社に取消要求を送信していました。この抽出時に発行していたSQLは、テーブル内のレコード全件を対象に検索していました。テーブルのレコードは1日以上は保持せずに削除していたため、検索対象は限られていたものの、1日の取引量が増えるにつれ、SQLが遅延することは目に見えていました。取引の抽出はバッチ処理でやっておらず、決済処理用のプロセスの内部で、定期的にスレッドを起動、具体的にはScheduledExecutorServiceを使用していました。このため、決済処理と同じコネクションプールを使用していたので、SQLの長時間化はコネクションを長時間保持してしまうので、コネクションプールの枯渇に繋がり、決済ができなくなるという事態に繋がることが懸念されました。このため、この処理もHAZELCASTに移行することにしました。HAZELCASTでは、RDBのテーブルに相当するMapの追加や削除といったイベントに対してイベントリスナを登録、任意の処理を実行させることが可能です。この機能と、MapのTime To Live値を使用して改修を実現しました。まず、取引発生時にHAZELCASTのMapに取引を登録、その後確定要求を受信したらMapから登録した取引を削除するように改修しました。MapにはTTLが設定されているので、一定の時間が過ぎたらエントリが期限切れとして削除されます。確定要求を受けない取引はリストに残り続け、期限切れとして削除されるので、このイベントに対してリスナを起動し、取引情報を使用してカード会社に取消要求を送信することにしました。この改修により、SQLの発行自体をなくせたので、取引量の増加によりSQLが遅延するという懸念をなくすことができました。こちらは具体的なコードの例です。左側がEntryExpiredListener、つまりエントリの有効期限切れに対するリスナです。引数のエントリイベントから削除されたエントリを取得することができます。ほかにも、追加時のリスナや削除時のリスナのインターフェースも定義されています。作成したイベントリスナはhazelcast.xmlでどのMapに対するリスナなのかを定義することができます。なおhazelcast.xmlで設定する内容はプログラムでも設定することが可能です。イベントリスナのインターフェースはFunctionalInterface(関数型インターフェース)なので、ラムダで書いて登録することも可能です。 6.システム移行時の課題 ▸ 新旧システムの並行稼働 ここまで改修してきて問題となったのは、新システムのリリースでした。サービスへの影響を最小限にするために、カナリアリリースでリリースすることになりました。サービス停止はなしでリリースするので、ロードバランサに新システムを繋げて、新旧システムで取引を処理するのですが、旧システムはRDB、新システムはHAZELCASTを使用することになります。この時、別々のDBを見ているので、例えば新システムで取引を処理し、旧システムで確定要求を処理した場合はRDBには取引が存在せずエラーとなり、HAZELCASTに登録された取引は削除されずに残り続け、取消要求の送信対象となってしまいます。つまり、確定要求を受けているにもかかわらず取消をされてしまうので、加盟店様とカード会社様との間で取引の齟齬が発生する可能性があります。これは非常に問題なので、確実に影響を出さないようにリリースする方法を見つける必要がありました。最終的に、並行稼働期間中、新システムはRDBとHAZELCASTの両方に処理を行うように改修し、その上でHAZELCASTから取消要求を送信する際にRDB側に同じ取引が存在するかを確認するようにしました。この図の例だと、新システムで取引を処理した際に、RDBとHAZELCASTの両方に登録、確定要求を旧システムで受けたら、RDBの取引の状態を更新します。その後HAZELCASTに登録された取引は期限切れとなり取消要求送信の対象となりますが、送信前にRDBを参照し、レコードが存在する場合は処理を中断することで取消要求を発生させないようにしました。これで、取消要求の送信処理自体を旧システムに寄せることが可能となりました。なお、HAZELCASTからRDBへの接続は、特にHAZELCASTでサポートされているわけではないので、独自に実装する必要がありました。当初発生したタイミングでDbConnectionを生成して接続することも考えましたが、同時に大量に取消要求が発生した場合、コネクション生成のオーバーヘッドが処理性能に影響を及ぼすことなどが懸念されたので、コネクションプールを使用することにしました。HAZELCASTには、起動時や停止時といったイベントに対してリスナを作成することができます。これを使用し、起動時にコネクションプールを生成、停止時に破棄するようにしました。なお、コネクションプールにはSpring Bootでも使用されているHikariCPを使用しました。 ▸ 本番移行でヒヤリ 本番移行でヒヤリとした話ですが、こちらはちょっとした小話程度に聞いていただければと思います。本番移行にあたってはリハーサルも実施して想定外の取消要求が発生しないことを確認した上で当日を迎えました。ですが、いざ新システムを稼働させ取引を処理させたら、新システムで大量の「対象の取引が存在しません」というログが発生し、即座に新システムをロードバランサから切り離すことになりました。これは、旧システムで取引を処理し、新システムで確定要求を処理した場合は、HAZELCASTに削除対象が存在しないというのが原因でした。移行期間中、新システムはRDBとHAZELCASTの両方に処理をするよう改修したので、確定要求を処理する時は、RDBの取引の状態を更新していました。このため、取消要求は発生せず、業務影響はありませんでした。ただ、移行リハーサル中は想定外の取消要求が発生しない、エラーログが発生しないという点に集中していたので、WARNログが出るところまでは把握しておらず、本番で初めて知ることになりました。結果として問題はなかったものの、移行当日はものすごく緊張していたのでほんとに肝を冷やしたのを覚えております。 7.まとめ 最後に、システム更改の成果と今後の課題です。システム更改からは1年経過しましたが、既に最大秒間取引件数の7割程度まで処理しています。かなり想定より早いペースですが、現状特に処理遅延などを起こしたり、障害に繋がるといった問題は発生しておりません。更改前よりもずっと安定して稼働しているという印象です。また、DB側のモニタリングで、更改前後で同程度の取引が発生した1日のDBの総アクセス時間を比較しましたが、更改前の約2/3程度まで低減させることができました。DBへの負荷は相当程度低減できたと思います。これが安定稼働に繋がっていると考えられます。また、旧システムと比較し、新システムではシステム内部の処理時間を200ms程度削減することができました。今後の課題ですが、運用に関する改修が必要と考えています。ひとつは、システムの異常をプロアクティブに検知するための仕組み、具体的にはAPMやElasticsearchなどを使ったログ分析といったことが考えられます。そのための足場作りとして、システム更改のタイミングでログ集約の仕組みを導入しています。また、CI/CD対応としてリリースの自動化とテスト自動化を予定しています。いずれも既に着手していますが、今後本格的に導入していく予定です。それから開発効率化のために、フレームワークの導入を検討しています。実は、決済基幹システムはフレームワークを使用しておらず、JDKに含まれるクラスのみでほぼ作られています。このため開発効率に問題があると考えられているので、大胆なアプリケーションの改修となりますが、フレームワークの導入を考えております。今回の更改でも検討はしたのですが、ほかに優先させることが多かったので見送りとなりました。一部の機能で導入し始めていますが、いずれ大胆にアプリケーションを改修して導入したいと考えております。 おわりに GMOペイメントゲートウェイではエンジニアを絶賛採用中です。今日ご紹介したシステムも含め、当社にて構築運用をしている様々なサービスをより発展させていくために、様々なバックボーンをお持ちのエンジニアの皆様のお力をお貸しいただければ幸いです。本日のイベントを聞いて興味が沸いた方はぜひ採用特設サイト（https://www.gmo-pg.com/corp/recruit/）をご覧ください。 Q&A 質問1．Hazelcastの運用で困ったことはありますか？ 主催機能性能は非常に良く、要件に合致してらっしゃると思うのですが、困ったこと、困っていることなどございますか？ 運用して1年程度経ちましたが、今時点で大きく困っているところはないです。ただ、複数台サーバーをクラスタリングしているのですが、間にロードバランサを挟んだりする訳ではなくてクラスタリングされているノードが勝手にクラスタリングをしてくれるというのがHazelcast機能なんですね。なのでいきなり稼働しているもののプロセスを落としてアプリケーションの切り替え等をやるので、その辺が結構、ドキドキするというか、メンバー含めて大丈夫か毎回確認するようなところが、通常のアプリとはちょっと違うなという風に感じています。羽鳥 主催ロードバランサ毎にサーバーを立ててというのではなくて、各ノードのうちどれかがプライマリとして起動して、っていう形になりますのでそうですね。確かに知らないとちょっとドキドキするっていうのはあるかもしれませんね。 質問2．Hazelcastをputする度にネットワークI/Oのブロッキングは発生するのでしょうか？測定などされていましたか？ ブロッキングは発生しているかと思います。実際ネットワークテストの中で、ノードを全部落として実行すると接続できなくて、その間ずっとリトライするのでブロッキングされるはずです。ただ非同期で書くこともできたかと思います。羽鳥 主催そこは作り方次第ではあるけれども、製品としては担保しているということですね。 そうですね。羽鳥 質問3．RDBとHazelcast両方に登録するとデュアルライトが発生すると思いますが、それはどうやって解消されたのですか？ 2つ書き込んでデータが重複して不具合が発生するかということですかね。Hazelcast側でデータベースを参照しながら、移行期間中は業務処理的に不具合が起きないよう工夫をしながら解消していました。Hazelcastからデータベースに接続する所は独自に作らなければいけなかったので、そこはちょっと頭をひねった部分だと思います。羽鳥 主催いわゆるデータグリッドのようなHazelcastの製品だと、キャッシュに書いてからライトスルー同期型でデータベースに書き込みしたりだとか、ライトビハインドで非同期するようなことがあるかと思うのですが、今回の場合はライトビハインドではなくライトスルーという形になったんですね。 はい、そうですね。羽鳥 質問4．Hazelcastを使っているならPayara Micro使うのがいいのでしょうか？ 主催フレームワークを採用する上で、何か意図してHazelcastだからこのフレームワークなのか、そうではなくて今までこれを使っていたから、単純にHazelcastを使うようにしたというのか、両パターンあるのかなと思うんですけど、御社の場合は去年お話ししていたSpringとか、プラスJDKでガリガリ作ってらっしゃった話を聞いたことがあるんですけども、何か指針がありましたら教えてください。 指針というより経緯という感じになってしまうのですが、以前プロジェクトでPayara Microを使用した経験があって、その中で若干Hazelcastを使ったことがあったというところから、採用しました。今回の更改では、特にフレームワークを導入することはなくてPayara Microを使っていないのですが、知識が若干あったことと、且つユースケースも嵌まるということが分かったので使うことになりました。羽鳥 主催select for updateのお話ですね。NOWAITとかSKIP LOKEDとか併用で制限付きリトライを実装する、もしくは例えばロックタイムアウトをある程度制限しておかないとコネクションを埋めつくすよねっていうとこでしみじみコメントされている方もいらっしゃいますね。 本当に仰る通りですね。今回ご紹介していない機能で、select for updateが原因でロック待ちが発生してしまっていたケースがあって、こちらも改修する際にかなり悩まされた部分ではあります。羽鳥 主催あとはデータベースのロックが悪というって言い方はちょっと表現が強いかなっていう感じはするんですけど、どうしてもロックしてしまうよね。っていうところで、今回はインメモリデータグリッドの製品であるHazelcastをお使いになったのかなと思ってはいるんですけれども。 質問5．お話いただいた以外でハマったところなどあれば教えてください。 主催今回お話頂いた以外で、この辺はハマりどころだから、ちょっと気をつけてくださいというようなガイドというかチップスみたいなのをオーディエンスにお伝えいただければなと思います。 よく覚えているのが、Hazelcastの設定ファイルはhazelcast.xmlで定義するのですが、公式のドキュメントを見ていてYAMLでもかけると思ったのでせっかくなのでYAMLでやったら、一部の機能でYAMLではダメですとなって結局xmlに戻したという経緯があります。なのでやるならhazelcast.xmlでやった方が無難です、というところですかね。あとは日本語のドキュメントがなかったので、公式の英語のドキュメントを見る必要があって、そこがちょっと大変でしたね。一方で、公式ドキュメントは結構充実しているので、ちゃんと読めば理解が深まるようになっているとは思います。羽鳥 主催マニュアルを読むうえで英語がメインのドキュメントになってしまっていたので、ややハードルがあったという感じですね。ありがとうございます。 質問6．プロジェクトはどれぐらいの期間かかったのですか？ 期間的には約1年半ぐらいですかね。羽鳥 主催GMOさんは既に色々プラットフォームをお持ちだったりするので調達はそれほど難しくはないかと思うのですが、実際に要求開発及び設計で恐らくテストの期間が1年半という感じですかね。 そうですね。羽鳥 質問7．開発は何人ぐらいでされていましたか？ 主催決済システムはお金が関わるシステムなので、非常にヒヤヒヤドキドキするのであるとかっていう開発も結構ヒヤヒヤものだと思うんですけれども、結構プレッシャーが高いかと思います。何人くらいで開発されていたのでしょうか？ 大体、10人ぐらいですかね。羽鳥 主催じゃあ、アーキテクトがいてあとはプロジェクトオーナーとかちょっと置いておいたとしても、実際に手を動かす人々がそれぞれという感じですかね。 はい、そうですね。羽鳥 質問8．テスト中にHazelcastの特性上困ったことなどありましたか？ 主催素朴な質問なのですが、データベース直だとロックとかそういうパフォーマンス的な部分ばかりで、あとはHazelcastをお使いになったことであるっていうことなので、ある程度特性をご存じで、テストの時にHazelcastの特性や知らなかった部分が理由でうまくいかないとか、そういうことってあったのですか。 テストの中で想定してないっていうのは、あまり記憶にないですかね。逆にいうと、そこまで複雑な機能を使わずシンプルな使い方をしていたので、テスト中にはまったというのはなかったですね。羽鳥 主催開発時に何かちょっと思っていたのと違ったとか、設計に入る段階で既に基礎調査みたいなことはされていたと思うので、そこで解決していたのでしょうか。 基礎調査で結構時間をとって、簡単なプログラムを作って動作確認するというのはかなりやったので、実際テストのタイミングでは想定外というのは起きなかったのかなと思います。逆に言うと、そのタイミングで思ったよりパフォーマンスが出ないとか、IAtomicLongいわゆるカウンターみたいなものがHazelcastの中にはあるんですが、これを複数のスレッドで同時にカウントアップとカウントダウンを行った場合に処理性能的にRDBを使った場合と、どの程度違うのかっていうのをやってみたら、あんまり速くなかったことがありました。羽鳥 主催ロック競合というか取り合いになるからということですかね。 はい、そうですね。羽鳥 質問9．開発の効率化にあたってフレームワークの導入を進めているとのことですが、どんなものが候補に上がっていますか？ Spring Boot、Vert.xやQuarkusが候補にあがっています。羽鳥 主催開発者も多いっていうのがありますよねSpring Bootは。 はい、弊社内でも経験者が多いので、Spring Bootは進めやすいです。羽鳥 質問10．新システムと旧システムを並行稼動中に新システムが問題なく稼動してるのを確認する方法として、エラーが出てないこと以外に、データ整合性など見てらっしゃったポイントなどありますか？ 色々見ていたような記憶があるのですが、やはりそのデータベースとHazelcastを使った中でのそのデータの整合性もちゃんと行っているかというところの確認ですね。特にその意図してない取り消しが発生してないか。発生するとその加盟店的様との決済の不整合が起きてしまうので、そういったところはかなり注力して見ていたところです。あとはエラーだとか、ワーニングといったところのログは全て拾って、何かしら異常が出ていないかっていうところはかなり注意して見ていたかなと。とにかくログの種類というか条件を絞らずに、抽出すべきログを全部見るみたいな、形でやっていたところはあります。あとは新旧処理の遅延、処理が遅くなってないかというようなところも、かなりモニタリングしました。羽鳥 質問11．最後に何かメッセージはありますか？ はい。弊社の新しいメンバーを募集していまして、特に決済に携わってきたキャリアをお持ちの方でぜひご興味を持っていただければと思っております。カード決済の仕事で培った知識といったものが結構限られた業界というか、専門的なものなので、そういったものを弊社で非常に取り扱うので、決済の知識を持った方に是非ご興味持っていただければと考えております、よろしくお願い致します。採用特設サイト（https://www.gmo-pg.com/corp/recruit/） 羽鳥 主催羽鳥さん、どうもありがとうございました。 ありがとうございました。羽鳥 アーカイブ動画 ご視聴・ご参加いただき、誠にありがとうございました。たくさんのご質問もいただき、重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://youtu.be/SGy0UDwZpB4

こんにちは、GMOインターネットグループ株式会社の斉藤です。この記事はConoHa Advent Calendar 2022の13日目の記事です12日目は@narikakunさんのConoHa VPSを使ってツイキャスの配信が始まったら通知するプログラムを動かすでした。 VPSのセットアップ 今回は基本に立ち返って(?)、VPSの初期設定のお話しです。 ちょっとしたプログラムのテストや何か新しいソフトウェアを動かしてみたりするときに、ConoHa VPSはとても便利です。仮想サーバーがすぐに立ち上がりますし、1時間単位で課金されるのでコストも最小限になります。 私も日頃から何かのテストや動作検証などなどで、とっても便利に利用しています。最近はコンテナを使うことが増えていますが、それでもOSやその下のネットワーキングなど低いレイヤーをテストする場合は仮想サーバーが便利なこともまだまだ多くあります。 新しくサーバーを立てると、もちろんそのサーバーはすっぴん状態です。自分が普段日常的に使うツールなどは入っていませんし、シェルの設定なども初期状態です。これは使いにくい！　検証目的とは言え自分好みのサーバーの環境を使いたいものです。 ConoHaであればVPSを「イメージ保存」で保存して、次回からそのイメージからサーバーを立ち上げることができます。なので初期セットアップを済ませた状態のVPSをイメージ保存すると言う方法が一つ賢い使い方です。 一方で自分好みのサーバーの初期設定をスクリプトなどにしておくととても便利です。イメージ保存を使うと保存した時点でのソフトウェアで固定されますが、スクリプトにしておくと毎回セットアップ時に最新のバージョンのソフトウェアとを使うことができます。 それにOSのメジャーバージョンアップなどがあった場合でも、スクリプトの大部分を使い回せることが多いですしね。 と言うわけで、私が普段Ubuntuで使っている初期セットアップスクリプトをご紹介したいと思います。ConoHaは以前からサーバーの勉強をしている方の利用が多いですし、コメントで解説を入れてありますので参考にしてみてください。 スクリプト 以下のようなスクリプトをgistに保存しています。一部、対話的なコマンド(update-alternativesやvisudo)があるのでスクリプトを流して終わりというわけには行きません。ただ数回のコピー/ペーストで終わるのでこれで十分だと思っています。 もちろんこれは最小限なので、用途に応じて追加でいろいろインストールしたり設定を変えたりと言うことを行います。 # apt関連 # インストールしているソフトウェアのコメントを付けておきます # # fish: fishシェルを常用しているので必須です # vim-nox: -noxを付けるとX Window System関連の依存が入らなくなるので便利です # findutils: 古いですがfindとかxargsとかまだ使うので # lv: lvはlessよりタイプ数が少ないのが良いです # install-info: infoもたまに見ます # aptitude: 極まれにaptでインストールできないものを入れるのに使います # dnsutils: dig用 # jq: 良い代替ツールないですかね # mosh: ターミナルマルチプレクサはサーバー屋さん必須ツールです # build-essential: ビルドに必須 # automake: ビルドに必須 # grc: いろいろなコマンドの出力に色づけしてくれます https://github.com/garabik/grc # apt update && apt -y install \ fish \ vim-nox \ git \ gh \ findutils \ language-pack-ja \ wget \ curl \ tmux \ lv \ install-info \ aptitude \ dnsutils \ jq \ mosh \ build-essential \ automake \ zip \ grc # タイムゾーンを日本に sudo timedatectl set-timezone Asia/Tokyo # Ubuntuはデフォルトでnanoを使うのでvim-basicに変更 update-alternatives --config editor # Docker(CE)のインストール # オフィシャルリポジトリからインストールすると最新版が使えます sudo apt-get install -y \ apt-transport-https \ ca-certificates \ curl \ gnupg \ lsb-release sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io # ローカルユーザーを作成します。私は"hiro"をずっと使っています。 # UIDを固定していますがこれは昔からの名残で今は必要ないでしょう useradd -u 5010 -s /usr/bin/fish -m -d /home/hiro hiro # dockerとsudoグループに追加 usermod -a -G docker,sudo hiro # sudoの設定を変更します。 visudo # ローカルユーザーの設定を行います su -l hiro -c /bin/bash # 設定ファイルはgitにしておくとcloneするだけなので楽です git clone https://github.com/hironobu-s/dotfiles ~/dotfiles ln -s ~/dotfiles/fish ~/.config # sshの設定 mkdir -m 0700 ~/.ssh # 公開鍵はgithubから取ると便利です curl https://github.com/hironobu-s.keys > ~/.ssh/authorized_keys chmod 0600 ~/.ssh/authorized_keys # ローカルユーザーで使う実行ファイルはここに格納します mkdir -p ~/local/bin 終わりに 今年も無事ConoHa Advent Calendarに参加できました。個人的にはこれを書くと年末という感じがしますね。去年は「diskspdでいろいろなVPSのストレージベンチマークを取ってみる」という記事でした。お時間のある方は読んでみてください。 それでは皆様、どうぞよいお年をお迎えください。

GMOインターネットグループの稲守です。当社の大規模技術カンファレンスであるGMO Developers Day 2022を12月6日〜7日の２日間で開催いたしました。本エントリーでは各セッションや会場の雰囲気などを写真も撮って出しで速報をお送りします。 開催概要 GMOインターネットグループにはインターネットインフラ事業をはじめとして広告・メディア・金融・暗号資産と様々な事業会社・開発組織があります。これからの各開発チームから登壇者が集まり、登壇グループ企業数は20社、登壇者はゲストスピーカーを併せ80名ほど。2トラックで全34セッションで実施しました。 公式WEBサイト：https://developers.gmo.jp/developersday/ キーノートセッション グループ専務執行役員の堀内からオープニングのエンドースメント。こちらでは技術責任者会議の設立経緯や来週から実行するエキスパート制度について発表が行われ、DevDay2日間の見どころをお届けしました。 CTOセッション〜技術責任者会議〜 技術力を強化し、グループシナジーの最大化を図るため2022年より各社のCTOが集まり、開発者の最高意思決定機関として技術責任者会議が組成されました。本セッションではこの技術責任者会議のボードメンバーであるCTOたちが、GMOインターネットグループの開発体制における現状から、これからの展望について議論を交わしました。 世界で戦うWeb3起業家たち キーノートセッション2つ目はWeb3をテーマにAstar Network渡辺創太さん、昨年に続き藤本真衣さん、そして弊社ステーブルコインのGYEN担当の中村の３名で集まりました。こちらではグローバルチームを牽引する上での苦労やナレッジをはじめ、世界の視点から日本が抱える課題やこれからの展望など、GMO Web3社プロジェクトの話も交え、スイス、シンガポール、米国を繋いで配信いたしました。 渡辺 創太氏（Astar Network ファウンダー）藤本 真衣氏（BlockchainPROseed Co-founder）中村 健太郎（GMO-Z.com Trust Company, Inc. CEO） ブロックチェーン技術のビジネス実装で広がる未来 本セッションでは当社のブロックチェーン分野で活躍するエンジニア２名と分散技術の権威である京都大学の首藤教授をモデレーターにお招きし、ブロックチェーンをビジネス実装し、社会に提供する際の課題や意義などを広く議論いただきました。 （左から） 首藤一幸氏（京都大学学術情報メディアセンター 教授）佐藤 史彦（GMOインターネットグループ株式会社　次世代システム研究室 室長）黒瀧 悠太（GMOペパボ株式会社　SUZURI事業部 シニアエンジニアリングリード） 越境のデザイン――ソフトウェアからのアプローチ Day1のトリを飾るのは弊社の成瀬です。「越境のデザイン」と題し、マイクロサービス化をすすめる上での様々な困難、課題についてどのようにアプローチするのかトークしてくれました。 成瀬 允宣（GMOインターネットグループ株式会社　テックリード／デベロッパーエバンジェリスト） 上下関係がない「ホラクラシー組織」におけるアプリ開発体制とは GMOタウンWiFiでは、個人と組織が自律的に進化し続ける「ティール組織」を実現するためのフレームワークである「ホラクラシー」を導入しています。スクラム手法を交えながら開発を進めているのか事例を交えながら発表が行われました。 松野 峻也（GMOタウンWiFi株式会社　取締役 CPO） その他セッションの様子 データサイエンティスト対談 ～GMOだからできるデータサイエンスとは～佐野、財津、春田、石地 クラウドネイティブセッション長谷川、山下、佐藤、山崎 入社2年でリーダーも！次の未来を担う、若手エンジニアたち石丸、松窪、土井、鬼塚 各セッションはアーカイブ視聴いただけます。公式WEBサイトからログインしご視聴ください。 公式WEBサイト：https://developers.gmo.jp/developersday/（アーカイブ視聴：12/15（木）10:00まで） 会場の様子 会場ではいわゆる企業ブースの他、ConoHaのグッズ販売、ペパボブースではペパボ社の新デザインフレームワークを用いた新デザインブーストなっていました。率直にかっこいいです。今後開催される各イベントでこちらのブースもチェックしてみてください。 会場ではDEV HUNTERSの抽選会を行っていました。この企画はDevDayのセッションや会場などに隠されているキーワードトークンを集めて抽選に参加できる企画です。順位発表などはこちらで行われました。皆さんご参加ありがとうございました。本企画のシステムはNoCodeで開発されたものです。セッション終わりなど負荷が多い瞬間への対応などが課題となりました。このあたりは別途機会を設けて共有できればと思います。 会場では写真のトートバッグをお渡ししていました。オリジナルのPCカメラカバーを封入していました。ぜひご利用ください。 また会場となったGMO Yoursのカフェも皆さんにご利用いただきました。普段、私たちが触れている部分を少しでも感じ取ってもらえたら幸いです。 さいごに 非常に多くの方にご参加いただき、運営事務局を代表して改めて感謝いたします。運営チームでは必ず振り返りのKPTを実施しています。今回もKよりPが多くなりそうですが、皆さんと一緒により良い情報発信とするべく改善を進めてまいります。開催速報としては以上になります。今後もGMOインターネットグループをどうぞよろしくお願いいたします。

　Microsoft365からメール送信を行う場合はOutlookを利用して、Power AutomateやPowerAppsから送信が可能です。ただし、あくまでも個人のアカウントからのメール送信となるとめ、お客様への案内メールなど送信する場合は別途専用アカウント用意する必要などがあります。今回は外部のSMTPリレーサービスとPower Automateを組み合わせてお客様への案内メールを送信する方法を紹介します。 ゴールイメージ 　今回のゴールとして、”[email protected]”という送信者アドレスからお客様へ案内メールを送信できること。加えて、“[email protected]”宛てに送られたメールを、MIcrosft365の個人アカウント“[email protected]”で受信するまでを目指します。 ※正確にはメールの受信はSMTPでメールサーバーに送られてきたものをPOP3やIMAP、MAPIで受信します。 SendGrid 　インターネットサービスの中にはお客様向けの案内メールなどを送信するためのサービスが数多く提供されています。その中で、今回利用するサービスは「SendGrid（https://sendgrid.kke.co.jp/）」を選択しました。こちらのサービスは検証用に個人で利用する程度であれば無料で利用可能なメール配信サービスです。こちらのサービスを利用できるようにセットアップを行います。まずはTopページの「無料ではじめる」から新期会員登録を行います。 差出人情報の登録 　アカウントが発行されたら、差出人情報の登録を行います。サインイン後、ダッシュボードの左メニューから「Marketing」-「Sendars」-「Create Sender」を選択します。 From Nameメール送信者として表示される名前From Email Address送信者メールアドレスReply To返信先メールアドレスCompany Address会社（個人）住所Nickname差出人情報を管理するための名前 こちらの情報を登録します。 登録したメールアドレス宛に確認メールが届きますので承認します。 「VERIFIED」にチェックマークが付けば差出人情報の登録は完了です。 APIキーの取得 　SendGridのサービスを利用するためのAPIキーを取得します。ダッシュボードの左メニューから「Settings」-「Create API Key」を選択します。キーの名前を入力して、「Full Access」を選択して「Create ＆ View」を選択します。 発行されたキーを保存しておきます。 メール送信テスト 　ここまでの設定で、SendGridのSMTPサービスが利用できるか、メールを送信して確認します。PowerShellからAPIキーを設定してメール送信を行ってみましょう。 $Smtp = "smtp.sendgrid.net" $Port = 2525 $Encode = [System.Text.Encoding]::UTF8 $Account = "apikey" $Password = "<取得したAPIキー>" | ConvertTo-SecureString -AsPlainText -Force $Credential = New-Object System.Management.Automation.PSCredential $ Account,$ Password $FromAddress = "[email protected]" $ToAddress = " [email protected]" $Subject = "SGTestMail" $Body = @" メールテストです。 "@ Send-MailMessage ` -To $ToAddress ` -From $FromAddress ` -SmtpServer $Smtp ` -Credential $Credential ` -UseSsl ` -Encoding $Encode ` -Port $Port ` -Subject $Subject ` -Body $Body 自分から自分宛てに送信したメールですが、無事届いています。最初の設定としてはOKです。 Power Automateでクラウドフローの作成 　SendGridにはメールが届いたタイミングで任意のWebhookを利用する機能が提供されています。これを利用して、お客様から返信されたメールの宛先アドレスを実際に受信できるメールアドレスに変換する仕組みをPower Automateのクラウドフローで実装します。具体的には、お客さまからの返信メールの受信者アドレス [email protected] を [email protected] に変換した後、メールをSendGridのAPIを利用して送信します。この機能をSendGridからWebhookで呼び出すことになります。フロー全体は以下となります。 フロー内のいくつかポイントを解説しておきます。 呼び出されるWebhookのUrlを提供する「HTTP要求の受信時」トリガーはプレミアムコネクタとなります。件名、本文、送信者、受信者はそれぞれ変数を作成して格納しています。取得するパラメーターはSendGridの解説ページ「Setting Up The Inbound Parse Webhook（https://docs.sendgrid.com/for-developers/parsing-email/setting-up-the-inbound-parse-webhook）」内の「Default Parameters」を参考に、それぞれ「triggerFormDataValue」関数を使って以下のように取得しています。 Subject triggerFormDataValue('subject')BodytriggerFormDataValue('text')FromtriggerFormDataValue('from')TotriggerFormDataValue('to') 「HTTP」アクションでは、SendGridのWebAPIを利用してメール送信を行います。「トランザクションメールを送信する」を参考に、URI,、jsonデータを設定します。jsonデータには宛先として”[email protected]”を指定しています。authorizationには、“Bearer <取得したAPIキー>”という書式で指定します。 以上で、クラウドフローが完成したので、「HTTP要求の受信時」トリガーに表示されている「HTTP POST の URL」の値を取得しておきます。こちらがWebhookの呼び出しUrlとなります。 MXレコードの登録 SendGridでお客様の返信メールを受け取るには、返信アドレスとなる ”[email protected]" のドメイン”sg..win1.wok”のMXレコードを”mx.sendgrid.net”としてDNSに登録する必要があります。お名前.comを例にするとこのようになります。この設定によって、”[email protected]” のメールがSendGridのサーバーに送られることになります。 ドメインの登録 　SendGridで“sg.win1.work”このドメインのメールを受信できるようにドメインの登録を行います。ダッシュボードの左メニューから「Settings」-「Sender Authentication」-「Get Started」を選択します。 お名前.com利用の場合は、「DNShost」は“Other Host(Not Listed)”、「Wichi DNS Host」はお名前.comのDNSサーバーのホスト名“01.dnsv.jp”を入力します。 認証するドメインには“win1.work”を入力します。 画面上にCNAMEの一覧が表示されますので、こちらすべてをDNSサーバーに登録します。 お名前.comを例にするとこのようになります。 DNSの登録が完了したら、「Verfy」ボタンを選択します。この画面が表示されればドメインの登録完了となります。 Inbound Parse Webhookの設定 　SendGridでメールが届いたタイミングで任意のWebhookを利用するために「Inbound Parse Webhook」の設定を行います。ダッシュボードの左メニューから「Settings」-「Inbound Parse」-「Add Host & URL」を選択します。 テスト実行 　全ての設定が完了したとこをで、今回の目的となる動作を一通り実行してみましょう。まずはお客様へ案内メールを送信します。送信元"[email protected]"からお客様アドレスの" [email protected]"へSendGrid経由でメールを送信します。 $Smtp = "smtp.sendgrid.net" $Port = 2525 $Encode = [System.Text.Encoding]::UTF8 $Account = "apikey" $Password = "<取得したAPIキー>" | ConvertTo-SecureString -AsPlainText -Force $Credential = New-Object System.Management.Automation.PSCredential $ Account,$ Password $FromAddress = "[email protected]" $ToAddress = "[email protected]” $Subject = "お客様へのご案内" $Body = @" お客様へのご案内メールのテスト送信です。 よろしくお願いいたします。 "@ Send-MailMessage ` -To $ToAddress ` -From $FromAddress ` -SmtpServer $Smtp ` -Credential $Credential ` -UseSsl ` -Encoding $Encode ` -Port $Port ` -Subject $Subject ` -Body $Body お客様にメールが配信されました。このメールに返信します。返信先は"[email protected]"です。 SendGridからPower Automateのクラウドフローが呼び出され、"[email protected]"へメールが転送され受信ができました。 　以上、Power Automateと SendGridの機能を組み合わせたメール転送サービスの構築方法となります。WebhookやWeb APIをフル活用することで、単体では機能不足なサービスも、色々と組み合わせて機能補強が図れるようになります。今回は最初のメール送信部分をPowerShellのコードで記載していますが、こちらもローコード開発が当然可能です。プラグラムを一行も書かずにメール転送サービスが構築可能ということです。Microsoft365やSendGrid以外にも数えきれないくらいのWebサービスが提供されていますので、組み合わせ次第では最強のシステムの開発ができそうです。

本イベントは、世界トップクラスのサイバーセキュリティ専門家による国際会議として、10月27～28日の2日間、東京・渋谷パルコDGビル 18階 カンファレンスホール “Dragon Gate”にて開催されました。欧米の著名研究者が参加して研究成果を共有するとともに、日本の若手研究者の研究も発信する場としても知られています。GMOインターネットグループからは、GMOサイバーセキュリティ byイエラエ社がトップスポンサーとして協賛し、セッションやワークショップへの出展などで参加しました。CODE BLUE 2022 協賛レポート［前編］記事に引き続いて、今回は［後編］として、ワークショップ・ブースの様子をお届けします。 CODE BLUE 2022 協賛レポート［前編］ https://developers.gmo.jp/26813/ ワークショップ ワークショップ会場では「Webハッキング体験 forビギナーズ」と題したコンテストを実施していました。これは、Webサイトに仕込まれた脆弱性を使ってシステムへの侵入にチャレンジするという企画。貸し出された、または自前のPCを使って参加するというもので、全問正解者先着10名には、イエラエ社のエンジニアが執筆した書籍がプレゼントされていました。 Webハッキング体験 forビギナーズを実施していたワークショップのイエラエ社ブース ブースの担当者が「大盛況」と言うとおり、いつブースを覗いても参加者がいるという状況でした。実は、すでにGMOインターネットグループ内で行ったHacking Nightで使われた問題と同じものが使われていたそうですが、取材時で満点の人が5人ほど。「腕に覚えのある方だとすぐに（満点を）取っていく」という説明でしたが、人によっては2時間ぐらいかけて頑張って解いている、という感じだったそうです。 いつ見ても貸出PCは埋まっていました ビギナーズと題していますが、オフィスのパソコンを管理している情報システム部門と、Webの開発はしているけれどもセキュリティには手を出したことがないという人をターゲットにしていたそうです。ハッキングでどんなことが行われているかピンと来ないような人が、実際に攻撃してみて、どう守るかを理解してもらうことが目的だと言います。 トップ10の結果。横軸が回答時間、縦軸が点数。一定まではすぐに解ける人も、後半のセクションで時間がかかった例が多いようです。トップの人は短時間でクリアしており、腕に覚えがある人だったと見受けられます 内容的には、全部で3セクション12問が用意されており、1セクション目にある9問は簡単ですが、体系的に学びを得られる内容で、続く2、3セクションで学んだことをそのまま使ってみる、という構成になっています。 ただし、2セクション目以降は、そのまま学んだことを使うだけでは解けずに、一工夫が必要な仕組みになっています。実際、1～9問目まではすぐに解けていた挑戦者も、それ以降の回答に時間がかかった例もあって、教材としても優れた作りになっていることが伺えました。 グループ内では過去に使われたこのハッキング体験ですが、今回のCODE BLUE会場でも大好評！ブース担当者は、具体的な話があるわけではないと前置きしつつ、外部にも何らかの提供があってもいいのかもしれないと話していました。 景品として用意されていたイエラエ社のエンジニアが執筆した書籍 企業ブース 企業ブースでは、イエラエ社の製品を紹介していました。製品はアタックサーフェース可視化サービス「metisys」と、デジタルフォレンジックの「レッドチーム演習」です。 企業ブースで紹介されていたmetisys metisysは、攻撃の入口となるドメインやIPアドレス、企業の漏えい情報を具体的、包括的に可視化してくれるサービスです。IPアドレスを登録すると定期的にスキャンして、問題点が上がると赤く表示されます。ドメインも同様にチェックできます。 社内の資産を列挙し、IPアドレスやドメイン情報をスキャンして、脆弱性があれば指摘してくれます スキャンした結果、脆弱性情報があれば赤色で警告を表示 漏えい情報では、メールアドレスとその流出元が表示されます。こうした情報は、特に大きな会社だと、工場や支社、支店なども含めると管理しきれなくなり、サプライチェーン全体で管理したいというニーズに対応するための製品だと言います。 実は、現時点ではインターネットクローリングをかけているだけですが、来年に向けてアクティブなスキャンをするエンジンも開発しているそうで、それが実装されれば、深いところまでチェックできる製品になると説明していました。 紹介されていたもう1つの製品である「レッドチーム演習」。目標となるゴールに対して実際の攻撃者と同じ条件で攻撃を実施して、組織全体のサイバー攻撃に対する体制の評価などを実施します。 レッドチーム演習、デジタルフォレンジックに関する紹介も ブース担当者の説明では、従来はアンケートや脆弱性診断などを実施していたのですが、調べることが広範になってしまうそうです。レッドチーム演習の有用性が高いのは、一番攻撃されやすいところが判明することです。 「サイバーセキュリティキルチェーンと言われるが、攻撃はたいてい1つの入口から連鎖している」とのこと。その入口さえふさげば攻撃は連鎖しないわけで、それを可視化するのが今回のサービスで、クオリティの高いエンジニアがホワイトハッカーとして攻撃を実施します。 このレッドチーム演習に対して、ブルーチームによるフォレンジックや支援サービスも提供。ハッカーに侵入されたときにどこに侵入されて、どういう感染経路で、どういう攻撃手法だったのか、といったことを調査。PC、サーバー、カーナビ、IoT、クラウド環境といった幅広い調査ができることが特徴だと言います。 「演習」というのがポイントで、従来の手法だとリアリティがないと担当者。経済産業省がサイバーセキュリティ経営ガイドラインでもインシデント発生に備えて演習をするよう求めるなど、演習に対するニーズが高まっている点も追い風のようです。 「レッドチーム演習」サービスについて、詳しくはこちらから さいごに CODE BLUEは、歴史あるセキュリティイベントとして多くの来場者が集まっており、「Web3セキュリティ解体新書」講演にもたくさんの聴講者がいて、やはりWeb3の注目度の高さを感じさせました。 そうした中でもワークショップにおけるハッキングコンテストの人気も、もともと来場者のセキュリティ意識は高いのでしょうが、様々なキャリアの人がトライしていた様子だったのも注目ポイントです。 セキュリティ対策においては技術力の強化だけでなく、日々の情報収集能力も重要で、レッドチーム演習の担当者も、イエラエ社の強みとして最新情報の情報収集力を挙げていました。CODE BLUEのようなイベントは、最新情報を得られる格好の場であり、イエラエ社も最新の情報を提供し、さらに攻撃と防御に対する認知度を高めるという貢献を担っていたのではないでしょうか。