技術情報 の記事一覧

2022年6月21日（火）～23日（木）に日本国内最大のドローン・eVTOL（空飛ぶクルマ）展示会「Japan Drone 2022」が幕張メッセにて開催されました。GMOインターネットグループはプラチナスポンサーとして協賛し、最大規模で出展しました！今回は、国際コンファレンス「攻撃者はどこを狙うのか？ドローン・eVTOLに求められるセキュリティ対策～GMOインターネットグループが目指す「安全な空の移動」～」と題し、ドローン・eVTOL産業に携わる3人の専門家パネリストが「空の移動」におけるセキュリティや業界動向、GMOインターネットグループの目指すビジョンについて語りました。イベント告知：https://developers.gmo.jp/18770/本記事はこちらのイベントの書き起こしとなりますので、ぜひご覧ください。 登壇者（敬称略） DRONE FUND 創業者/代表パートナー千葉道場ファンド 創業者・ジェネラルパートナー/慶應義塾大学SFC 特別招聘教授千葉功太郎GMOグローバルサイン・ホールディングス株式会社 CTO室 室長浅野昌和GMOサイバーセキュリティ byイエラエ株式会社 執行役員 高度解析部部長寺村亮一 国際コンファレンス 「攻撃者はどこを狙うのか？ドローン・eVTOLに求められるセキュリティ対策～GMOインターネットグループが目指す「安全な空の移動」～」 ドローン、 eVTOLの将来像と現在の状況 空の移動において留意すべきセキュリティリスクと、安全を守るために必要な対策について、有識者の皆様からお話をお伺いします。未来のドローンがどうあるべきかを模索していきたいと思います。ドローンが一般的にも認知され、小型のものなどはもう個人でも比較的簡単に扱えるようになってきました。千葉さんはドローンに関するファンドも創業されているとお伺いしていますが、今後どのようにドローンや空飛ぶクルマと関わっていかれるのか、まず詳しくお伺いできればと思います。 千葉まず自己紹介からですが、わたしはドローン大好き人間です。DRONE FUNDというドローンの投資ファンドは、今日もたくさん出展していますが、ドローンに夢を賭けている会社に株式出資をして、取締役としてわたしも入るとか、経営のご支援をしながらドローンの未来を作っていくということを主にやっています。ほかにも、日本のスタートアップに投資、支援する仕事をしていて、現在約140社、個人も含めて日本中、世界中の会社を支援しています。わたしはパイロットをやっています。ホンダジェットの国内1号機をオーナーとして所有していて、せっかく飛行機を所有したのならばパイロットになろうと思い、苛酷な訓練を2年半やりまして、昨年パイロットライセンスを取得。現在副機長として、今週の金曜日にも乗務予定です。皆さんに今日お伝えしたいのは、この会場にはドローンの未来に期待をしている皆さんが集まっていただいているのですが、最終的には人間が空を飛びます。空を飛ぶということに対して一番知見が多いのは航空機産業だと思っています。航空機産業でパイロットが一番安全に対してすごく意識を持っていて、皆さんが気軽に乗っている飛行機は、日々1秒1秒がパイロットをはじめ業界全体の人たちによって守られています。これを学んで皆さんの業界に伝承し、ノウハウを引き継いでドローンやエアモビリティが安全に飛ぶ社会を作っていきたいというのが、わたしが取り組んできていることです。我々の活動は世界で唯一のドローン・エアモビリティ専業の投資ファンドです。我々のテーマは、ドローン・エアモビリティ前提社会を作るということでして、小さい頃に見たアニメとか映画の世界が21世紀になっても全然実現しないわけです。それに僕は21世紀になった瞬間に絶望して、このままでは自分が生きている間に人間は空を飛べないと思って、人間が空を飛ぶ社会を作りたいと思ったのが自分の根幹です。実は5年前に、「2023年、六本木ヒルズ屋上から見たドローン前提社会はこうなる」という絵を描きました。来年ですね。皆さんというところのレベル4です。東京都心部の上空でも自律飛行型のドローンが飛ぶ社会というのが来るだろうというのを、5年前に絵を描いて、こういう世界を作っていこうということをやっていますし、あるいは「2025年、墨田区のビルの屋上で離発着するドローンタクシー」という絵、これも今、大阪・関西万博に向けて政府が2025年にドローンタクシーの商業運用を発表しています。こういったことを5年前に絵を描いて、未来予測を立てて、みんなを巻き込んで、こういう未来を作っていくんだ、日本から発信するんだというようなことをやっています。最終的には、皆さんの生活の中に普通にドローンが入り込んでくる。例えば小学生の忘れ物を届けてくれるお母さんの代わりにドローンが届けてくれるとか、犬のお散歩をしてくれるとか、歩く女性の日傘の代わりになってくれるとか、こういう日常生活まで来る日が、この絵では2024年と書いたのですが、それぐらいのスピード感でくるといいな、と思っています。我々は夢がたくさんあるなと、よくGMOインターネットグループの熊谷代表がおっしゃっていますが、「空は最後の産業のフロンティアだ」と。我々の社会はインターネットや、航空機産業やクルマ産業などいろいろな産業で大きくなってきましたが、実は空、特に低中空域は誰も開拓していない、ゴールドラッシュの可能性がある場所だと思っております。そこにリモートセンサー、フィールドロボット、モビリティがあるし、特に日本は課題先進国であると考えていて、いろんなことをネガティブにとらえるのではなく、だからこそドローンを代表するロボットが活躍するには日本は最良の国ではないかと、そういうふうに考えております。日本で勝ち抜いたソリューションというのは世界中に輸出することができるのではないかと考えており、それがこのドローン・エアモビリティの社会実装になっていくのだと。ということは、今日のこのセッションもそうですが、いわゆるドローンの本体を作るだけの仕事ではなくて、このドローンが安全に飛行するための様々な見えないところに気を使っていかなくてはいけない。ドローンが落ちたら怖いじゃないですか。例えばここに書いてあるのは、我々の投資しているところで言うと“風を読み取るスキャナー”に投資をしています。3Dスキャナーで風のこの空間の中が一体どういうふうに空気が動いているかというのをリアルタイムにデータ化して、例えば東京のビル群の中をどう具体的にどういう向きでどういう風が動いているかというのもスキャンするような仕組みです。こういう仕組みがないと、東京のビルとビルの間を自動飛行のドローンやエアモビリティが安全に運航することは不可能です。なので、こういう技術もドローンの一部ですし、このあとお話しするセキュリティの技術も当然ハッキングされて盗まれてどこか持っていかれても困るし、墜落させられても困るので、要はやっぱりドローンが安心安全であるというのが、ドローン前提社会では必要なテーマになります。そのために我々のDRONE FUNDファミリーがいま54社いて、ソフトウェアを作っているチーム、ハードウェアを作っているチーム、あるいはまさに周りの安全運航を支える基礎技術を作っているチーム、様々なチームが一緒になってDRONE FUNDファミリー、合宿もよくやっていますけど、みんなで未来を作る活動をしております。 ドローンの技術向上だけでなく社会整備も重要というのが、この回のテーマになったと思います。浅野さんはGMOインターネットグループを代表して「空の移動革命に向けた官民協議会」にも参加されているということなのですが、その点についてお伺いしてもよろしいですか？ 我々GMOインターネットグループは、昨年2021年から「空の移動革命に向けた官民協議会」に参画し、主にeVTOL（空飛ぶクルマ）の検討を行っております。ロードマップを今回2つご用意していますが、こちらがドローンの官民協議会（「小型無人機に係る環境整備に向けた官民協議会」）に出されたものです。今年12月に改正航空法が施行されますが、ロードマップ上で黄色で示されているところ、これによって法的には今千葉さんがおっしゃったドローンのレベル4の飛行が可能になります。レベル4というのは、「人がいる地帯」の上を飛べる、しかも遠隔操縦あるいは自律飛行が可能になるということです。最初は山間部と離島部などで実証実験が始まりますが、ゆくゆくは都市部でもドローンが人のいる上空へ飛んでいくことが実現可能になってくるかと思います。次に、いわゆる空飛ぶクルマ（eVTOL）については、「空の移動革命に向けた官民協議会」において安全性基準の検討や、あるいは「社会受容性」といって、皆さんに受け容れていただく、皆様が安全で便利な乗りものだということを認識いただくための活動をどう行えばよいかという検討をしております。今年からは、空飛ぶクルマが離発着する離発着場（ポート）の検討にも具体的に入っていく予定です。2025年の大阪・関西万博で、遊覧飛行する予定になっておりますので、大阪・関西万博を節目にして、大きく認知が広がっていくと考えています。浅野 まさに3年後ということですけども、千葉さん、空飛ぶクルマの開発はどのくらいまで進捗しているのでしょうか。 千葉ドローンも含めた代表的なメーカー2社ということでご紹介します。1社目はプロドローンです。今日ご紹介する2社とも愛知県のスタートアップとなりますが、まさに日本の地域に根ざしたいろいろな技術がある、日本はクルマで産業が大きく育っておりますので、特に愛知であればトヨタ関連の会社とか技術がたくさんあります。日本各地にいろいろな技術があって、その技術をドローンや空飛ぶクルマにいまコンバートしていくチームがたくさん現れている中の、ドローンチームがプロドローンです。もちろん皆さんがご存知の中型大型のドローンもありますし、サンダーバードドローンというものもありまして、空から飛んでいって海の上に着水して、そこから潜水艦ドローンが出てきてそれが海に潜っていく。それも発表して、実用になっています。あとはヘリコプタータイプのドローン。ドローンはマルチコプターだけではなくて羽が付いた固定翼型のものもあれば、ヘリコプター型もあれば、さっき言ったとおり水中に潜るドローンもあったりとか、あるいは無人の船の型だったりとか、ドローンは非常に広範囲の定義になってきていると思います。こういったメーカーが日本でも生まれていると。2社目が同じく愛知県のSkyDriveです。カーゴドローンと、人が乗るドローンを両方作っておりまして、2025年の大阪・関西万博に実際にお客様を乗せて運航するという日があと3年です。いまこのカーゴドローン、大型ドローン、特に人が乗る空飛ぶクルマは世界の競争が激しい分野です。もともと進んでいるのが中国、そしてアメリカ、ドイツといった国で、うれしいことで日本勢はトップ5にちゃんと残っています。まだまだメダルが狙える位置にある。誰もまだ商業化に来ていないということを考えると、商業化できたチームが金メダルだと考えると、日本勢も金メダルのチャンスはあるのでは、という状況です。 ドローンや eVTOLなどを含むIoTセキュリティの現状 となると、やはりセキュリティの面が気になるのですが、これまで数々のサイバー攻撃に対抗してきた寺村さんから見て、ドローンやeVTOLにどのような脅威が想定されるのでしょうか？ ドローンを飛ばすにあたって国土交通省から認定をもらっていないと飛ばしてはいけないという型式認証の話が出てきています。5年ほど前の自動車と同じ状況かなと思っていますが、型式認証の中のひとつにサイバーセキュリティという項目がちゃんと残っています。まだ最終版ではないですが、型式認証をとるためにドローンに要求されているものとして、「きちんと脅威を分析、特定して、その脅威に対して適切な対策をとっていること」という、脅威に関する文言が、抽象的ではありますが残されています。これは何かというと、自動車の型式認証とほぼ同じなのです。自動車の時は、国際連合の法規で「このような脅威に対抗すること」という項目が決定された上で、日本でも「このようなことをやりなさい」と法律として出ているのですが、おそらくドローンも同じような方向性になると思います。「このような脅威例がある」といった具体的な議論はまだまだですが、今後ドローンをリリースする、型式認証をとる作業を行う上で、きちんとセキュリティの脅威を自分たちで分析し、それに対して自分たちで対策を立てることが必要になってくるのかなと思います。「これをやらないとドローンがリリースできない、市場に出せない」という、自動車と同様な世界がドローンに対しても近付いていると思っています。自動車も同じ道をたどりましたが、実際に脅威分析をやるとなると、どこまでやればいいのかと。自動車もドローンも、最悪の状況は人が死ぬこと。自動車はもともと安全の世界で、制御は絶対大事。曲がる・止まる・走る、この3つを守らなくてはいけない。ドローンや空飛ぶクルマが制御を奪われるということは人命に直結するので、脅威分析をやらないことが絶対に許されない世界になっていくと思います。ただ、これをやっていくと、ビジネスで使われる用途ごとにまったく脅威が変わってきます。例えば、人を乗せるドローンと、物を運ぶドローンと、カメラで撮っているドローンで、最終的に何かしら攻撃された時の影響はまったく変わってきます。だから、それぞれ一つ一つに対してカスタマイズした脅威分析をやっていく。自動車の場合は、自動車会社が体力があるので多額の資金をかけてやっていますが、ドローンについてもどこまで要求されるかは分からないですけど、たぶんその世界が近付いてきています。まず技術面で言うと、攻撃者がドローンに対して「ここは絶対攻撃したい」と思うところはそこまでパターンはないかと思っています。攻撃者としては、一発で大きい影響を与えたいので、リモートからドローンの制御を奪うだけでは全然面白くない。「リモートからドローン制御を奪う、そしてどこかへ飛ばす、落とす」ということを、攻撃者としてはやりたいわけです。もう1つは、ドローン単体の制御を奪うだけではなくて、ドローンを操作しているクラウド側を奪いたい。そのクラウドに繋がっている他のドローンの制御も全部奪えるとか、クラウド経由でドローンを操作しているオペレータールームの制御を全部奪えるとか、大きく制御をとるところを絶対狙いたいと思います。3つ目として、ドローンで重要情報を運んでいる場合にその情報を盗みたいというのもあると思います。寺村 ホワイトハッカーならではのお話で、リスクストーリーをどんどん上げていって、さらに対応策・対抗策をしていくということですね。攻撃を防御するためのIoTセキュリティとして、何か必要なものはありますか？ 本当にいろいろあって、先ほど国土交通省から脅威分析してくださいよという話がありましたが、これがまず脅威モデリングという形で分類されています。大枠としてはそもそもちゃんと脅威について考えましょうというだけですが。今年3月に経済産業省から出されたガイドラインは良いなと思っています。寺村 経済産業省管轄のNEDOさんからドローンのセキュリティガイドライン（「無人航空機分野　サイバーセキュリティガイドライン」）が出ています。浅野 このガイドラインで良いと思っているのが、ドローンの使われ方ごとに「こんな脅威の例がある」という話と、それに対する対策が書いていること。自分のドローンの使われ方を想定した上で、どのような脅威があるのかを自分なりに考えてみて、それに対して「こういうセキュリティを入れているから防げる」もしくは「この使われ方ではこの攻撃方法はたぶん通用しないので対策しなくていい」ということで取捨選択をできると。ドローンを飛ばすのも大事だけど経営を守るのも大事。全部やっているとお金はいくらあっても足りなくなります。セキュリティをやって経営が傾くと意味がないので、そこはバランスをとらないといけなくて、その考えをまず整理するというところが大事です。その上で「何のルールに基づいてセキュリティをやるか」を決定して、要件定義から設計実装、そしてテスト、運用、それぞれの方に何の技術を得るのかを決定していく、そういうことが必要になってくるのだろうと思います。寺村 その具体的な対策は？ 多くの方は「机上でそんな分析をするって言ってもそれは何なの？」と思われるでしょうし、「それをやる意味はあるのか？」ということをよく言われます。結局何からやるのが一番良いかというと、現状問題があるかどうかをまず一度確認すること。机上で検討していてもまだ決まっていないことや実装に落ちていないことばかりだったりするので、「実際動いているもので今現在テストしてみましょう」「テストして問題点を洗い出した上でフィードバックさせましょう」という方法です。正式には要求定義からするかもしれないけど、なかなかそれでは現場で入っていけないので、実際の製品にテストをしてダメなところを洗い出して、次の製品もしくは現状の製品に対してフィードバックをかけ、それをもとにしてセキュリティ要件を作る、という形で流していくやり方を、結構やっています。例えば私たちはIoTペネトレーションテストの中でハードウェア解析を行っています。ドローンが廃棄されたり墜落したりしたとして、悪い人の手に渡ったらどこまでの情報がハードウェアから盗めるかというテストをドローンを分解してしたり、テスターから空を飛ぶドローンに対して通信をどこまでできるのか試してみたりするものです。実際にやってみると、アップデート機構で脆弱性が見つかることが多い。鍵をドローンの中に入れているパターンで、鍵の管理が甘くて、ソフトウェア解析をするとその鍵が簡単に取れてしまいます。ファームウェアをリバースエンジニアリングして、アセンブルといいますが、その中で鍵を取れたらそれが同一ロットのドローンに関してはその鍵が使え回せたとなると、同一ロットのドローンになりすませることが確定します。ドローンがどういう通信をクラウドに対してやっているかということまでファームウェアから読み取れてしまいます。どこの宛先に対してどこのポートに対してこの鍵を使ってアクセスしたかが全部分かるから、次はそれを模擬していくわけです。今回、ブースでデモをやっていますが、これもこのファームウェア解析をして見つけた脆弱性をもとに、プロドローンさんにご協力をいただきながら行っているものです。利用しているドローンはホワイトラベルなのでプロドローンさんの直接の製品ではないですけども、実際の解析結果をもとにして攻撃するコードを書いてパソコンから操作すると、クラウド経由でドローンを墜落させられるというデモをやっています。このような脆弱性が見つかるので、まずはここからやってみるということを対策としておすすめしています。寺村 GMOグローバルサインの実際の取り組みはいかがでしょうか。 私どもは、主に通信の暗号化と、機体の認証を専門にやっています。特にレベル4になってくると、ドローンと地上のクラウドのシステムを本当に密にやりとりをしながら、機体の状況を常に地上で把握しなければいけない。通信が非常に重要になってきます。そこに対して通信を盗み見られないような暗号化であるとか、あるいは機体や地上システムが相互に認証し、お互いのことを相手が意図したドローンあるいは地上システムであるということを確認しながら通信を行うというところをお手伝いさせていただいています。浅野 環境整備の話も進んでいるということですが、これらの話を聴いて千葉さんいかがでしょうか？ 千葉すごく平たく言うと、会場の皆さんが業務で使われているドローンは穴だらけの可能性があるという話をしています。わたしはインターネット業界出身で前職はスマートフォンゲームの開発をしていました。何百万人のお客様に使っていただいていると、サーバーのハッキングが経営の恐怖です。インターネット企業を経営していると、当たり前のようにハッカーからどうこの我々のサーバー、インターネットの資産を守っていくか、お客様のデータを守るか、というのは至上命題です。なので、まさにGMOサイバーセキュリティ byイエラエさんのようなホワイトハッカー集団に頼んで徹底的に攻撃してくれと。自社の例えばゲームサーバーを攻撃して、我々のシステムは盤石だからといって自信を持ってご依頼すると、やすやすと侵入されてしまい、やすやすと入られたのを塞いでいくというようなことを、ゲームやインターネット業界は息をするようにやっています。でも残念ながら、ドローン業界はハードウェア中心の業界、通信中心の業界なので、あまりハッカーに対してどうこうという概念がない業界です。飛べればいい、あるいはプロペラが止まっても安全に着陸できるようなところに安全性があると、それも正しいです。ハードウェアにトラブルがあった時に何かあっても、人間が死なないためにゆっくり降りてくるとか、あるいはドンと落ちないようにパラシュートを付ければとかありますが、それ以前に一番怖いのは、1万機のドローンが東京の空にレベル4で飛んだ時に、さっきおっしゃっていたように、1万機を根こそぎ奪ってしまったら面白いという考え方、悪意のあるハッカーにすれば、まさに1万機を全部乗っ取ってターゲットポイントに集めて一斉に次々と落としていったら大変な攻撃力を持ってしまうわけです。こういうことを我々がやろうとしているドローン前提社会は、広げれば広げるほどハッカーの脅威にさらされていく。こういう現実を我々は認識しないと、ここから先はやられ放題になるというセッションです。 GMOインターネットグループが今後取り組んでいくこと 今後のGMOインターネットグループとして目指す安全な空の移動のために、さらに今後どのようなことに取り組んでいくのか、また取り組まねばならないのかを、寺村さんにお伺いしてよろしいですか？ 今後の対策として、セキュリティをやっていくというのはなかなか大変です。これはドローンに限らなくて、Webであっても、どこの大企業でも大変です。その中で、やはり国が主導してセキュリティ対策を進める傾向にあると思っています。国土交通省や経済産業省、NEDOさん等がいろいろと進められていますが、あとは業界やセキュリティベンダー等が、国と一緒に、国だけでなく世界と一緒になって、まずはセキュリティインフラを整備していかないといけないと思います。これがないと安全にドローンを飛ばせない。GMOグローバルサイン等のセキュリティベンダーやドローンを作ってくださっているベンダーさんが一体となって、インフラ整備等の取り組みを今後しっかりとやっていかなくてはならないと考えています。寺村 先ほど千葉さんもおっしゃいましたが、なかなかセキュリティにまで意識が向かないというのが現状だと思います。今回私どもがブースを出しているのは、本当にそういったところを皆さんも気を付けていかなければいけないということを啓蒙していくため。こういったことを今後も続けていかなければいけないと思っています。そうした上で、「では何をやったらいいんですか」という話になった時に、GMOサイバーセキュリティ byイエラエであるとか、我々GMOグローバルサインがお手伝いさせていただき、皆さんが不安に思われたところをきちんと埋めていく。こういった作業をしていければと思っております。浅野 千葉今日改めて思いましたが、スポンサーの顔ぶれがすごい。わたしはインターネット業界出身なので、これはどこのインターネットイベントなんだろう？と思ってしまいました。このJapan Droneは歴史ある業界イベントですが、こういったインターネットのトップ企業がプラチナスポンサーをやり、その下にKDDIさん、ソフトバンクさん、NTTドコモさんと通信事業者が冠スポンサーになり、テララボとブルーイノベーション、これらはDRONE FUNDファミリーの大切な仲間なんですが、ドローンを作っているチーム、ソリューションを作っているチームも入っていて、異種格闘技戦みたいな、そういう時代に入ったのかなという感想を今日持ちました。我々は今まで、ラジコン的なドローンから、飛ぶものを作るぞということでずっとこの業界をスタートしてきましたが、いよいよこの社会実装が1年以内に迫ってきたことによって、まさにこのインターネット業界の培ってきたセキュリティなど様々な技術を実装していかないと安心と安全は守れない、だからこれだけの人たちがドローン業界に興味を持っていただけている、というのがわたしの感想です。 千葉さんより、今後のGMOインターネットグループに対する期待はありますか。 千葉インターネット業界においてありとあらゆるインフラをやられているど真ん中の会社様が、ドローン業界に興味を持っていただけたこと自体がすごいと思っていて、SSLの通信を暗号化して守るみたいな話とかはインターネットでは当たり前ですが、たぶんGMOさんが本気でこちら側に興味を持っていただかなければ、我々はたぶんドローン業界で実装することがないと思います。なので、わたしからの期待としては、ぜひインターネットの常識をドローン業界の常識に変えていただければなと思っています。 まさに私どもが目指しているところです。インターネットで培ってきた技術をドローンあるいは空飛ぶクルマに適用していく、広げていくということを、これからやっていかなければいけないんだ、という気持ちを新たにしたところです。浅野 「期待に応えられるように頑張ります」の一言です。ドローンのセキュリティも大事だということで頑張っていきます。新参者かもしれませんけど。寺村 千葉特に、空飛ぶクルマも開発が進んでいまして、ぜひGMOサイバーセキュリティ byイエラエさんにペネトレーションテストを徹底的にやっていただきたい。人が空を飛ぶ時にハッキングされたくないじゃないですか。一番恐ろしいなと思っています。 自動車のペネトレーションテストはたくさんやってきているので、それも踏まえてeVTOLもやれたらと。寺村 千葉以前、GMOサイバーセキュリティ byイエラエさんの会社の資料を拝見した時に、車を乗っ取って、遠隔からパソコンで動かすというデモンストレーション動画を拝見したことがあって、背筋が凍りました。わたしが持っている車種で、乗っ取られるというのはこういうことなのかと。 セキュリティリスクはこれから絶え間なくどんどんアップデートし続けていくものだと思いますが、不安に思われている方が、GMOサイバーセキュリティ byイエラエさんを通じて何か試せることはあるのでしょうか？ 経済産業省さんが本年度事業として、IoT・ドローンも含めたセキュリティリスクの調査をするプロジェクトをやっており、弊社も協力させていただいております。条件はありますが、ドローンを提供いただいたらある程度テストさせていただいて、その結果をフィードバックするという内容になっています。テスト結果は公表しないと思いますが、経済産業省で収集するという調査協力の形でプロジェクトを展開されています。詳細は、興味があればブースの方にお立ち寄りいただければと思います。寺村 本当に貴重なお話をお三方ありがとうございました。 アーカイブ公開 今回の国際カンファレンス「攻撃者はどこを狙うのか？ドローン・eVTOLに求められるセキュリティ対策 ～GMOインターネットグループが目指す「安全な空の移動」～の映像はアーカイブ公開もしていますので、以下より是非ご視聴ください。 https://www.youtube.com/watch?v=HZNFKCse9KM&feature=youtu.be さいごに この度は会場へお越しいただき、また、レポート記事をお読みいただきありがとうございます。 JapanDrone2022の開催レポートは、「Vol.01～Vol.04」を掲載しております。ぜひご一緒にご覧いただければと思います。 https://developers.gmo.jp/20526/ https://developers.gmo.jp/20553/ https://developers.gmo.jp/20557/

2022/4/21（木）ConoHa WINGにWEXAL®が提供されました（→リリースニュース）。 無事に提供することができて開発者一同安心しています（エゴサもしっかりしています）。今回は、ConoHaコントロールパネルで利用できるWEXAL®のバック/フロントエンド設計について、簡単に解説できればと思います。 開発者体制 WEXAL®をリリースするにあたり、大きく分けて以下3つの分野で開発者が作業分担しています。 WINGサーバーのセットアップ/チューニングWINGサーバーとConoHaコントロールパネルを中継するAPIの開発ConoHaコントロールパネル&WordPressプラグインへの機能/画面追加 コントロールパネルは直接WINGサーバーをいじらず、APIを経由します。 他にも、開発したConoHaコントロールパネルの画面に不具合が無いか検証する専門のチームもいます。ここからはConoHaコントロールパネルを”コンパネ”、WordPressプラグインを”プラグイン”と記載します（それぞれ開発現場での名称です）。 WEXAL®のコンパネ/プラグイン設計方針 WEXAL®機能を実装するうえでどのような設計で実装したのか、バックエンドとフロントエンドに分けて解説していきたいと思います。 バックエンド WEXAL®におけるバックエンドはMVCモデルベースで設計されています。MVCモデルと異なる点は、コアロジックはModelではなくServiceという専用のレイヤーに集約している点になります。コンパネ/プラグインに必要なドメインモデルはSDK等の内部実装が既に用意しているため、ドメインモデルをわざわざ定義する必要がありません。そのため、このような設計になっています。現状のConoHaはController部分がファットになりがちですので、いかにコアロジックを切り離すかに注力しています。 破線矢印はインターフェースでの参照になります。コアロジックがModelではなくServiceに集約されているのが特徴です。 View 画面の実装になります。後述するフロントエンドと重複する内容になるので、割愛します。 Controller Controllerはコンパネ/プラグイン双方に用意されています。Serviceを呼び出す際はインターフェースを経由することで、画面ごとに利用できる処理を制限しています。役割は以下の通りです。 処理に必要なServiceの呼び出しServiceから返されるResponseを元に、Modelを生成ViewにModelを返す Model ConoHaにおけるModelは、事実上ViewModelの役割を担っています。先述した通り、コンパネ/プラグインにおけるドメインモデルはSDK等の内部実装に既に定義されているため、敢えてこちら側で用意する必要性が無いためです。役割は以下の通りです。 フロントバリデーションのAttribute実装Viewに返すプロパティの集合体（≒ViewModel） Service WEXAL®におけるコンパネ/プラグイン側のコアロジックが閉じ込められたクラスになります。 WEXAL®のCRUD機能をはじめとしたコアロジックの集約を目的としています。Serviceの呼び出し元はServiceを直参照するのではなく、インターフェースを経由して参照します。これにより、各画面で利用できる機能を定義しています。Serviceの構成は以下の通りです。 WexalService（IControlPanelWexalServiceとIPluginWexalServiceの実装）IControlPanelWexalService（コンパネのみで利用する処理の定義, IWexalServiceの実装）IPluginWexalService（プラグインのみで利用する処理の定義, IWexalServiceの実装）IWexalService（共通で利用する処理の定義） DAO SDKとのつなぎこみの部分になります。インターフェース経由でSDKを参照するため、モックとの差し替えが可能になっています。 フロントエンド WEXAL®におけるフロントエンドは以下のような設計方針で実装されています。基本的にはMVPを踏襲した形で、一部にアレンジを加えた設計になっています。描画描画、通信、制御の責務を分離し、EventHandlerからすべてのイベントのフックを確認できるようにすることを目的としています。 EventHandlerを起点にView/Presenterへ処理が渡ります。Repositoryはインターフェース経由で参照するため、Controllerが未実装でもモックと差し替えることが可能です。 Selector セレクタや属性等の定義集になります。定義を1つにまとめることで、htmlのDOM変更に対応しやすくする意図があります。  役割は以下の通りです。 セレクタ, 属性, Value等の定義と意味づけフロントエンドでセレクタや属性、ValueはすべてSelecterから参照 View 画面の描画制御をつかさどる部分になります。画面描画や画面情報取得の機能をすべて集約しています。役割は以下の通りになります。 画面から情報を取得し、バックエンドへ渡すリクエストモデルを生成バックエンドから返されたレスポンスモデルのデータを描画フロントバリデーションの実行 Presenter ViewとRepositoryの制御をつかさどる部分になります。PresenterはRepositoryの呼び出しが必要な場合にEventHandlerから呼び出されます。役割は以下の通りになります。 EventHandlerからの呼び出しを受ける窓口Repositoryを呼び出し、返却されたResponseをViewに渡して描画命令タイマー処理で定期的に描画命令 Repository Ajaxをつかさどる部分になります。バックエンドとの通信はすべてここで行います。インターフェースを経由するため、MockRepositoryと差し替えることが可能です。役割は以下の通りになります。 Ajaxの定義バックエンド側と通信する際のオブジェクトモデルの定義 EventHandler すべてのユーザーイベントが定義された部分になります。ラジオやチェックボックスのchangeイベントやボタンのクリックイベントなど、すべてのイベントはEventHandlerを起点に発火します。バックエンドの通信が必要な場合はPresenterを、不要の場合はViewを呼び出します。役割は以下の通りになります。 すべてのイベントの定義既に追加されたイベントの削除イベントの再定義必要に応じてView/Presenterの呼び出し まとめ 以上がWEXAL®開発におけるコンパネ/プラグインの設計になりますが、いかがだったでしょうか？システム設計において明確な正解というものはありませんが、WEXAL®においてはこの設計方針でサービスを提供しています。ConoHaはおかげさまで9周年を迎えます。これは非常に嬉しいことですが、ソースコードを見てみるとリリース初期のレガシーコードがちらほら散らばっているのが現状です。これからも長く皆様に愛されるサービスを提供するために、ソースコードも変革期が来ています。今後もConoHaの提供に適したソースコードで開発できるよう、リファクタリングや設計の見直し等できることは全力で取り組んでまいります。このようなリファクタリングやスピード感のある開発に興味のある方、いろいろな設計手法に触れてみたい方―。私たちはいつでもお待ちしていますので、ぜひともGMOインターネットグループにエントリーしていただければと思います。 ConoHaについて 最後に、進化し続けるホスティングサービス「ConoHa」についてご紹介します！ ・国内最速※レンタルサーバーのConoHa WING！・ITエンジニアが使いたいVPS No.1※のConoHa VPS！・快適なWindows環境のConoHa for Windows Server！・応援団長の美雲このはが清楚かわいい！ ※2022年7月自社調べ※日本マーケティングリサーチ機構調べ 調査概要：2022年3月期_ブランドのイメージ調査 記事のところどころにいる、ConoHaの応援団長「美雲このは」と一緒に楽しむConoHaの利用ガイドもあるので是非チェックしてみてください！

6/19（日）「JJUG CCC Spring 2022」がオンラインにて開催され、GMOインターネットグループはセッションスポンサーとして協賛・登壇しました！イベントでは2セッション登壇したうち、今回はGMOペイメントゲートウェイ株式会社が登壇したスポンサーセッション「クレジットカード決済システムをJavaで構築して10年間運用した話」について、登壇レポートをお届けいたします。イベント告知：https://developers.gmo.jp/19185/本記事はこちらのスポンサーセッションの書き起こしとなりますので、ぜひご覧ください。 登壇者 GMOペイメントゲートウェイ株式会社システム本部 決済サービス統括部 エグゼクティブ・リーダー米原 孝太 はじめに クレジットカード決済システムをJavaで構築して10年間運用した話をしたいと思います。GMOペイメントゲートウェイの米原と申します。よろしくお願いいたします。 我々GMOペイメントゲートウェイでは、ECサイトなどのお客様に対して様々な決済手段のサービスを提供しております。本日はその様々な決済手段サービスの中でも一番主力となる、クレジットカード決済のシステムについてお話しします。 まず、クレジットカード決済システムについて概要と、システムを設計した時に考慮した点、それから今回は移行のシステムとなるので、その際のパフォーマンステストについてお話しします。そして、そのシステムを10年間運用してきてその中でどのような対応を行ってきたのかというところを最後に説明します。 1．クレジットカード決済システムについて クレジットカード決済システムは、クレジットカードの会社へ決済の要求電文を送信するシステムとなります。送信先は、CAFISやCARDNETなどの決済用のネットワーク。これらに接続して要求電文を送ります。CAFISはNTTデータさん、CARDNETはJCBさんが提供しているサービスです。 このCAFISやCARDNETの決済ネットワークは、インターネットが始まるよりも前のサービスなので、RFCなどの規格とは関係のない、独自の通信プロトコルを使った独自仕様です。よって、専用のパッケージソフトを利用して接続するのが一般的です。 決済処理なので、トランザクションの一貫性（整合性）を確保することが重要です。また、ECサイトに提供するシステムなので、当然ながら24時間365日無停止のサービスを提供することになります。 今回の対象のシステムは、もともとベンダーへ委託して構築運用していたシステムがあり、それを新しくシステム更改という形で（内製で）新しく作り直したシステムとなります。 サービスの全体概要としては、まず購入者からECサイトを通じてGMOペイメントゲートウェイへのサービスの方に接続があります。そのあと、バックエンドサービスとしてCAFIS、CARDNETなどを通じてカード会社（三井住友カードさん、楽天カードさんなど）に決済要求の電文を上げる仕組みとなっています。 GMOペイメントゲートウェイの中のサービスとしては各種フロントサービスがあり、その後ろのサービスとしてクレジットカード決済システムが存在します。フロントサービス自体は目的によって無数のサービスが存在していて、お客様に対して管理画面を提供したいというようなサービスも提供しています。それらのフロントサービスの中でもクレジットカード決済の処理に関しては、今回発表するクレジットカード決済システムですべて処理する仕組みになっています。 2．システム構築時に考慮した点 このクレジットカード決済システムを構築する時にどういった点を考慮したかということについてお話しします。まず、セキュリティ監査。クレジットカードの世界ではPCI-DSSという監査仕様があるので、これに準拠するところ、また、24時間サービスなので耐障害性のための分散構成を採ったというところ、さらにトランザクションの一貫性を保つところもあり、厳密なトランザクションの処理制御を行うようにしています。では、障害調査の容易性、サービス移行後のパフォーマンスを確保するための仕組みというところを説明します。 ■セキュリティ監査（PCI-DSS）対応 まずセキュリティ監査（PCI-DSS）への対応ですが、PCI-DSSとはクレジットカードの国際ブランドが策定したセキュリティの仕様となります。2008年頃に実際に適用され始めたのですが、ちょうどこのシステムを作る時（2011年）、実際に日本国内でも徐々に対応するという形が広まってきたので、我々が社内で最初にPCI-DSSに準拠しようということで対応することになりました。 要点としては、まずソフトウェア脆弱性の即時対応があります。具体的には、セキュリティーホール等が見つかった時に、それらのパッチが発表されるとそれをすぐに適用するというのが、セキュリティの対応要件としてあります。これに対応するための方法は、CI/CDといったような即時にリリースするための仕組みもまだ用意していませんでした。そのため、採った方法としては変わっていますが、フレームワークとかOSSといったライブラリを極力使用しないことで、対応するというよりもそもそも対応の頻度を下げるという形で対応することにしました。 次にセキュリティ要件として、クレジットカード番号や3Dセキュアの認証情報といったセンシティブデータについては、非保持または暗号化が必要となっています。したがって、センシティブデータをDBに保存する際には暗号化を施しました。また、ログデータとして出力する時は伏せ字、TRUNCATEと呼びますが、アスタリスクで置き換える、意味を持たないデータにするようにしています。 次の要件として、機能単位にサーバを用意するというのが必要になります。具体的には、Webサーバ・DBサーバ・APサーバを1つの筐体の中で1つのサーバOS上に同居させるのではなく、それぞれ個別のサーバを用意してその上に稼働させるというのが要件としてあります。そのために複数サーバを実際に購入して運用するのは非常に費用もかかるので、OS仮想化機能を利用して、1筐体の中で論理的にサーバを細分化することでこれらを実現しました。 ■耐障害性のための分散構成 耐障害性のための分散構成ということで、主要なオンライン機能、具体的にはAPサーバについては多重化構成をとるようにしました。万が一ハードウェア障害などによってサーバがダウンしたとしても、シングル構成にはしない、最低でも2台以上は稼働している状態を保つようにしました。例えばプロセスのフリーズなどが発生した際に、シングル構成だと、早急に復旧させるということでエンジニアによる調査がなかなかできないという問題が出てきます。多重化構成にしておくことで、問題になったサーバについて時間をかけて調査ができるという利点が発生します。また、バッチ処理用のサーバや社内の管理画面に使うサーバについては、それほどクリティカルでもないために、単純な正／副構成とすることで効率を上げています。 ■厳密なトランザクション処理制御 今回、通信処理の部分はTCPソケットライブラリを利用して作成しています。複数のトランザクションを並列処理する部分についてはConcurrency Utilitiesを活用して作成しています。具体的には、処理の役割ごとにスレッドプールを用意して処理を行っています。受信処理と業務処理スレッドを分離することで、受信処理から業務処理スレッドを呼ぶことで制御を行っています。業務処理スレッドが不足している場合にはエラーを即時応答することができます。業務処理が規定時間内に完了しない場合には、規定の時間が経ったところでエラー応答するという仕組みを実装しています。また、規定時間内に完了しなかった取引については、障害取消の処理を行うようにしています。 業務処理スレッドプールについては、処理種別ごとにグループを用意しています。具体的には、業務処理スレッドとして決済要求を処理するグループ、それから取消処理をするグループ、照会などの参照をするためのグループというようにグループを分けることで、例えば決済処理をするグループの方でカード会社が遅延していて、スレッドがすべて埋まってしまったというような場合にでも、取消や照会の要求に対しては正常に処理をすることができるという利点が生まれます。 ■受信処理スレッドから業務処理スレッドへ処理依頼 具体的なコードとしては、ThreadPoolExecutorを利用してスレッドプールを事前に生成しておきます。処理スレッドから業務処理スレッドへ処理依頼する際には、対象のスレッドプールに対して業務処理のクラスを生成した上で渡します。submitの部分になります。submitした際にfutureパターンに沿ってfutureオブジェクトで受け取っておいて、タイムアウト時間を設定した上でget処理を行います。こうすることで、業務処理スレッドプールに空きがない場合にはリジェクトのexceptionが返却されるので、クライアントに対しては現在過負荷状態であるという旨を即時にエラー応答することができます。 この過負荷状態のエラー応答については、実際に大量の処理をする場合のコツがあります。例えば加盟店様がバッチ処理的に連続で処理を呼び出すような場合、即座に応答を返すと連続して処理要求が来て即座にエラー応答を返すということが連続で発生するために、ひたすら処理要求をエラーで返すということでCPUリソースなどを食いつぶしてしまう危険性があります。なので、意図的にエラーを返す前に少しスリープを入れるなどの工夫をして、あえてお客様へ対して処理を待たせるといった検討もしています。 このfuture.getによって規定時間内に処理が返って来なかった場合はタイムアウトエラーとしてクライアントに対してエラーを返します。この場合、業務処理スレッドの方は正常に処理ができている可能性もあるため、後処理として障害取消を行うことでトランザクションの一貫性を保つというふうにしています。 ■障害取消処理を非同期実行 この障害取消の処理を実行する部分の扱いは非同期実行で行うようにしています。障害取消処理の実行を依頼する部分については、DB上にキューに相当するテーブルを用意しておいて、そちらに障害取引の要求電文を書き込みます。処理を行っているスレッド自体は速やかにエラー応答をクライアントへ返すというふうにしています。また、CAFIS等の決済ネットワークの障害取消電文は、大元である決済要求電文とほぼ同じ形でデータ電文を生成することが多いため、通常の処理電文生成時点で障害取消電文も同時に生成しておくと非常に処理が楽になります。書き込まれたDB上の障害取消要求に対して別スレッドでキューから定期的にフェッチして処理を実行することになります。こちらについては別プロセスまたはバッチ処理での実行をするようにしています。 障害取消については、障害取消自体が失敗するということも考慮して設計する必要があります。失敗した場合リトライを行いますが、その際もリトライ間隔やリトライの回数、こちらは決済ネットワークの方の仕様によって時間等が決まっていることがあるので、それを加味した状態で調整するようになります。また、実際に運用しているとそれらの決済ネットワークの事業者からこういう間隔に変えて欲しいとか、間隔をもっと延ばして欲しいといったリクエストを受ける場合もあるので、それらはプロパティ等に設定するようにして、後から調整可能にしておくことが重要です。リトライを繰り返しても障害取消がどうしても完結しないというケースがどうしても出てきてしまいます。そういった場合については、完了しなかった障害取消は日次のレポート等に出力して、その後は人間による運用で対応するという形にしています。 ■障害調査を容易にする 障害調査を容易にする仕組みについて説明します。まず、ログについては1トランザクションにつき1行というのを原則にしています。こちらは、実際に秒何十件何百件というトランザクションが発生するので、1件ごとに複数のログを出してしまうと滝のように流れるログになってしまうため、1トランザクションにつき1行くらいがちょうどよいと思います。ログの内容としては、調査用のキーとなる項目を端的に出力する必要があります。具体的には、トランザクションIDや処理結果（OK／NG、エラーであればエラーコード）、実際にはどの処理がどうなっているかというのを確認する意味も含めまして処理時間、できればそのトランザクションに全体で何ミリ秒かかったのか、またそのうち自身のシステムの中で経過した時間は何ミリ秒だったのか、このあたりを出力しておくと、例えば処理遅延が発生した場合に原因が自身にあるのかそれとも外部にあるのか、こちらを素早く判断することができるので非常に有効になります。 また、調査専用のDBテーブルを用意しておくと非常に楽になります。実際運用していると、月間件数の集計など統計的なものを見ることが多いので、そういった場合に大元の実際の取引のデータ、こちらはレコードサイズも大きいし実際センシティブデータを含んでいることが多いので、集計等をするためだけに要点となる項目のみ絞り込んでさらに集計しやすいようにあらかじめコードで表現するとか、そういった加工したデータを保存するようにしておくと非常に便利になります。 運用していく中でリソースの処理状況を見る必要がありますので、できるだけ詳細な統計情報を取得するようにします。実際にスレッドの利用状況とかDBコネクションの利用数など、こちらを秒単位とかの短い間隔で統計情報として出力することで、実際にはどういう状態になっているのかというのを外部から判断することができるようになります。 3.移行を意識したパフォーマンステスト 今回は既存のシステムを移行する形でサービスシステムを構築しました。したがって、稼働してすぐに大量のトランザクションが実際に発生するというのが分かっていましたので、既存システムの負荷状況を分析しています。具体的には、時間帯ごとの負荷状況や、送信元（お客様）の偏り具合、取引が少ないお客様もいればすごく大量に発生するお客様もいますので、そのあたりの偏り具合も統計をとっています。また、送信先のカード会社、こちらもカードを発行する会社によって発行枚数が違い、平均的とはなっていないので偏り具合も分析しました。あと処理種別、先ほどあったような決済要求や取消など、そういった業務の処理の偏り具合も分析しています。さらに、正常処理だけではなく実際にはエラー処理も発生しますので、そのエラー処理も混ぜるようにしています。 これらの偏り具合を実際に再現するテストをするわけですが、この負荷状況をシミュレートするのにちょうどいいツールがなかったために、今回はJavaで専用のテストドライバを用意して対応しています。 データについては、実際に1ヵ月分のデータを採るのはちょっと難しいので、負荷がピークとなる日、経験上毎月1日に取引量が多いというのが分かっていたので、そちらの1日分のデータを統計としてとっています。 システム移行では当然ながら目標値は現行よりも数倍の性能を目指すので、テストドライバとしても倍率を指定して負荷テストを実施できるような仕組みを用意しています。 実際に統計を取った時の情報をご紹介します。詳細に公開できないところもあるので一部ぼかしていますが、こういった形で実際はかなり偏りがあるというところを再現するようにしています。円グラフになっているのはカード会社の偏り具合です。右下のグラフは、時間帯による取引の偏り具合を統計として取得したものになります。実際、0時～24時の統計ですので、真夜中2時・3時は取引が減っていて、昼休みにあたる12時頃とか、夜の23時頃にどうしても取引が大量に発生するというのが見えています。 今回、テストのために用意した仕組みですが、テストドライバ自体は単純な仕組みとしておいて、それらに渡すデータ（CSVデータ）を事前に生成しておき、そちらで様々なパターンをテストできるという仕組みにしました。実際、先ほど挙げたような統計情報を元にデータ生成ツール（スクリプト言語やExcelなど）を使ってあらかじめCSVのデータを生成しておき、テストドライバとしてはそれらを読み込んでテストデータをシステムの方に投げるという仕組みにしています。その取引のデータを投げた結果をまたデータとして出力して、それらをExcel等でグラフ化することで、処理遅延が発生していないかとか、エラーが大量に発生しないかというのを視覚化した上で、どこに問題があるかというのを推測することに充てています。 ■パフォーマンステスト時のポイント（1） パフォーマンス時のポイントをいくつか挙げたいと思います。 まず非機能要件を確認する。一般的にピーク時に秒何件発生するのかといった要件を入れていますが、同じように処理件数のピーク時の件数を設定します。こちらは瞬間ではなくて1時間それが継続するという想定を挙げています。結構重要なのが、最大の日次処理件数や月間の最大処理件数で、これらも明確にしておく必要があります。日次バッチの処理時間やDBバックアップの時の処理時間、これらを測定する必要があるので、日次・月間の処理件数を明確にしておくことは非常に重要になります。 また、取引の応答時間についても最大処理時間を決めておいて目標値としてその時間内に収まるようにします。ただ、どうしても突発的に遅延というのは発生するので、全体の99.9%が収まるようにといったような少し緩和する条件を付け加えるのもよいと思います。 あとは、前提条件として耐用年数を迎えた状態を用意する必要があります。具体的には、例えば5年後に月間5,000万件を処理するという想定であれば、仮にデータを3か月間保持するシステムで、1.5億件のデータをあらかじめデータベースのレコードとして用意しておきます。できれば意図的にデータも汚す、例えば正常の取引だけが1.5億件入っているだけよりも、そのうちの何割かは取消処理されたといったような少し汚れた状態を作っておくことが重要になります。 ■パフォーマンステスト時のポイント（2） 次に、特殊なテストパターンも用意しておく必要があります。我々はバースト処理と呼んでいますが、瞬間的に大量の取引が発生するということを想定しておきます。実際に、チケット販売のお客様の場合だと、チケットの販売直後にものすごく大量の取引が発生するようなこともあるので、そういった状況も考慮して、例えばある瞬間だけ5秒程度、秒1,000件～2,000件といった大量取引が発生するというような状態を試しておきます。この時、当然ながら目標値を超えるようなものはエラーになってしまいますが、重要なのは、その波を乗り切った後に正常状態に戻るかどうかというところになります。経験的にTomcatのServletとかでシステム構築していますと、そこでエラーが発生した後、さらになかなか波を乗り切っても元の正常状態に戻らないというようなことがよく発生するので、そういった状態が起きないかというのをあらかじめ検証しておくことは非常に重要になります。 それから、ロングランテスト。取引を流した状態で、できれば1週間程度連続稼働させています。こちらは、メモリリークが発生していないか、GC遅延等が発生しないかという様子を見るために非常に重要になります。 プロセス起動直後での高負荷が発生する状況というのもテストしておいた方がよいです。システムのプロセスを起動した直後は、スレッド数とかDBコネクションとか動的に増えるような要素がある部分についてはその高負荷状態に追いつかないケースがありますので、こちらはそれをなんとかするというよりは、そういう状態が起きるというのを事前に知っておくというのが非常に重要になります。なので、例えばリリースをする場合でも、もし負荷が高い時間帯にどうしてもやる場合は、こういったことが起きるかもしれないというのを考慮することができます。 ■パフォーマンステスト時のポイント（3） 当然ながら、設定した要件をクリアできることというのがパフォーマンステストのポイントですが、設定した要件を超えた場合の挙動を確認するという意味もあります。この場合、特にボトルネックになる箇所を見極めておくのが非常に重要になります。CPUのリソースがなくなるのか、メモリが不足するのか、それともDBコネクションが枯渇するのか、そういったボトルネックの箇所を見極めておくことで、将来サービスが拡張していく際にスケールアウトなどのシステムの拡張を行うにあたり、どこを拡張すべきかというのを事前に把握しておくことができます。 また、過負荷状態になった時、その後の平常状態に戻った時に問題が出ないことを確認する、過負荷状態が発生してエラーが発生しますが、その際に不整合の取引が発生していないかどうかを確認することが重要です。 これらのテストを行っていくわけですが、実際にどこまでテストすればいいのかというのが非常に悩ましいところ。私の経験としては、そのテストを指導する立場として、「ここまでテストしても実際の稼働した範囲に問題が出るならば仕方ない」という、自分の中でもう諦めがつくところまでテストするようにしています。 4.10年の間に行ったこと これまでがクレジットカード決済のシステムをJavaで構築した際の話ですが、ここからは、それを実際に運用していてどうなったかというところについて説明します。 ■システム変更履歴 実際に今回のシステムは、2012年10月に移行を開始しました。今回はお客様がたくさんいましたので、一度に全部ではなくて段階的に移行するという手法をとっています。その段階移行が完了したのが2013年1月になります。この後に旧システムを撤去しています。それからあまり時間が空いていませんが、2013年3月にサーバを増強しています。こちらはパフォーマンステストと実際のサービス移行をしている中で、すでにAPサーバが少しリソース不足であるというのがもう統計的には分かっていましたので、早いうちにサーバ増強の対応を行っています。続いて、2015年11月の時点で、お客様の要件としてもあったためにDR環境を新しく追加しています。こちらはシステム増強というか、DR用に別拠点にサブセットの環境も一式用意して、データ同期等を行うというような対応を行っています。2017年10月、ちょうど5年ほど経過したところで、DBサーバの方のリソースが不足気味であるというのが分かっていたのと、他のサービスでのDB移行を行うという目論みがあったために、この時点でDBサーバの更改を行っています。こちらのDBサーバの更改を行ったことで、システムとしてはさらに処理件数も増やせるような状況になっていました。それからさらに少し年数が経ちまして、去年（2021年12月）の時点で、それまで稼働していたDBサーバ以外の部分、WEB/AP/バッチサーバといった部分について、全面的に更改を行っています。 ■2021年更改時内容 その2021年の更改時に変えたところを説明します。 OS/Javaのバージョンアップ実際にサーバも変えていますので、当然ながらOSもバージョンアップし、このタイミングでJavaもほぼ最新のものにバージョンアップしています。 制御系処理の改善制御系処理を改善しています。具体的には、処理経路アルゴリズムを見直すことで処理の効率化を図っています。 制御系テーブルをインメモリDBへ変更分散処理をする上でどうしても制御系のテーブルをデータベースに持っていたのですが、この部分がどうしても処理パフォーマンス上のネックになるというのが分かっていました。よって、それらの制御系テーブルについてはインメモリDBを新しく用意してそちらに移し替えるという形にしています。これによってかなり処理のパフォーマンスが良くなっています。 バッチ処理モジュールにフレームワーク導入それまではバッチ処理も含めて基本的に各モジュールにはフレームワークを入れていなかったのですが、このタイミングでバッチ処理についてはフレームワークを入れるようにしました。具体的には、Spring Batchのフレームワークを導入しています。 バッチ処理実行をcron起動からジョブ管理製品へ変更それまではバッチ処理の実行をcron起動によって行っていましたが、このタイミングで一般的に売っているジョブネット等が組めるジョブ管理製品に変更しています。 ビルドツール変更それまでは使っているライブラリ等も少なかったので、実際にEcripse上でただコンパイルするだけというようなビルドの仕方だったのですが、今回の更改のタイミングから、Maven&Jenkinsを使ったビルド方式に変更しています。 不要テーブルの削除バッチ処理を変更したということと、監視系の見直し等も行った結果、使っていない、なくても特に問題ないといったテーブルがあったので、それらの不要テーブルをこのタイミングで削除しています。 暗号化用秘密鍵の管理方式変更セキュリティのために暗号化処理を行っていますが、そのための秘密鍵の管理方法を変更しています。こちらは、PCI-DSSの要件が2～3年おきに更新されていくので、PCI-DSSのバージョンアップに対応するための変更を行いました。 ■統括 今回のシステムのように業務要件の変更があまりないシステムについては、Javaで構築した息の長いプログラムを稼働するケースがあります。この場合、計画時に性能要件を明確にするとともに、定期的な性能測定を行いつつ、早めの拡張計画を立てることが必要です。また、ハードウェアの保守期間やOS／ミドルウェアのサポート期間の期限が切れることがあるので、これらを考慮した設計導入を行うことが非常に重要だと思っています。 むすび 最後になりますが、我々GMOペイメントゲートウェイではエンジニアの仲間を募集しています。我々GMOペイメントゲートウェイでは、お客様にサービスを提供することを主目的としています。そのサービス自体は我々自身で構築して運用しています。実際に、先ほども説明したように、10年近く前に構築したシステムを運用し続けるといったようなことを行っています。その中で実際に私自身もここについてはちょっと失敗したなというような思う点もありますが、逆にここについては狙い通りにできたというふうに思える部分もあります。我々はシステムを構築することが目的ではなくて、実際にそのシステムを運用してサービスを提供することが目的です。そういった自分の実績を確認できることは、エンジニアとして非常に幸せなことだと思っています。皆さんも、もし興味がありましたらぜひ採用サイトを訪れてみてください。 以上、ありがとうございました。 Q&A 質問1：金融システム観点で、設計段階から注意するべきことなどありますか？ 主催設定した要件を超えた場合の挙動、ここはシステム設計及び運用をされている上でも、やはり一番重要視されてることの1つだという風に考えてるんですが、いかがでしょうか。 そうですね、決済・お金を扱っていますので、これがあとで不整合みたいなことが起きると、非常に後処理が大変ですし信用も失っていきますので、その辺を十分に考慮して処理をすると。ウェブサービスよりも1段上のシステムを作っているという意識を持って設計テストをするようにしています。米原 質問2：システム更改の際、スプリングバッチ及びスプリングフレームワークの選定理由について教えてください。 主催PCI-DSSの観点で、当初のパッチの適用が必要になることからプレイバックをさけるみたいな話もちょっとあったかと思うんですけれども、そこはあえてスプリングバッチを入れた判断というのと、そのスプリングバッヂを選択した理由とかですね、その辺ちょっと差し支えない範囲でお話しいただけますか。 それまでがバッチ処理はクーロン起動っていう形でかなり作り込んで実施していたんですが、今回更改のタイミングでJP1を使ってジョブスケジュールでやることになりました。社内的に全部そちらで統一しましたので、そちらに移行した方が運用しやすい、となりました。その上でいろいろ作り変えていくとこがあったので、これを機にフレームワークを入れようという形で、特にこの機能が使いたいとか、そういうわけではなかったんですけれど、徐々にフレームワークを入れていこうという方針に変わってますので、それで対応したという感じですね。米原 主催そうなんですね。じゃあそこでスプリングバッジを選択したっていうのは、たまたまそこで何らかの基準があって、スプリングバッチを選択されたという感じですかね。 社内のシステムが基本的にはスプリング、フレームワーク系を使うように今なってますので、そうすると他のチームから移ってきた人とかも、同じフレームワークを使っている方がやりやすいというところもあって、社内的にある程度共通化していく、技術の共通化を図るというところを目指してます。米原 質問3：「安定稼働するシステムの更改タイミングについて」アーキテクト・プロジェクトリードの側面からコツ（勘所）を教えてください。 主催10年間（実際にはもう移行前からいうともっと長いかとは思うんですけれども）例えば今回の場合だと移行のタイムとアプリケーションのロジックをちょっと変えてみたりとかあったかと思うんですが、そのタイミングというのはどのように判断したのかっていうあたりで、アーキテクトの立場なのか、そのプロジェクトリードの立場なのかっていうのもいろいろあるかと思うんですけども、「このタイミングだ」という風に判断された理由とそのタイミングがいつだったかというところを、もしよければお話しいただければと思います。 そうですね。これタイミングが非常に難しくて、やっぱり安定して動いているシステムほどなかなか変えるっていうのが難しくて、正直に言えば一番はハードウェアの保守が切れて、もう変えなきゃいけないというタイミングでハードウェアを変えるのであれば、この時にアプリケーションも見直しをかけましょう、という、そういったタイミングでもないとなかなか動いているものに手を入れるっていうのは非常に勇気がいるというか難しいのが実情ですね。あとは長年運用していますと、だんだんサポート切れという問題も増えてきますので、そこをそういったサポート切れが一番タイミングとしては分かりやすいといいますか、機会としてはちょうどいいかと思います。ただ、そのために色々準備は必要ですので、早めにここから公開するぞという計画を立てるのが重要なところになります。米原 主催どっちかというと、外部要因が一番大きなインパクトや影響を受けたところではあるけれども、事前にもちろんそういうことがあってもいいように準備だけはしておかれたということですかね。 そうですね。まあ、普段から運用していますと、この辺がちょっとネックになっているとか問題があるとかだんだん上がってきますので、でもその場ですぐに対応するしかないというのは、どうしてもたまってくるんですよね。そういうのを事前に調べて、こういう風に変えていこうとかっていう調査とかは進めておいて、それをまとめて一気に対応するというような感じで運用することが多いですね。米原 質問4：フレームワークを使うメリット等あれば、教えてください。 主催PCI-DSSの観点でフレームワーク極力排しますっていうお話は、これが多分視聴者の皆さんもかなりインパクトがあったようでして。例えばこの10年間の中で、フレームワークあれば良かったなと思った時というとどんな時がありましたか？というご質問をいただいております。 一番は、やはりだんだんメンバーが入れ替わったり増えたりしていく中で、フレームワークを使ってないと、そもそもこれ何？みたいな感じでやっぱり入ってきた人にはちょっと意味が分からないみたいで。設計書はあるんですが、そんなに詳細な説明書を用意したわけでもないのでやはり少し見てもらって対応していく、という流れになります。最初の入り口で時間かかるので、そういう意味ではやっぱりフレームワークを入れていると、特にスプリングなんてもうメジャーですから、皆さんだいたい触ったことあります、分かりますと。プロジェクトに参加した時、最初の慣れてくるまでの時間という意味では、フレームはあった方がいいなというのは思いました。米原 主催なるほど、ありがとうございます。やはり最初に作った人と後から入ってきたというところにギャップがあって、そのキャッチアップに時間がかかるというのは、運用する上では結構厳しかったりもしますもんね。 そうですね、はい。米原 質問5：言語やライブラリのバージョンアップ問題による、影響などあれば教えてください。 主催2021年のタイミングでJAVAのバージョンアップもされましたよっていうお話をされていらっしゃいましたけど、今までいわゆるフレームワークを使わずに、元々のライブラリをずっとメンテナンスされてってことだったと思います。今まで御社で作られたライブラリもバージョンアップによってやはり何らかの形で影響があったかと思うのですが、どのあたりが一番影響が大きかったですか？ここも言える範囲でお願いいたします。 そうですね。まあ正直そんなに影響はなかったですね。ただやっぱりJAVAはバージョン変わるとそれまでとちょっと微妙に動きが変わるっていうところが出てきますので、そこを事前に動作を調べてどういう風に変わるか、どういう風に影響出るかっていう、これには結構時間がかかっています。具体的にはテスト担当が1人2人専属でやってもらって、やっぱり1～2ヶ月ぐらい。工数でいうと2人月3人月ぐらいはやっぱりかけて調べて、どういう風に対応すればいいかというところを調べた上で、結構やっぱり時間はかかります。米原 主催小さいけれど、やっぱりそれを潰していかないと突然予想できない動きをされると困るっていうところもありますよね。 そうですね。米原 質問6：パフォーマンス改善に伴う、ボトルネックなどあれば教えてください。 主催パフォーマンスが問題になる場合に、どの辺がボトルネックになることが多いですか？ピンポイントに絞っていただいて結構なので、例えばこういう例どうですかっていうところでお話しいただけますか。 そうですね、一番ネックになるのはやっぱりデータベースのコネクションですね。DB（データベース）コネクションはやっぱり無限に使えるわけではないので、今回例えば決済システムですと、この後ろに具体的にはクレジットカード会社をまたいで最終的な与信枠まで使って大丈夫かっていうチェックまでして返ってくるので、1秒から数秒かかるんですよね。単純に作ると、その間はずっとスレッドが動きっぱなしというか。そうするとコネクションも握りっぱなしで実際何もしてないのに、ただリソースだけを使う状態っていうのが発生するので、その辺りはちょっと工夫して一旦コネクション離すとかそういう工夫しないとすぐにコネクションツールを使い切ってしまうので、結構苦労してますね。米原 主催なかなかそこはそうですよね。やはりブロッキングになってしまうと、なかなか難しいというころですかね。やっぱりその辺りが興味深いと思ってる方々がやはり多いですね。 質問7：JAVAバージョンアップによるパフォーマンス改善の恩恵などあれば教えてください。 主催先程のJAVAのバージョンアップによって、挙動が変わったところをつぶして行かれた、というところに関連してなのですが、バージョンが上がると、例えばGC（ガベージコレクション）のパフォーマンスが上がるとか色々良いこと、もちろんこの機能無くなって困ったねっていうパターンもあるかとは思うんですけど、パフォーマンス的な違いっていうのって何か体感されたこと、例えばパフォーマンス指標自体収集されて、これぐらい変わったんだっていうのをもし御社の今回の移行の中でこの辺はすごいアップデートすることによって良い影響をもらったなっていうのは何かありましたらお話しいただけますか。 JAVAのバージョンアップ自体でパフォーマンスがこう劇的に上がったっていうのは実はそこまでないですね。どちらかというと、その仕組みを色々見直して結果2倍3倍ぐらいの処理能力に上げていますけど、やっぱ一番効いたのはデータベースで排他制御していたところをインメモリーDBに変えたとか、そういうところも効いてますし、でもそのためにやっぱりいろいろJAVAの新機能を使ったりしてますので、なかなか単純にJAVAのバージョンを上げたから、ポンと上がるっていうのはちょっと体感的にはないですね。米原 主催なるほど、そうですよね。GCE単体のベンチマークを取ってるとかっていうんだったら別でしょうけども、システムとしてはトータルで見ないといけないというところもあるんで、トータルで見ると、例えばインメモリーでDBを入れましたとか、その他あと工夫というかアーキテクチャー上の改善とかをされて、パフォーマンスが当初よりももちろん上がったというような感じですかね。 おまけ 主催米原さんよりお話をしたいことがあるということで、イベントの告知ですかね。では、ちょっとお願いできますか。 はい、我々GMOインターネットグループが開催してますオンラインイベントとして、Developers Nightというのがあります。これが7月14日（木）に開催されるのですが、その中で我々の新しい決済サービスであるfincode byGMOっていうのがあり、こちらの話をします。実はこちらのサービスの裏側として、今回説明した決済システムを使ってクレジットカードの処理をしています。こちらのサービス開始する時に実は私も一部関与していまして、実際に一緒に開発したメンバーがこちらのイベントで登壇しますので、ぜひ参加して話を聞いていただければと思います。よろしくお願いいたします。米原 主催はい、ありがとうございます。（イベントでは）なかなか濃い話をしていただける、と思っていいですか？ そうですね。具体的にどう作ったとかっていう話があるはずですので。米原 主催なるほど、ありがとうございます。どう作ったかというのもあるだろうし、ここ少し頑張ったよ、みたいなしみじみ感あるようなお話もあればいいかなと思います。視聴者の皆さん、ぜひ楽しみにしていただいて参加登録いただければと思います。 参加申し込みはこちら https://developers.gmo.jp/20150/ さいごに ご視聴・ご参加いただき、ありがとうございました。たくさんのご質問もいただき、重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://youtu.be/2tGMbGfJkW4 クレジットカード決済システムをJavaで構築して10年間運用した話 連載記事はこちら https://developers.gmo.jp/21413/

GMOインターネットグループの稲守です。前回に続き、新卒技術研修についてお送りします。本エントリーでは新卒技術研修で使用された資料の一部を公開します。 前回記事 https://developers.gmo.jp//technology/18135 今年度のGMOテクノロジーブートキャンプ（以下、GTB）では下記のカリキュラムを実施しました。 2022年度 GTBカリキュラム 研修資料 GUI設計概論・実践https://www.figma.com/proto/AzekAIQzyZ9wk2XiCwQtYL/GUI%E8%A8%AD%E8%A8%88 Webアプリケーションhttps://speakerdeck.com/gmodev/gtb2022-webappframework Webコーディング実践編https://speakerdeck.com/gmodev/gtb2022-webcoding Webデザイン基礎https://speakerdeck.com/gmodev/gtb2022-webdesign サービス開発プロセスhttps://speakerdeck.com/gmodev/gtb2022-servicedev インターネットの歴史https://speakerdeck.com/gmodev/gtb2022-history-of-webit 今回紹介した資料はほんの一部です。全ての講義資料は社内の研修チャネルで自由に閲覧できるようになっています。次回記事では、新卒技術研修の成果発表会などのアウトプットについてお届けします。 さいごに 7/14（木）に技術イベントをオンラインで開催します。年間数兆円の決済インフラを支えるGMOペイメントゲートウェイが、fincode byGMOというスタートアップ向けにサクッと決済機能を実装できる新サービスの提供をはじめました。こちらをテーマにオンラインイベント開催します！ぜひご参加ください。 参加申し込みはこちら

こんにちは。GMOインターネット セキュリティエンジニアの中田です。皆さんはネットワークのデータを見たことはあるでしょうか。実はネットワークのデータって誰でもみることができちゃうんです。この記事では、暗号化されていない通信がどれだけ危険かをWireSharkというツールを使って見てみましょう。 パケットについて ネットワークに流れるデータは、パケットという細分化された塊にヘッダーという情報を付与されて通信が行われます。 ヘッダー情報とは、送信元/宛先情報や通信先へパケットが届いたときに元にのデータに戻せるな情報のことです。ではなぜネットワークを流れるデータは、パケットという細分化された塊にしてデータを送信するのでしょうか。それは大きいデータをそのまま送ると回線を占有してしまい、データ通信に支障をきたしてしまうからです。例えば、ピザを食べるとします。そのまま一枚を切らずに食べるとなると大変ですが、6等分にするなど細分化することによって、みんなとシェアして食べられますし、あとで食べるために取って置いたりすることができます。ピザをそのまま食べると大変なように大きなデータをそのまま通信しようすると回線を占有してしまうため、ネットワークを流れるデータはパケットという細分化されたデータで変換され、通信を行います。では、実際にツールを使ってパケットを見てみましょう。 パケットのイメージ Wiresharkについて 実際にパケットを取得し中身を見ることをパケットキャプチャというのですが、今回はWiresharkというツールを使ってパケットの中身を見ていきます。 Wiresharkとは、ネットワークを流れるデータをキャプチャして内容を解析・表示するプロトコルアナライザ（ネットワークアナライザ）の一つです。※インストール方法については、省略致します。 使い方について インストールが終わったらwiresharkのショートカットをクリック それぞれのイーサネットの中でデータ見れるものをクリックしましょう（ここではイーサネットを選択してみます） Wiresharkを起動させるとたくさんのパケットが流れているのが確認できると思います。 上記のデータ詳細欄に通信に必要な宛先/送信元のIPやMACアドレスなどのヘッダー情報が見えます。 この情報をもとに通信が行われ、みなさんのもとにWEBサイトや画像をみることができるのです。 実際に通信内容の確認してみよう 今回は、一般的にWEBサイトへアクセスする際に使用されるhttpとhttpsの通信でWordpressの管理画面からログインした際のパケットがどういう風に見えているか確認してみます。http：暗号化されていない通信https：暗号化されている通信 http 通信の場合 httpの通信内容を見てみるとログイン情報（log/pwd）が見えているのが確認できると思います。 https 通信の場合 暗号されているhttps通信の場合は、何がかかれているか復号する鍵がない限り解読できないようになっています。 最後に 暗号化されていない通信は中身が全てみえてしまい、パケットキャプチャされてしまうと情報が容易に流出してしまうことがわかっていただけましたでしょうか。皆さんもうっかりhttp通信のWEBサイトに個人情報を入力しないように注意しましょう。 また、暗号化されていてもそれが安全なものでなければ簡単に復号化されてしまい、知らないところで個人情報が流出してしまうこともあるかもしれません。

　クラウドストレージとしてとても便利なOneDriveは、オフィスワークには欠かせません。場所を選ばないクラウドサービスならではの使いやすさと、専門知識は不要で十分なセキュリティーを担保してくれますのでテレワークにも最適です。今回は様々なOneDriveへのファイルのアップロード方法を紹介します。 デスクトップアプリケーションから 　Windows10にはOneDriveアプリケーションが最初からインストールされていますので、サインインするだけですぐに利用可能です。個人利用のOneDrive、Microsoft365のOneDrive Business、SharePointのドキュメントファイルにアクセス可能です。 サインイン後、ファイルエクスプローラーから直接参照可能となります。設定メニューからアカウントを追加すると個人アカウントの OneDriveも同時に表示することができます。タスクバー右隅には、Microsoft365のOne Drive for Businessは青い雲のアイコン、個人アカウントは白い雲のアイコンが表示されます。 さらにSharePointサイトのドキュメントから「同期」を選択すると、ファイルエクスプローラーからOneDriveの操作が可能となります。 SharePointのドキュメントもファイルエクスプローラーから操作可能に。ファイルエクスプローラーに表示されていれば、デスクトップのファイルと何ら変わらずファイルのアップロードが簡単にできます。 ブラウザから 　もちろんブラウザからもアクセスができます。デスクトップから直接ドラッグ＆ドロップでファイルアップロードが可能です。 Teamsから 　Teamsアプリケーションからもアクセス可能です。TeamsのチームからはSharePointのドキュメントを参照することになります。 左メニューのファイルからは個人のOneDrive for Businessを参照可能です。 スマートフォンアプリから 　Android、iPhoneどちらのスマートフォンアプリからも利用できます。移動中にファイルのチェックや、撮影した写真をすぐにOneDriveにアップロードして、仲間と情報交換といったモバイルならではの使い方ができます。 Power Automateから 　Power Automateからはもちろん、OneDriveのコネクタが利用できますので、簡単にファイルアップロードのフローが作成できます。 Power Appsから 　以前利用した、Power AutomateとPower Appsの連携でファイルをアップロードしてみましょう。Power Automate側はこのようになります。OneDriveのアクションで指定する「ファイル名」には triggerBody()?['file']?['Name'] こちらの式を設定します。 Power Apps側は前回も利用した「添付ファイルコントロール」を配置して、アップロードボタンには ForAll( DataCardValue3.Attachments,'OneDrive-ファイルアップロード02'.Run( {file:{ contentBytes:Value, name:Name } } )) こちらの式を設定します。For～Allを利用して複数のファイルのアップロードに対応しています。 添付したファイルの内容を表示するために、「挿入」メニューから「ギャラリー」の縦型を選択します。Itemsに DataCardValue3.Attachments.Value を設定します。 ギャラリーに表示するのは、「添付ファイルコントロール」でアップされたファイルになります。Imageには ThisItem.Value を設定して、Image以外は全て非表示にしておきます。 ここまで出来たら実行してみましょう。添付したファイルが画像の場合はサムネイルが表示されます。 アップロードボタンを選択すると画像もテキストファイルもアップロードされました。 HTTPリクエストから 　Power AutomateにはAPIとしてHTTPリクエストを受け付けることができるトリガーとして「HTTP 要求の受信時」が用意されています。こちらを利用すると、外部からのHTTPリクエストでOneDriveにファイルをアップロードすることができます。フロー全体はこのようになります。 「要求本文の JSON スキーマ」には { "type": "object", "properties": { "fileName": { "type": "string" }, "contents": { "type": "string" } }} こちらを設定します。リクエストで受け取るのは、ファイル名とBase64にエンコードされたファイルのデータとなります。 「ファイルコンテンツ」には base64ToBinary(triggerBody()?['contents']) を設定します。 Base64の文字列で受け取ったファイルデータをバイナリデータに変換して、アップロードするファイルの仕様に適合させています。最後に、一番上の「HTTP POST の URL」をコピーしておきます。このURLがAPIの窓口となります。ここまで出来たら保存しておきましょう。 では実際にこのAPIを呼び出すコードを作成します。HTTPリクエストを実行出来れば言語は問いません。今回はPowerShellです。変数 $Url には先ほどコピーした「HTTP POST の URL」を設定します。コードの内では、APIの仕様に合わせてアップロードするファイルをいったんBase64のテキスト形式に変換してPOSTしています。 $FilePath = "C:\Users\Administrator\Documents\test.txt"$FileName = Split-Path $FilePath -Leaf$Url = "取得したHTTP POST の URL"$FileToBase64 = [Convert]::ToBase64String([System.IO.File]::ReadAllBytes($FilePath))$PostText = @{fileName=$FileName; contents=$FileToBase64} | ConvertTo-Json -Compress$PostBody = [Text.Encoding]::UTF8.GetBytes($PostText)Invoke-RestMethod -Method POST -Uri $Url -Body $PostBody -ContentType application/json 実行してみましょう。成功しました！ 　以上、 OneDrive へのファイルのアップロードをアレコレと紹介しました。これだのアプローチ方法が用意されているので、利用シーンに合わせて様々に使い分けることができます。移動中でもテレワークでも、業務の自動化でもOneDriveにアクセスできるので働き方改革には必須のサービスとなっています。クラウドストレージとしてのOneDriveはPower AutomateやPower Apps、他のクラウドサービスや、オリジナルのアプリケーションと組み合わせて工夫次第では立派な業務システムの構築もできそうです。

　普段はインフラエンジニアをやっている柳です。前回の記事「オープンソースで作成する顔認証Web Server / vol.01」と共通する部分も多いため参照ください。音声認識とは人間の声をコンピューターに認識させることです。音声認識にはWeb Speech APIという無料で使えるAPIがありhtmlとJavaScriptで実装可能です。しかしそれでは面白くない為、機械学習部分も含めサーバーを構築していきたいと思います。言語はフロントにhtml、JavaScript、バックにPythonを用います。 1.完成イメージ 　Web Speech APIと同じ動作をすることを目標とします。ブラウザ上でリアルタイムに音声認識し短文としてウェブページ上に表示します。 Web Speech APIでの実装は下記となります。htmlファイルとして保存しブラウザで起動すれば動作可能です。※インターネット環境が必要です。 <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>Web Speech API</title> </head> <body> <h2>Web Speech API</h2> <button id="start_btn">start</button> <button id="stop_btn">stop</button> <small id="status"></small> <h3>Recognition Result</h3> <textarea id="show_progress" cols="100" rows="1"></textarea> <div id="show_result"></div> </body> <script> // Declare webkitSpeechRecognition window.SpeechRecognition = window.SpeechRecognition || webkitSpeechRecognition; var recognition = new webkitSpeechRecognition(); // Web Speech API Configuration // Language recognition.lang = 'ja'; // Show Progress recognition.interimResults = true; // Continuous recognition recognition.continuous = true; // Const const start_btn = document.getElementById('start_btn'); const stop_btn = document.getElementById('stop_btn'); const show_progress = document.getElementById('show_progress') const show_result = document.getElementById('show_result'); recognition.onsoundstart = function(){ document.getElementById('status').innerHTML = "Recognizing"; }; recognition.onnomatch = function(){ document.getElementById('status').innerHTML = "Try again"; }; recognition.onerror= function(){ document.getElementById('status').innerHTML = "ERROR"; }; recognition.onsoundend = function(){ document.getElementById('status').innerHTML = "Stopped"; }; start_btn.addEventListener('click' , function() { // Start recognition recognition.start(); this.disabled = true; stop_btn.disabled = false; }); stop_btn.addEventListener('click' , function() { // Stop recognition recognition.stop(); this.disabled = true; start_btn.disabled = false; show_progress.innerHTML = ''; }); recognition.onresult = function(event){ var results = event.results; for (var i = event.resultIndex; i<results.length; i++){ if(results[i].isFinal) show_result.innerHTML += '<div>'+ results[i][0].transcript +'</div>'; else show_progress.innerHTML = "[Progress] "+ results[i][0].transcript; } } </script> </html> 2.サーバー構成 　フロント（HTML, API）のウェブアプリケーションフレームワークはFastAPI、バックエンドにはEnd-to-End音声処理のESPnet2を利用します。（FastAPIのアプリケーションは前回同様Gunicornで起動しリバプロにnginxを挟んでいます。） クライアント側のマイク起動はWebRTCのAPIで行い、音声データの前処理はWeb Audio APIを利用します。 3.Web Audio API 　クライアント側での音声処理ワークフローです。マイクで入力された音声をHTTPS（Port441）でサーバーにポストする処理を担当しています。 （1）WebRTCのgetUserMediaでマイク起動 16bit、16kHz、モノラルを指定しマイクのアナログ入力を32ビット浮動小数点数（-1.0～1.0）でAD変換し入力します。 （2）AudioContextを定義 ESPnet2で利用する16kHzのサンプルレートを指定しAudioContextを定義します。 （3）MediaStreamAudioSourceNode createMediaStreamSourceでストリーム（WebRTC）からの入力ノードを作成します。 （4）AudioWorkletNode AudioWorkletNodeはScriptProcessorNodeの後継となります。音声録音用のレコーダーを作成します。AudioWorkletNodeではbufferSizeを指定できませんが内部では128サンプルで処理されています。 （5）recorderProcessor 入力データを処理する場合はここで定義します。今回は入力データを処理する必要がない為中身は空となります。 （6）AudioDestinationNode レコーダーを出力先に接続します。 （7）WebSocket WebSocketを定義しサーバーへ音声データをPostできるようにします。port.onmessageで入力データを随時サーバーへBinary Dataとしてポストします。 //(2) Declare audio context const context = new AudioContext({ sampleRate: sampleRate }); //(3) Create MediaStreamAudioSourceNode const source = context.createMediaStreamSource(stream); //(4&5) Create AudioWorkletNode await context.audioWorklet.addModule('static/js/recorderProcessor.js'); const recorder = new AudioWorkletNode(context, 'recorder'); // Connect MediaStreamAudioSourceNode and AudioWorkletNode source.connect(recorder); //(6) Connect AudioWorkletNode and AudioDestinationNode recorder.connect(context.destination); //(7) WebSocket let connection = new WebSocket(websocketUrl); // Send audio data connection.onopen = function(event) { show_status.textContent = "Recognizing"; // Send stream to websocket recorder.port.onmessage = msg => { connection.send(msg.data.buffer); }; }; サーバー側で受け取ったデータを出力先が処理可能なデータに整形し渡します。 ■ESPnet2解析時 websocketのreceive_bytes でデータを受取後ndarray（float32）へ変換します。 # Recieve binary data data = await websocket.receive_bytes() # Convert bibary to numpy ndarray(float32) np_data = np.frombuffer(data, dtype='float32') ■音声ファイル保存 32ビット浮動小数点からリニアPCM（16bit符号付整数）に変換します。※215－1を掛けることで変換できます。 # Change float32(-1.0 ~ 1.0) to 16bit signed integer(-32,768 ~ 32767) int_size = 2**(SAMPLE_SIZE - 1) – 1 np_data = (np_data * int_size).astype(np.int16) 下記ページを参考にさせて頂きました。 https://qiita.com/ryoyakawai/items/1160586653330ccbf4a4https://developer.mozilla.org/ja/docs/Web/API/Web_Audio_API 4.Websocket 双方向通信 リアルタイム音声認識を実現するため、WebSocketでサーバークライアント間の双方向通信を実装する必要があります。また音声データは途切れることなくクライアントからサーバーへ送付されるため、音声データの受信処理（websocket.receive_bytes）と解析結果の送信処理（websocket.send_text）が同時にサーバー側で行えるよう非同期処理で実装します。 5.音声認識 ここからはサーバー側の処理を説明します。音声認識はespnet_model_zooをインストールしESPnetの学習済みモデルを利用します。下記ページを参考にさせて頂きました。 https://tech.retrieva.jp/entry/2020/12/23/170645 # ASRモデルを指定しSpeech2Textを定義 speech2text = Speech2Text(asr_config, asr_pth, device=device) # 32bit floatの音声データ(np_data)を入力 nbests = speech2text(np_data) # 解析結果(text)を取り出し text, *_ = nbests[0] ■ESPnet2について 音声認（ASR）、テキスト音声合成（TTS）、音声強調（SE）がサポートされている音声処理ツールキットです。機械学習部分にはPyTorchが採用されています。レシピと呼ばれるシェルスクリプトがありモデルの構築も可能です。 詳しくは下記ページを参照ください。今回は学習済モデルを利用するためモデルの構築は必要ありません。 https://kan-bayashi.github.io/asj-espnet2-tutorial/ ■End To End音声認識について 従来の音声認識技術では、音響モデル、言語モデル、発音辞書を組み合わせ、音声認識システムを構築していました。End To Endモデルでは特徴量からダイレクトに文字や単語をニューラルネットワークから予測し出力します。 https://techblog.yahoo.co.jp/entry/2020062930010545/ ■ ESPnet2でのASR（音声認識）フローについて https://tech.fusic.co.jp/posts/2021-08-03-espnet/ 6.音声区間検出（Voice Activity Detector） リアルタイム音声認識に必要となる音声区間検出についてです。会話の区切り（息継ぎ）を見つけることで短い文、単語として音声を解析させます。End To Endモデルでは長い文章で解析するより短い文に区切り解析した方が高速となります。 例：「今日の天気は晴れ後曇り。/最高気温は三十度です。/夕方から雨が降る可能性があるので/傘を持っていくと安心です」（音声11秒） （A）1音声ファイルで入力した場合　　　解析時間：33秒（CPU）、2.97秒（GPU） （B）4音声ファイル（/で分割）で入力した場合　　　解析時間：14秒（CPU）、2.11秒 （GPU） 会話中、会話終了、無音は下記で判断します。 （A）会話中　：音声区間検出あり（B）会話終了：音声区間検出なし、Speech DATAあり（C）無　音　：音声区間検出なし、Speech DATAなし ① WebSocketからデータを受信しWebsocket DATAに格納します。② Websocket DATA[リスト型]から音声をPOP（Websocket DATAリストは空となる）　後、音声区間検出（VAD）を行います。　└音声あり：データをSpeech DATAへappend（追加）し①へ　└音声なし：③へ③ Speech DATA[リスト型]から音声をPOP（Speech DATAリストは空となる）　後、データありなしを判別します。　└データあり：会話終了、解析処理を行います　└データなし：無音区間、①へ戻ります ※データをPOPしリストを空にすることが重要です。音声区間検出実行のインターバルは1～2秒が最適と思います。　└短いインターバル：音声途中で解析を行う（息継ぎ等）の可能性が高くなります　└長いインターバル：会話と会話が繋がり解析する可能性が高くなります このフローであれば長い文章でも単語でも息継ぎを見つけることでリアルタイム（1-2秒後）に結果を表示可能となります。 7.WebRTC マイク入力切り替え 　音声認識で重要な要素の1つがマイクの性能です。ノートPC内蔵マイクでも認識可能ですが雑音が多く認識率が下がります。専用の指向性マイクを利用すると雑音が少なく認識率が良くなります。クライアント別にマイクが選択できるようWebRTCで実装しました。 実装イメージは下記となります。 navigator.mediaDevices.enumerateDevicesでデバイスリストを取得し必要な部分のみ加工しHTMLへ表示させる形です。コードは下記となります。 <select id="audioSource"></select> const audioInputSelect = document.querySelector('select#audioSource'); const selectors = [audioInputSelect]; // Get device list and show list on select button function gotDevices(deviceInfos) { // Handles being called several times to update labels. Preserve values. const values = selectors.map(select => select.value); selectors.forEach(select => { while (select.firstChild) { select.removeChild(select.firstChild); } }); for (let i = 0; i !== deviceInfos.length; ++i) { const deviceInfo = deviceInfos[i]; const option = document.createElement('option'); option.value = deviceInfo.deviceId; if (deviceInfo.kind === 'audioinput') { option.text = deviceInfo.label || `microphone ${audioInputSelect.length + 1}`; audioInputSelect.appendChild(option); } } selectors.forEach((select, selectorIndex) => { if (Array.prototype.slice.call(select.childNodes).some(n => n.value === values[selectorIndex])) { select.value = values[selectorIndex]; } }); } // Create device list navigator.mediaDevices.enumerateDevices().then(gotDevices); 下記ページを参考にさせて頂きました。 https://webrtc.github.io/samples/src/content/devices/input-output/ 8.各種比較結果 ESPnet2 学習済みモデル （1）kan-bayashi/csj_asr_train_asr_transformer_raw_char_sp_valid.acc.ave コーパス：CSJ、言語：日本語、容量：411MB、周波数：16kHz、訓練時間：45時間、必要GPUメモリ：1.7GB【結果】日本語認識率○、特定の不得意な単語あり （2）Shinji Watanabe/laborotv_asr_train_asr_conformer2_latest33_raw_char_sp_valid.acc.ave Watanabe/laborotv_asr_train_asr_conformer2_latest33_raw_char_sp_valid.acc.aveコーパス：LaboroTV、言語：日本語、容量：611MB、周波数：16kHz、訓練時間：2,049 時間、必要GPUメモリ：1.7GB【結果】日本語認識率◎、全く異なる文章に変換する場合あり （3）Hoon Chung/jsut_asr_train_asr_conformer8_raw_char_sp_valid.acc.ave コーパス：JSUT、言語：日本語、容量：212MB、周波数：16kHz、訓練時間：10時間【結果】認識率✕、学習データが少ないと思います →（1）または（2）を利用するのが良いと思います。 その他学習済モデルhttps://github.com/espnet/espnet_model_zoo/blob/master/espnet_model_zoo/table.csvtaskはASR、lnagはjpを選びます。※fs（周波数）に注意ください。 音声区間検出（Voice Activity Detector） （1）inaSpeechSegmenter ffmpegのインストールが必要となります。wav audio形式の入力はできますがnumpy形式は不可。別途Numpy形式を入力できるよう改修が必要となります。またnumpy, typing-extensionsがデグレードするためお勧めできません。 参考：https://www.ai-shift.co.jp/techblog/1686 （2）silero-vad PyTorchとの相性がよく実装が容易です。子音部分をはっきり検知するため誤認識が少なく不要な単語別れもない為まとまった文で区切られます。 参考：https://pytorch.org/hub/snakers4_silero-vad_vad/ （3）pyannote-audio 話者ダイアリゼーションを得意としています。複数の話者が話している音声データを解析し話者を識別することが可能です。ただしその分解析処理に時間を要します。リアルタイム性に課題はありますが議事録作成に非常に有用と思います。 参考：https://github.com/pyannote/pyannote-audio →今回は（2）silero-vadを利用し音声区間検出を実装しました。 9.開発環境準備 開発はWindows 10がインストールされたノートPC1台（＋Bluetoothマイク）で進めます。全てを1台で完結させるためCPUパワーを必要としますが高速にデバッグ可能です。 （1）Anacondaインストール 下記ページを参考にインストールします。https://www.javadrive.jp/python/install/index5.html#section1 （2）必要なパッケージインストール Anacondaプロンプトを起動し必要なパッケージをインストールします。 conda install pytorch torchaudio cpuonly -c pytorch conda install -c conda-forge fastapi python-multipart conda install -c conda-forge uvicorn[standard] conda install aiofiles jinja2 pip3 install espnet_model_zoo pip3 install SoundFile （3）仮想環境作成 base環境をコピーし開発用の環境を作成します。 conda create -n poc --clone base conda activate poc （4）アプリケーションダウンロード conda install -c anaconda git git clone https://github.com/masayay/maispeech.git （5）Config編集 [1] maifaceへ移動リネーム 　conf_sample_win.pyをconf.pyへリネーム [2] フォルダ作成＆必要に応じてconf修正 　C:\User\Music\wav 　C:\User\Music\models （6）Uvicornでアプリケーション起動 [1] アプリケーションディレクトリへ移動 　cd maispeech [2] アプリケーション起動 　uvicorn speech_api:app 下記メッセージが表示されれば起動成功です。 SpeechRecognition started on device: cpu Using legacy_rel_pos and it will be deprecated in the future. Started server process Waiting for application startup. Application startup complete. Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit) マイクに向かって話すと下記のようにログが流れます。 DEBUG:uvicorn:Speech Recognition: テスト DEBUG:uvicorn:Speech Recognition: ＹｏｕＴｕｂｅ （7）接続テスト ブラウザでhttp://127.0.0.1:8000/を開きます。 ※http://127.0.0.1:8000/は手順（1）～（6）実施後アクセス可能です。※ブラウザよりマイクのアクセス許可を求めらますので「許可」します。 （8）認識結果比較 左が今回作成した音声認識ウェブサーバーで右側がWeb Speech APIを利用した結果となります。かなり等しい結果が出力されるよう作成できたと思います。 10.所感 　顔認証、音声認識を提供するWebサーバーを構築し、バックエンドの機械学習部分は異なる知識が必要だと感じました。顔認証では画像から特徴を見つけ、音声認識では波形から特徴を見つけ学習します。しかしこの異なる分野も機械学習の登場により共通部分が増えて来ていると感じました。 関連記事はこちら https://developers.gmo.jp/17430/

こんにちは、GMOインターネット ネットワークチームの梅崎です。今回は先日取得した 一陸特 （第一級陸上特殊無線技士）の免許について養成課程で「へえ～」となったことやこれ知ってたほうが便利だなということを書いていきたいと思います。 そもそも一陸特とは？ 陸上特殊無線技士とは簡単に言うと陸上の無線局を扱うのに必要な免許となっています。扱える操作内容や電波出力によって一～三級までの資格がありさらにその上位資格もあったりします。詳しくはWikipediaで なぜ取得したのか？ 弊社ではローカル5Gを構築しておりまして、社内にも無線について学んだ人がいた方が良いよねとなりまして養成課程を受講してきました。実際、免許取得時の諸元等、ここはこういう意味だったのか！と視界が広がった気分になっています。 本編 どこからどこまでが電波？ 電波や赤外線、可視光線、紫外線やX線、γ線といった電磁波と呼ばれているもののうち日本の法令では300万メガヘルツ以下の周波数のものを「電波」として扱うらしいです。 正直、案外厳密に決まっているものなんだなーと思いました。まあ法令なので厳密で当然と言えば当然ですが。 電流の表皮効果 電流が電線を流れる際に高周波になればなるほど電線の中心の電流密度が小さくなり、表面だけを電流が流れるらしいです。導体の抵抗は断面積に反比例するので、同じ導線でも周波数が高ければ高いほど抵抗が大きくなってしまいます。（高周波になると、後述のものと合わせてあんまり電線使わないらしいです） 高周波でのコイルやコンデンサの挙動 リアクタンスは周波数によって変わるため高周波になればコンデンサの静電容量が小さくともリアクタンスはとても小さくコイルのインダクタンスが小さくとも リアクタンスはとても大きくなってしまいます。 ……? 簡単に言ってしまうと電線同士の距離が近いと電線がコンデンサで接続されているように振る舞ってしまい、電線が少しでも捩れると電線にコイルを挿入したようになってしまう。 高周波の世界では、そんな線の取り回し一つで回路が全く違う挙動をしていまうピーキーな世界なのです。 導波管 高周波では前述の理由もあり、導波管というものを使ってエネルギーを送るらしいです。雑に言ってしまうと導体の筒の中を電波として飛ばしちゃうというものです。 電力を電波として筒で送るなんてことがあるとは驚きでしたが、よくよく考えると同じ電磁波を送る光ファイバーもあるのでさもありなんと感じました。 空中線とは？ ローカル5Gの免許取得で空中線という単語をよく見ていて正直、 空中線？？となっていたのですがなんのことはなく「アンテナ」の邦訳というだけでした。 なんだか、過去のアンテナが空中に電線を張ったものだったので見たまま空中線と読んだのでは？とのこと WWII頃の軍艦の画像で謎のワイヤーが張られていると思うのですが、あれもアンテナらしいです。それを聞いて確かに空中線だわ……と思いました。 色々出てくるdB〇〇 ・dBmが電力の表示に使われ、1mWの何倍か？という値・dBμが電圧のの表示に使われ、1μVの何倍か？という値 アンテナ利得の文脈で・dBiとあれば、三次元的に偏りのないアンテナを基準にしたもの・dBとあれば、半波長ダイポールアンテナを基準にしたもの（dBdとも書くらしい） 単位を最後まで書かない文化のようで、ちょっと困っちゃいますが……とりあえず上の4つを覚えておけば大丈夫そうでした。 dBの計算方法 1倍で0dB2倍で3dB3倍で4.8dB7倍で8.4dB10倍で10dB（エネルギーのとき） これだけ覚えておけば、サクッと概算ができて便利でした（例：5倍なら10/2倍で10dB-3 dB →7dB） 締め 色々書いていると長くなってしまったのでまた、知っておくと便利なものがあれば投稿しようかと思います。 ここまで読んでいただいてありがとうございました。

本記事では、SSH経由でファイルシステムをマウントする便利ツールsshfsが開発終了となったため、代わりにRcloneを使用することをご紹介します。Rcloneはさまざまなプロバイダーに対応しており、ローカルとクラウドストレージを同期することができます。設定や使い方の詳細については下記内容をご確認ください。 はじめに みなさん、こんにちは。GMOインターネット株式会社の斉藤です。 ご存じの方もいらっしゃると思いますが、SSH経由でファイルシステムをマウントできる便利ツールsshfsが開発終了となりました。 https://github.com/libfuse/sshfs 拙訳: このプロジェクトは今後メンテナンス/開発は行われません。よって、GitHub issueとプルリクエストは無効になりました。下記のメーリングリストは利用可能です。このプロジェクトを引き継ぎたいのでしたら歓迎します。プロジェクトをフォークして開発を続けてください。6ヶ月に渡って有効な活動がある場合、私のメールアドレスまでコンタクトして下さい。喜んであなたにこのプロジェクトのオーナーシップ権限をお渡しするか、ここをフォークしたプロジェクトへのポインターにします。 リモートファイルシステムのマウントは、特に一時的な用途でとても便利です。開発中にリモートのソースコードが欲しいときにつかったり、サーバーのメンテナンス/移行作業などで大活躍します。 sshfsはとてもポピュラーで私もかなりお世話になりました。作者の方にはお疲れ様でしたと申し上げたいです。残念ながら開発終了の理由は探せませんでしたが、もしご存じの方がいましたら教えてもらえるとうれしいです。 Rclone sshfsの代わりにRcloneというオープンソースのツールを使ってみましょう。 Rclone syncs your files to cloud storage https://rclone.org/ Rcloneはローカルとクラウドストレージと同期することを目的に開発されたツールです。非常に多くのプロバイダーがサポートされていて、ssh以外にもAmazon S3, Google Cloud Storage, Microsoft One Driveなど数多くのクラウドストレージをサポートしています。OpenStack Swiftもサポートしているので、ConoHaのオブジェクトストレージでも使うことができます。サポートしているプロバイダーのリストはこちらです。 「ファイルの同期」を主目的としてはいるものの他の機能も多く実装されていて、よく使うファイル作成、コピー、削除のようなものから、ディレクトリのマウント、リモートファイルの閲覧など、おおよそ必要なファイルオペレーションは一通りサポートされています。ディレクトリのマウントはsshfsを代替できるもので。 インストール RcloneはWindows, macOS, Linuxなどのプラットフォームで動作します。以下のURLから自分のプラットフォームにあった方法でインストールを進めていきます。 https://rclone.org/install/ macOSの場合はHomebrewを使うのでは無く、自分でバイナリファイルをダウンロードしてインストールするのが良いでしょう。macFUSEが不要になります。 設定 Rcloneではリモートのストレージに接続する前に、あらかじめ設定を行っておく必要があります。リモートストレージ毎に「プロバイダー」と呼ばれるコネクタが用意されていて、それぞれ固有の設定を持っています。SSHなどでリモートのサーバー上のファイルシステムをマウントする場合、「SFTP」というプロバイダーを使います。 https://rclone.org/sftp/ 設定を行っていきますが、Rcloneには対話的なコマンドが用意されています。便利なのでこれを使うのが良いでしょう。ちなみに設定ファイル自体はホームディレクトリの ~/.config/rclone/rclone.conf に保存されます(macOSやLinuxの場合)。 少し長いですが大半の項目は省略可能です。大括弧の部分は私からの補足説明ですので参考にしてみてください。 $ 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-vps [←リモート設定の名前を入力します。よく使うので短い方が良いです。後で変更可能] 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> sftp [←sftpと入力します] Option host. SSH host to connect to. E.g. "example.com". Enter a value. host> conoha.hironobu.org [←接続先のホスト名を入力します] Option user. SSH username. Enter a string value. Press Enter for the default (hiro). user> [←SSHのユーザー名を入力します。省略すると今現在ログイン中のユーザー名が使われます] Option port. SSH port number. Enter a signed integer. Press Enter for the default (22). port>　 [←ポート番号を入力します。省略可能] Option pass. SSH password, leave blank to use ssh-agent. Choose an alternative below. Press Enter for the default (n). y) Yes, type in my own password g) Generate random password n) No, leave this optional password blank (default) y/g/n> [←パスワードを入力します。公開鍵認証を使う場合はそのままエンター] Option key_pem. Raw PEM-encoded private key. If specified, will override key_file parameter. Enter a value. Press Enter to leave empty. key_pem> [←PEM形式の秘密鍵を直接入力できます。省略可能。次でファイル名でも指定できます] Option key_file. Path to PEM-encoded private key file. Leave blank or set key-use-agent to use ssh-agent. Leading `~` will be expanded in the file name as will environment variables such as `${RCLONE_CONFIG_DIR}`. Enter a value. Press Enter to leave empty. key_file> ~/.ssh/id_ed25519 [←秘密鍵のファイル名を入力します。私はこちらを使いました] Option key_file_pass. The passphrase to decrypt the PEM-encoded private key file. Only PEM encrypted key files (old OpenSSH format) are supported. Encrypted keys in the new OpenSSH format can't be used. Choose an alternative below. Press Enter for the default (n). y) Yes, type in my own password g) Generate random password n) No, leave this optional password blank (default) y/g/n> [←秘密鍵のパスワードを入力します。省略可能] Option pubkey_file. Optional path to public key file. Set this if you have a signed certificate you want to use for authentication. Leading `~` will be expanded in the file name as will environment variables such as `${RCLONE_CONFIG_DIR}`. Enter a value. Press Enter to leave empty. pubkey_file> [←公開鍵ファイルを指定できます。省略可能] Option key_use_agent. When set forces the usage of the ssh-agent. When key-file is also set, the ".pub" file of the specified key-file is read and only the associated key is requested from the ssh-agent. This allows to avoid `Too many authentication failures for *username*` errors when the ssh-agent contains many keys. Enter a boolean value (true or false). Press Enter for the default (false). key_use_agent> [←ssh-agentを使う場合はtrueにします。省略可能] Option use_insecure_cipher. Enable the use of insecure ciphers and key exchange methods. This enables the use of the following insecure ciphers and key exchange methods: - aes128-cbc - aes192-cbc - aes256-cbc - 3des-cbc - diffie-hellman-group-exchange-sha256 - diffie-hellman-group-exchange-sha1 Those algorithms are insecure and may allow plaintext data to be recovered by an attacker. Choose a number from below, or type in your own boolean value (true or false). Press Enter for the default (false). 1 / Use default Cipher list. \ (false) 2 / Enables the use of the aes128-cbc cipher and diffie-hellman-group-exchange-sha256, diffie-hellman-group-exchange-sha1 key exchange. \ (true) use_insecure_cipher> false [←falseで良いでしょう。古いサーバーに接続する場合はtrueにする必要があるかもしれません] Option disable_hashcheck. Disable the execution of SSH commands to determine if remote file hashing is available. Leave blank or set to false to enable hashing (recommended), set to true to disable hashing. Enter a boolean value (true or false). Press Enter for the default (false). disable_hashcheck> [←SFTPのハッシュチェックを無効にします。省略可能] Edit advanced config? y) Yes n) No (default) y/n> [←拡張設定を行いたい場合はYesと答えます。省略可能] -------------------- [conoha-vps] type = sftp host = conoha.hironobu.org key_file = ~/.ssh/id_ed25519 -------------------- y) Yes this is OK (default) e) Edit this remote d) Delete this remote y/e/d> y Current remotes: Name Type ==== ==== conoha-vps sftp e) Edit existing remote n) New remote d) Delete remote r) Rename remote c) Copy remote s) Set configuration password q) Quit config e/n/d/r/c/s/q> q 以上で設定が終わりました。 rcloneコマンドの基本的な書式は、 rclone [サブコマンド] [パラメーター] となります。ひとまず先ほど作成したリモート設定が正常に動作するか確認するために lsd サブコマンドを使ってみましょう。lsdはリモートのディレクトリを一覧表示するサブコマンドです。 $ rclone lsd conoha-vps:/home/hiro -1 2022-04-25 17:57:52 -1 .config -1 2022-04-28 15:07:55 -1 .docker -1 2022-05-12 12:04:45 -1 .local -1 2022-04-11 16:07:46 -1 .npm -1 2022-06-03 12:05:00 -1 .ssh -1 2022-04-25 12:36:33 -1 .vim -1 2022-05-31 04:30:57 -1 .vscode-server -1 2022-01-05 17:26:05 -1 dotfiles -1 2022-01-05 17:26:21 -1 local conoha-vps:/home/hiro の部分は先ほど作成したリモート設定の名前と表示したいファイルパスをコロンで繋いだものです。sshfsでも使われた形式ですね。/home/hiroの部分は省略可能で、その場合はホームディレクトリを指定したことになります。 サブコマンドにはもちろんlsdではないlsもありますが、一般的なlsとは違ってデフォルトでディレクトリを再帰して表示しようとします。ホームディレクトリを表示すると膨大な数の一覧が返ってくることがあるので、ここではあえてlsdを使いました。 ここで一つ注意することがあります。ホームディレクトリを表すのにチルダ ~ がよく使われますが、rcloneではシェル展開されないので使えません。 サブコマンドは他にもmkdir, copy, rmdir, deleteなど一般的なファイルオペレーションで使われそうなものも揃っていて直感的に使えます。これだけで一通りリモートファイルの操作ができるでしょう。syncというサブコマンドもあって、これはrsyncのように使うことができます。 マウントする sshfsのようにリモートファイルシステムをローカルにマウントする場合は、そのままの名前でmountと言うサブコマンドを使います。簡単な使い方は以下のようになります。sshfsと似ていますね。 $ rclone mount [リモート名:リモートパス] [マウントポイント] 「マウントポイント」とはローカルのパスです。 このコマンドを実行するとフォアグランドで実行されますが、--daemonオプションを付けてバックグラウンドで実行することもできます。 マウントを解除する場合はumountでローカルのマウント先を指定します。バックグラウンドで実行した場合でもこの方法でアンマウントできます。 umount [マウントポイント] これもsshfsと同じです。 まとめ Rcloneをsshfsの代替として使ってみました。事前に設定を行う必要がある部分がsshfsには無かった点です、ただそれ以外は使い勝手も似ているので、代替ツールとして使っていけるのではないでしょうか。 Rcloneは非常に多機能でAmazon S3やGoogle Cloud Storageのようなクラウドストレージにも対応しています。最初の方で少し触れましたが、ConoHaのオブジェクトストレージもローカルにマウントできますので、次回はそのあたりの設定を解説しようかと思います。 それではまた次回お目にかかりましょう。 [PR] 私が働いているGMOインターネット株式会社ではエンジニアを含め採用を強化しています。 募集職種 | GMOインターネット株式会社採用 「いきなり応募するもなぁ」と言う方は、Twitter DMで私に直接ご相談いただいても構いません。社内の雰囲気、開発現場の雰囲気、人間関係、待遇など、社内の人物からリアルな情報を知りたいという方はお気軽にどうぞ。

こんにちは。デベロッパーリレーションズチームの村上です。今回は最近チームで取り組んでいるスクラム開発について書いていきます。よく聞く開発手法だけど具体的にどんなものなのか、実際生産性って向上するのか等、気になる方はぜひ参考にしていただければ幸いです。 スクラムの導入 今回チームにスクラム開発を導入するとなった経緯は、上長からの指示がきっかけでした。ただ自分自身別の機会でスクラム開発のいい部分を経験していたので、ぜひ取り組みたいものでした。全員で始めるのは難しいので、まずはトライアルとして少数で始めることになりました。 https://developers.gmo.jp/5571/ https://developers.gmo.jp/14672/ 体制について スクラムマスターは私が担当し、サービスのディレクションをするディレクターにプロダクトオーナーを担当してもらってます。開発チームは新卒2～3年目のメンバーを中心に4名アサインしました。全員がスクラム開発をするのは初めてなので、（今もですが）手探りで最適なやり方を探しています。ステークホルダーは事業部の担当者になりますが、まだまだスクラム開発の流れにうまく参加してもらえていない部分があるので、今後更にスクラム開発を進めていく上では、協力してもらうことが必須になってきそうだなと考えてます。 スクラム実践 それでは実際にどのように実践しているかを書いていこうと思います。実践するにあたり、所謂スクラム開発の型には嵌めてまず取り組み、チームのやり方として合わないなというものを自分たちに合うように改変して行っています。なのでアンチパターンを含む部分もありますが、ご了承いただけると幸いです。 使っているツールに関して スクラム開発を行う際に、バックログやタスクボードを管理する必要がありますが、本来であればホワイトボードに模造紙を貼り、直接書き込んだり付箋をペタペタ貼っていきます。ただ現在オフライン・オンラインでのハイブリッドな体制で日々業務を行っているので、今回はmiroを使用しています。スクラム開発で出てきた様々な情報は、このmiroに書き込んでいってチームの全員がいつも目に入るようにしておくことで、作業効率をアップさせていきます。 スプリントの期間 テンプレートなやり方だと、スプリントの期間は最低2週間からと言われています。それに倣いうちのチームでも1スプリントを2週間と定めました。案件によっては2週間が長すぎる場合もありますが、まずはスクラム開発のリズムを掴んでもらうため、現在もそのままにしています。 デイリースクラム デイリースクラムは朝に行っています。デイリースクラムは15分以内という制約があるので、それ以前と比べてスピーディーにMTGを終わらせることができています。ただ時間に囚われて大事な報告や相談事が漏れてしまうことがあったので、短い時間の中でしっかりと話し合う力をつけることは大事かもし行うれません。報告を行う際は、ふんわりとした表現は使わず、あと○時間で終わりますや、こういう懸念事項があるので終わりませんと言い切った報告してもらえるとわかりやすいですね。 スプリントプランニング スプリントプランニングは主にスプリントの開始時にやってますが、バックログがなくなってきたり新しいバックログが追加された際は都度行っていきます。最初は仕様がわかっている私がタスク作成を行っていたのですが、現在は開発チームで頑張ってやってもらってます。タスクに関してはなるべく細かく分割するようにして、複数の改修を含まないように作ってもらってます。そうすることでタスクのコードレビューがやりやすくなり、ミスが減ったり複数人での仕様の理解が進んでいるように感じます。タスクは開発チームでサインアップしており、自身のレベルに合わせたタスクを取ったり、やってみたいタスクを取れる環境ができています。スクラム開発の当初より積極的にサインアップを行っていたり、難しいタスクを複数人で対応しようとしたりする姿が見えて、チームも成長している実感が非常にあります。 スプリントレトロスペクティブ 振り返りに関してはまだうまく意見を出せてる感じはありません。今後もスクラム開発を継続していくことで「なぜうまくいかなかったか」「次回はどうすればうまくいくのか」を繰り返していくことが大事だと考えてます。まだまだ意見は少ないですが、慣れてくればもう少しスクラム開発についてが見えてくるようになるはずです。 これから改善する点 上記のスクラムの実践ですが、現在3ヶ月ほど経過した状況です。その中でもこれから実践・改善に取り組まないといけないポイントを上げていきます。 スプリントの期間が長い 現状細かな案件を含めると週に2度ほどリリース作業を行っています。その状態でスプリントが2週間というのがちょっと長すぎるかなという印象があります。アンチパターンではありますが、スプリントを1週間にして、金曜にスプリントプランニング、木曜にスプリントレビューを行うようなリズムが良さそうと考えてます。週末にプランニングしておくことで、週初めからスムーズに作業に入れるかなと考えたからです。いっそスプリントレビューも金曜にして、午前中にスプリントレビュー、午後にスプリントプランニングみたいなやり方でも良いかもしれません。 ベロシティが安定しない・測りづらい これには色々な要因があると考えます。 1つはサービス開発における運用案件の存在です。現在のスプリントプランニングに運用案件を入れていない為、純粋に元あるタスクが進まないという状態になります。プランニングに含めればベロシティとしては測れるようになるので、今後は含めてスクラムを回していかないといけません。 それ以外だとストーリーポイントの数値の不正確さです。これはエンジニアのスキル差が結構あるのもあるし、そもそもプランニングポーカーの数値のイメージがチーム内で揃っていないような感じを受けてます。今後もあんまり上手く見積もれる気がしていないので、実際の時間で見積もりしようかと考えてます。通常はストーリーポイントとかでタスクの分割を意識するのですが、現在は1改修＝1タスクにしてかなり細かくしてるので、タスクに落とし込む部分はうまくできてそうです。 スプリントレビューの重要度 スプリントレビューはスプリントでのインクリメントのレビューを行うものですが、現状では開発に入った段階でかなり仕様が確定してるので、ステークホルダーにインクリメントのレビューを行ってもらうほどじゃないという状態です。ただリリース直前にステークホルダーのチェックがはいるので、それがスプリントレビューの代わりになってます。どのような形でスプリントレビューを実施するか、その形を今後は模索していくことになりそうです。 まとめ いかがだったでしょうか。まだまだ荒削りというか試行錯誤の段階なので、色々と考える部分はあるのですが、うまくスクラム開発を回せれば生産性向上に繋がりそうな感じはあります。現在うちのチーム以外でもスクラムチームの運用が始まっており、定期的に情報共有を行ってます。みなさんもスクラム開発は自分のチームに合わないなと最初から決めず、まずは取り組んでみて自己流にカスタマイズするのもありじゃないかなと思います。それがアンチパターンであったとしても、結果として生産性向上に繋がれば成功です。ぜひ取り組んでみてください。