バックエンド の記事一覧

こんにちは、GMOインターネットグループ株式会社 システム統括本部 ホスティング・クラウド開発部 アプリケーション共通チーム（AWS運用チーム）の井本です。弊社では、2023年よりオンプレミスからクラウド環境へとシフトする取り組みを実施しております。その中で得たAWS運用の知見や現在の取り組み、運用チームとしての今後の展望について本記事で紹介させていただきます。 はじめに 私は配属以来、AWS関連業務, 社内開発ツール（CICD CodePipeline 自動作成ツール等）の機能追加、DevSecOps, RPA活用プロジェクトなど、多くの業務を担当をさせていただき、成長機会をいただいております。 本記事では、中でも主業務として取り組んでいるAWS運用チームの取り組みについて、その知見や現時点における課題、中長期的な今後の展望とともに紹介させていただきます。 現在の取り組み 一般的に、運用では、すべて手作業で行う「運用開始フェーズ」、自動化・移譲を推進する「自動化・移譲フェーズ」、ある程度自動化・移譲が完了し、より生産性の高い業務に取り組む「安定フェーズ」に分けられると私は考えています。結論、弊社のAWS運用においては、現在「自動化・移譲フェーズ」にあり、すべて手作業で行っていた定常業務を、ツール導入により自動化したり、各チームへの移譲を進めている段階です。 具体的に、どのような定常業務があり、現時点での自動化・移譲の状況はどうなっているかをまとめてみました。 定常業務 AWS運用チームとしての現在の定常業務は下記となっております。 IAM Identity Centerの追加・編集・削除AWSアカウント権限追加AWSアカウント作成AWS予算管理 / コスト報告コストモニタリング / コスト削減施策AWSサービス稼働前各種申請TGW関連作業DNS（名前解決）設定Public HostZone登録CICD CodePipeline作成 なお、これらの定常業務は、すべてドキュメント化やレクチャーを適宜実施しており、AWS運用メンバー全員が対応できる状態となっております。 自動化・移譲への取り組み 自動化・移譲が完了している業務 AWSアカウント権限追加（一時的な権限付与）AWSサービス稼働前各種申請CICD CodePipeline作成 AWSアカウント権限追加（一時的な権限付与）については、aws-samplesにて公開されていますTemporary Elevated Access Management (TEAM)というソリューションを弊社の要件に合うようにカスタマイズし、私が11月にリリースさせていただいたGuardianというアプリケーションにて、自動化を実現しました。また、他業務については、各チームにレクチャーを行い、作業の移譲を実現しました。なお、CICD CodePipelineは、社内ツールに適宜機能追加をしており、GUI上の操作のみで作成できる仕組みとなっております。 自動化・移譲の余地がある業務 AWS予算管理 / コスト報告コストモニタリング / コスト削減施策TGW関連作業DNS（名前解決）設定Public HostZone登録 自動化・移譲予定のない業務 IAM Identity Centerの追加・編集・削除AWSアカウント権限追加（恒久的な権限付与）AWSアカウント作成 これらはすべて、セキュアに管理・操作を行う必要があり、自動化・移譲を実現しようとすると、かえって各方面への調整や作業コストが膨大になってしまうため、直近で自動化・移譲は予定しておりません。 現時点における課題 AWS運用チームでは、下記の3点に課題を抱えており、目下取り組んでおります。 「自動化・移譲の余地がある業務」の自動化・移譲セキュリティ統制（発見的統制）の整備コスト最適化 「自動化・移譲の余地がある業務」の自動化・移譲 コスト関連の業務については、現状はAWS運用チームが日次でモニタリングし、適宜、コスト削減施策を実施していますが、今後は各チームでコスト意識、およびコスト削減目標を持っていただき、移譲を進めていく予定です。また、TGW関連作業やDNS設定、Public HostZone登録については、社内ツールの機能追加を行い、自動化や移譲の実現を検討しております。 セキュリティ統制（発見的統制）の整備 セキュリティ統制としては、一般的に予防的統制と発見的統制があります。予防的統制には、ネットワークトラフィック保護（ACM）,ネットワーク、ファイアウォール構成（セキュリティグループ, WAF）, サーバー側の暗号化（KMS）などがあります。発見的統制は、セキュリティイベントに備えるというもので、AWS Config Rules, AWS Security Hub, Amazon GuardDutyなどを利用して整備を行うのが一般的です。 弊社では、予防的統制は既に整備が完了していますが、発見的統制については一部Amazon GuardDutyを導入しているものの、充分な活用は出来ていない状況です。そのため、まずはAmazon GuardDutyを活用して、継続的なデータ分析およびセキュリティ監視を行い、検出結果からその対応を進めていきたいと考えています。 コスト最適化 現状、NAT集約やNATとVPC-EPのコストを比較した通信経路の最適化、不要リソースの特定・削除、ECSにおけるスペック最適化など、順次コスト削減施策を実施しています。全商材共通で取り組む必要があるコスト削減施策としては、テスト環境停止（業務時間外）の自動化を残すくらいですが、今後も継続的にコスト削減施策を実施していくために、タグ付けによる可視化やクイックウィン最適化、アーキテクチャ最適化など、まずはAWS運用チームの中で知見を深める必要があると考えています。 中長期的な今後の展望 先述した課題への取り組みが完了すれば、AWSのリリースノートから新機能・サービスのキャッチアップを行い、各チームへの展開やソリューションの提供に取り組んでいきたいと考えています。また、AWS全般における知見を深め、GPTsなども有効活用しながら、各チームの技術的な支援にも注力していきたいと考えております。 さらに、弊社ではDevSecOpsの推進も行っているため、そのプロジェクトと連携しながら、ログアーキテクチャの見直しを実施し、アプリケーションスタックのあらゆるレベルでモニタリングとロギングの機能を持てる状態を実現させていきたいと考えています。 おわりに いかがだったでしょうか。 以上が、AWS運用チームの取り組みになります。皆様に引き続き、安心して弊社のサービスをご愛顧いただけるよう、私自身、まだまだ駆け出しのエンジニアではありますが、日々奮闘していきたいと思います。

こんにちは、GMOインターネットグループ株式会社の河﨑屋です。今回はOJT（実務研修）の一環で新卒の方々と一緒にイベントストーミングを行った話をご紹介します。 710プログラムとは 現在GMOインターネットグループでは、新卒世代で最高のポテンシャルを秘めた人財に集まってもらうべく『新卒年収710万円プログラム』を実施しております。（初任給・給与ナンバーワン~新卒年収710万プログラム~） 従来の新卒パートナーの倍以上のパフォーマンスを発揮できる優秀な人財に対して年収710万円（2年間）をお約束するものです。将来的にはグループ会社の社長や各事業の責任者など、今後のGMOインターネットグループをリードする「リーダー人財」を目指していただきます。ぜひ興味のある学生の方はご確認ください。 参加者 本OJTには下記メンバーにご参加いただきました。筆者は②の商材システムの開発運用を行うエンジニアとして参加しました。 ①2023年にご入社いただいた710プログラムの新卒パートナー（以下 710新卒と呼称） ②ドメインエキスパート（商材システムの開発運用に従事しているエンジニア） ③ファシリテーター（会議の進行や参加者から質問を引き出す役） 今回のOJTの目的 イベントストーミングの目的としては710新卒の方々にイベントストーミングを通じて商材に関する知識を身に着けてもらうことと、エンジニアと協創するという経験から実際の業務でも円滑に進められるようなリレーションの構築を促すことです。 イベントストーミングとは イベントストーミングは、特定の「ドメイン」、すなわち問題を解決しようとしている特定の領域やビジネスロジックなどを理解し、モデル化するための手法です。ここでの「モデル」とは、現実世界の複雑な部分をシンプルに表現したものです。 今回のイベントストーミングはGMOインターネットグループ内で普段使用しているフォーマットを踏襲して進めていきました。ここでは詳しい説明は省きますが、興味のある方は以下の資料をご確認いただければイメージを掴めるかと思います。 参考資料：イベントストーミング&イベントソーシング入門 イベントストーミングのモデル例 新卒OJT版イベントストーミングの進め方 今回の研修では、主に3つのセグメント（ドメイン事業・ホスティング事業・アクセス事業）の代表的な商材をイベントストーミングの対象として実施しました。 なお、以下に示す例は実際に作成したものとは異なり、今回の執筆に伴い筆者の方で新たに作成したものになっています。ここでは、レンタルサーバーのサービスにフォーカスを当てています。 イベントの洗い出し 最初に想定しうるイベントを洗い出すことを行いました。710新卒の方々はプロダクトの仕様に関してまだ詳しくなかったので、システムの裏側を理解しているドメインエキスパートと対話しながら進めていきました。 洗い出されたイベントの一例 時系列の整理 次に、洗い出したイベントを時系列で整理しました。この段階でイベントが適切なものか、重複はないかなどの精査も併せて進めました。 時系列にまとめられたイベントの一例 懸念点・問題点の洗い出し 時系列で整理していくと、イベント単位で気になることや前後のイベント関係が不十分な箇所が出てきました。その部分をホットスポットとして、メモに記録しておきました。 留意事項をホットスポットで記載 モデルの構造化 イベント以外にも、コマンド、ポリシーなどの概念を加えて、モデルの構築を進めました。この段階で、ホットスポットに対して深掘りし、慎重に解決策を探りました。 構造化されたイベントストーミングの一例 やってみて感じたこと イベントストーミングは特別なスキルセットが必要なく、様々な属性を持つステークホルダーと共通理解を作り上げる手法だと説明されています。確かに今回参加した710新卒の方々はプロダクトの仕様をほとんど知らない状態から始め、自分たちの言葉で仕様を説明できるというレベルにまで到達することができました。 ですが、課題点もいくつか見受けられたので、こちらを共有します。 まず710新卒の方々を苦しめたのはドメインエキスパートが使う言葉でした。システム開発の経験がほとんどない710新卒の方々にとって、サービス、バッチ処理、API、DBなどの用語は混乱の元でした。それを察知して、少しでもイメージしやすいようにという気持ちから、ドメインエキスパートが曖昧な表現をしてしまい、さらなる混乱を生む場面もありました。 仕様を深堀りする、解像度を揃えるという作業には、高いコミュニケーション能力と、物事を構造的に把握する能力がとても重要に感じました。言葉の意味を注意深く察知し、「VMってなんだ？？」「レジストリとレジストラって一緒ですか？？」など積極的に質問している姿はとても印象的でした。 仕様を共有するドメインエキスパート側の姿勢も重要でした。システムの仕様を説明する際、どういった経緯で今の仕様を採用しているのか、身近なエピソードや具体例を交えて説明するなど、抽象と具象のバランス感覚を身につけることで、より深くシステムの概念やプロセスを共有できると感じました。 まとめ 今回筆者はドメインエキスパートとして参加しましたが、710新卒の方々とともに自分たちのサービスを見直す機会はすごく刺激的でした。「どうしてこんな構造なんだろう？」「ここはなぜ共通化できないんですか？」など出来上がったシステムだけを見ている私では気にも留めないようなことが、外から見ると目立ち、改善のヒントになることを新たに発見しました。 イベントストーミングはDDDにおけるモデル設計手法の一つというイメージが強かったのですが、今回のように開発者以外の方ともサービスの現在地点を共有し、新たな視点や知識を創造するための有効な手段になりうると感じました。 ぜひこの記事を読んでいただいた皆さんもイベントストーミングの魅力に触れてみませんか？可能性を探求し、創造の旅へ一歩踏み出しましょう。新たな視点を開拓するチャンスを掴んでください！

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の利用ガイドもあるので是非チェックしてみてください！

こんにちは、GMO稲守です。Adam byGMOを8月にβ版リリースしました。多くの皆様のおかげです。改めてお礼申し上げます。現在は毎週いくつかの新機能や改修などをリリースしています。本記事では現在までのまとめをお届けしたいと思います。Adam by GMO：https://adam.jp/ Adam by GMOについて 本プロジェクトは今年の春頃から本格的な開発、実装が一気に進み、8月末にβ版をリリースしました。ブロックチェーンについては5～6年ほど前から実証実験や研究開発を行っており、コントラクトまわりの開発も計画通りに実装が進んだことを記憶しています。 開発コンセプトは『Eコマースのような、いままでのネットと同じインターフェースでNFT体験ができること』。実装においても、NFTのサイトでは一般的な暗号資産での決済だけでなく、既存のECサイトのような決済手段としてクレジットカードと銀行振込に対応しています。 プロダクトの特徴 複数の決済手段（クレカ、暗号資産、銀行振込）言語対応（日本語+多言語）マルチデバイス対応（PC、タブレット、スマホ）Eコマースライクなインターフェース出品審査を行っている安心なNFTマーケット 技術的な要素 ブロックチェーン Ethereum（Solidity） インフラ、構成管理 AWS、docker、GitHub Webアプリケーション、フロントエンド Node.js、React UI Adobe XD Ethereumを用いており、Openseaなどの海外の著名なマーケットプレイスで採用されているERC721に準拠しています。国産では初めて商用利用の実装ではないかと認識しています。またWeb側も上記の通りモダンな作りとなっています。 ERC721については少し古い記事ですが、こちらの記事などが参考になると思いますので、ご興味がある方はご一読ください。 ERC721 トークンとERC20 の交換（次世代システム研究室ブログ）https://recruit.gmo.jp/engineer/jisedai/blog/trade-erc721-erc20/ 現在のプロダクト状況 本プロジェクトは冒頭で書いた通り非常に短い期間で開発実装を行い、早い時期にローンチが出来ました。ローンチ以降はアクセスいただくお客様の増加とともに、日々の商いもありがたいことに活発になっています。直近では著名なアーティストに多く参画いただいており、今後も続々と新作が発表されるようで私自身も非常に楽しみにしています。 一方でまだNFTに関する国内での利活用事例、商慣習、法解釈など、様々な課題がありますが、NFTの可能性を肌で感じながら皆さんと笑顔になるための活動を引き続きできればと思います。これからも多くの方にNFTを身近に体験いただける環境を提供できるようチーム一丸で開発進捗しています。 さいごに 一緒にAdam byGMOを開発いただける仲間を募集しています。ご興味ある方はぜひ気軽にカジュアル面談はじめ、ご連絡いただけると嬉しいです。 https://recruit.gmo.jp/engineer/jisedai/entry/