技術情報 の記事一覧

皆さん、こんにちは。GMOインターネットグループ株式会社の斉藤です。さて今回は、先日弊社がリリースしたNFTドメイン登録代行サービスCryptoName byGMOにまつわるお話しです。 NFTドメインを使ったログイン NFTドメインは hironobu-saito.wallet のような、いわゆる.comや.jpのような「ドメイン名」と似た文字列です。しかし大きな違いがあり、その実体がブロックチェーン上のトークンとして存在するということです。実際に先ほどのNFTドメインは私が保有していてPolygonチェーン上に存在します。 NFTドメインに付いては以前の記事もご覧ください https://developers.gmo.jp/22413/ 今回はNFTドメインを使ったログイン機能をWebサイトに実装してみたいと思います。NFTドメインというとブロックチェーンアドレスを解決する使い方が有名ですが、他にもいろいろな使い方があります。認証はその一つでもあり、Unstoppable Domainsは、これはWeb3時代の新しいデジタルアイデンティティになるとしています。 さて実装を進める前に、Unstoppable Domainsの管理サイトで今回作成するサイトを登録する必要があります。以下のClient Management Dashboardで登録をしましょう。 Client Management Dashboardhttps://dashboard.auth.unstoppabledomains.com/ 「Connect Wallet」をクリックしてダッシュボードにログインします。この際にMetaMaskなどのウォレットが必要です。ただNFTドメインを保有している必要はありません。 今回はMetaMaskを使うので選択します。 ウォレットの接続を求められるので署名して接続します。 ログインできました！ 続いて「Create Client」をクリックします。 すると今回作成するサイトで実装する際に必要になる設定が表示されます。このclientIDがサイト毎の固有IDとなります。 この下にあるRedirect URLsも設定しておきます。Unstoppable Domainsによる認証は、ブラウザ上でポップアップが表示されてそこで認証を行い、認証後にこのURLにリダイレクトされます。今回の場合はReactでサンプルサイトを作るので「http://localhost:3000/」としておきます。 ここまでで実装の準備は完了です。 実装 実装にはReactとUnstoppable Domainsが開発しているnpmモジュールの@uauth/jsを使います。uauthはUnstoppable Domainsで登録したNFTドメインを使った認証やメタデータの取り扱いを容易にしてくれるライブラリです。 最初にReactアプリを作成して@uauth/jsをインストールします。 $ npx create-react-app ud-login --template typescript $ cd ud-login $ npm i uauth npm WARN deprecated [email protected]: deprecated added 1 package, and audited 170 packages in 1s 74 packages are looking for funding run `npm fund` for details found 0 vulnerabilities src/Apps.tsxを以下のように実装します import React, { useEffect, useState } from 'react'; import './App.css'; import UAuth from '@uauth/js' type User = { sub: string; name?: string; wallet_address?: string; }; function App() { const [user, setUser] = useState<User | null>(null); const uauth = new UAuth({ clientID: [ここに先ほどのダッシュボードにあったclientIDをセットします], redirectUri: "http://localhost:3000", scope: "openid wallet email profile" }); const handleLogin = async () => { try { const authorization = await uauth.loginWithPopup(); setUser({ sub: authorization.idToken.sub, name: authorization.idToken.name, wallet_address: authorization.idToken.wallet_address, }); console.log(authorization); } catch (error) { console.error(error); } } const handleLogout = async () => { setUser(null); const r = await uauth.logout(); console.log(r); console.log('Logged out'); } return ( <div className="App"> <p> {user == null ? (<button onClick={handleLogin}>ログイン</button>) : (<button onClick={handleLogout}>ログアウト</button>) } </p> { user != null ? ( <table> <tbody> <tr> <th>name</th> <td>{user.name}</td> </tr> <tr> <th>wallet address</th> <td>{user.wallet_address}</td> </tr> <tr> <th>sub</th> <td>{user.sub}</td> </tr> </tbody> </table> ) : <div></div> } </div > ); } export default App; これだけでひとまず認証が動作するページが作れます。 22行目にある const authorization = await uauth.loginWithPopup(); これが認証の部分です。実際はポップアップが立ち上がりあとはuauthが全てハンドリングしてくれるのでとても楽です。開発者側は返り値を確認して、必要なメタデータをサイト上に表示してあげるだけです。 さてそれでは出来上がったサイトを見てみましょう。npm startして http://localhost:3000/ をブラウザで開きます。 npm start 何もない殺風景なページですが(笑)、ログインボタンを押してみましょう。 ログインページが表示されました（画像左）。サイトの訪問者は保有しているNFTドメインを入力してログインを行います。試しに私自身が訪問者として保有しているhironobu-saito.walletを入力してみます。 ここでログイン後にサイト側に渡される情報を確認できます（画像中）。ここでどんな情報が渡されるかはサイト制作者側が指定できます。Apps.tsxの14行目付近にある scope で指定します。 const uauth = new UAuth({ clientID: [ここに先ほどのダッシュボードにあったclientIDをセットします], redirectUri: "http://localhost:3000", scope: "openid wallet email profile" }); この確認が終わったら、ログインに使うウォレットを選択ます。Unstoppable DomainsのアプリやMetaMask等を選択できます。今回はUnstoppable Domainsのアプリを使ってログインしてみましょう。QRコードが表示されるので（画像右）これをスマートフォンのUnstoppable Dommainsアプリで読み込みます。 アプリから署名を行うと無事にログインが完了して、以下のようにNFTドメインに関連したメタデータが表示されます。 今回はメタデータを表示するだけの簡単なサイトでしたが、ここからは一般的なWebアプリケーションと同様にユーザー毎に違うページを表示したりと言った実装を行っていくことになるでしょう。 おわりに NFTドメインの利用方法の一つとして、認証を行う実装をご紹介しました。 皆様もぜひCryptoName byGMOのサイトをご覧頂き、NFTドメインについて知って頂ければ幸いです。 ブロックチェーン上の新しいドメイン - NFTドメイン新登場

2022年9月24日（土）～25日（日）に「PHPカンファレンス2022」が大田区産業プラザにて開催されました。GMOインターネットグループはスペシャルスポンサーとして協賛・登壇しました！今回は、スポンサーセッション「17年続くWebサービスを改善する　～新卒2年目からみるカラーミーショップ～」の書き起こし記事となります。ぜひご覧ください。イベント告知：https://developers.gmo.jp/23482/ 登壇者（敬称略） GMOペパボ株式会社　EC事業部ECグループCCXチーム中山 慶祐（やんまー）GMOペパボ株式会社　技術部プラットフォームグループ新宮 隆太（ほみるん） 前半「切り取り方を工夫してアプリケーションを漸進的に改善する」 https://developers.gmo.jp/24741/ 後半「カラーミーショップの改善におけるSRE活動について」 https://speakerdeck.com/homirun/karamisiyotupunogai-shan-niokerusrehuo-dong-nituite GMOペパボ株式会社技術部プラットフォームグループでサイトリライアビリティエンジニアをやっております、新宮隆太と申します。弊社ではあだ名で呼び合う文化があり、社内では"ほみるん"と呼ばれています。このあだ名は、むかし乱数で生成したものを使っています。 社内では、写真のようなサーバーを担ぐSlackアイコンを使っていることから、他のチームからはとりあえず「サーバーを担ぐやつ」として認知され始めました。最近のトピックは、曲がりなりにもサイトリライアビリティエンジニアをやっているわけですが、自宅サーバーで運用しているブログを落としてしまいました。非常に反省しております。Twitterは @h0mirun_deux のIDでやっておりますのでよければフォローよろしくお願いいたします。 本日のアジェンダです。 まず、一般的なSREについてのお話をさせていただき、その後カラーミーショップのSREチームの紹介をさせていただきます。そして、SREチームが行っているSRE活動と、その改善活動について実例を踏まえつつお話しさせていただければと思います。 SREとは まずSREとは何なのかという話をします。SREとはSite Reliability Engineeringの略です。日本語にするとサイト信頼性エンジニアリングですね。実はですね、このSREという略はもうひとつの意味でも使われています。それはSite Reliability Engineerです。先ほどはエンジニアリング、今回はエンジニア、どっちもSREなので困りましたね…。スライドや口頭とかでもSREというとエンジニアリングかエンジニアどっちを指すのか分からなくなりそうです。でも、リライアビリティという言葉はもうさっきからずっと言っているのですけどめちゃくちゃ言いにくいですよね。なので、できればSREと略して喋りたいわけです。 そういうことで今回はSREという略語に関しては、Site Reliability Engineering、つまり手法を指すということにしたいと思います。エンジニアの方は略さずサイトリライアビリティエンジニアと書いたり言ったりしたいと思います。 ということで、本題に戻りまして、SREの話をしていきたいと思います。 SREとは、サービスの信頼性を維持向上することを目的としたアプローチのひとつで、信頼性に関する指標などをもとにファクトベースで意思決定を行います。 今度はエンジニアの方、サイトリライアビリティエンジニアは、その名の通りサイトリライアビリティエンジニアリングを実践する人たちのことを指しています。この人たちはサービスの信頼性に関するすべてのことに関わります。 さて、SREの簡単な説明が終わったところで、先ほどから信頼性、信頼性と言っていたわけですが、信頼性とは何なんだという話について軽く触れていきたいと思います。 信頼性は、サービスがどれだけユーザーの期待どおりに利用できる状態かどうかを示す言葉です。よく信頼性が高いという言葉を耳にすると思います。これは、ユーザーが期待どおりに利用できる時間が長いということになります。例えば満足な速度でレスポンスが返ってくるだとか、サービスが障害で止まって使えなくなることが少ないだとか、そういうことが組み合わさって信頼性が高くなるわけです。 さて、ではその信頼性を維持向上することで何が嬉しいのか見ていきたいと思います。 一番大きいのは、ユーザー体験の維持・向上だと思います。極端な例ですが、リリースのためにサービスが不安定になったり、レイテンシが悪化するといった状態だったとします。するとユーザーはより快適な別のサービスに乗り換えてしまうなど、ユーザーが離れていってしまい、せっかく素晴らしい機能をリリースしたのにそもそも使ってくれるユーザーがいなくなってしまうわけです。こういった機会損失を防ぐことができるのが信頼性の維持・向上です。 信頼性の維持・向上のためには、まず現状のサービスの状態を知ることと、目標の設定が不可欠です。ということで、次は信頼性の指標となるSLI/SLOについて簡単に説明していこうと思います。 まずSLIから。SLIは、Service Level Indicatorの略で、サービスの稼働状況を示したものです。具体例を出すと、可用性であればリクエストの成功と失敗の割合であるエラーレートであったり、決済の成功率、レスポンスの応答速度であればn秒以内に処理を完了したリクエストの割合とかがSLIとして設定できます。 SLOは、Service Level Objectiveの略で、サービスの稼働目標を数値化したものです。先ほど説明したSLIがどのような状態になっているとよいのかを定義します。先ほどと同じような例を出していくと、可用性では30日間で正常に処理されたリクエストが99.9％だとか、30日間で決済成功率が99.99％、いわゆるフォーナインといわれるものですね、レスポンスの速度では、30日間でn秒以内に処理が完了したリクエストが99.95％というものがSLOとして設定できます。 では、具体的に信頼性の維持向上のためにサイトリライアビリティエンジニアは何をやるのでしょうか。 実際には、以下のようなことをやっております。先ほど話したSLI/SLOの運用であったり、メトリクスをもとにしたパフォーマンスチューニング、運用の手順化・構造化、構造化したものをソフトウェア・エンジニアリングを用いて自動化し効率を図る、など様々なことをやっております。 今回の発表では、上記の2つについて、より焦点を当てて話しさせていただければなと思っています。 カラーミーショップのSREチーム カラーミーショップでSRE活動を行っているチームについて簡単にお話しさせていただきます。 GMOペパボでは、サービスごとに事業部という形で分かれています。カラーミーショップは赤枠で囲んだEC事業部というところで開発されています。ですが、カラーミーショップのSREチームはEC事業部ではなく、サービス横断の横串組織である技術部の中にあるプラットフォームグループというところで主に担当しています。 カラーミーショップのSREチームを担当しているプラットフォームグループは、サービスから独立したSREチームとなっており、以下のようなことを行っております。SLI/SLOの運用、ソフトウェア・エンジニアリングを用いたサービス運用効率化、メトリクスをもとにしたパフォーマンスチューニング、といった先ほどのサイトリライアビリティエンジニアのやることで紹介したことはもちろん、インフラまわりの整備、オンコール対応なども行っています。 カラーミーショップにおけるSRE活動 ではここから、本題である実際にカラーミーショップで行っているSRE活動について説明していきたいと思います。 先ほど説明したSLI/SLOは、設定するだけでは意味をなしません。SLI/SLOを観測することが信頼性維持・向上に向けての第一歩となります。カラーミーショップではSLI/SLOを観測するために、以下のような取り組みを実施しています。 ではひとつずつ説明していきたいと思います。 まず1つ目がSLIの監視と通知です。 カラーミーショップではエンドポイントのレイテンシをSLIの1つとして設定しています。そこで我々はSLIを監視ツールで監視をし、直近の数分のレイテンシが閾値を超えていたことを通知できるようにしました。これにより、いま自分たちのサービスの信頼性が低下しているかもしれないということに即刻気が付くことができるようになります。 次にダッシュボードについてです。 ダッシュボードはグラフ化されることで視覚的に分かりやすくなり、SLIの傾向をつかむのに最適です。全体的に少しずつSLIが悪化もしくは改善している傾向が分かったり、特定のタイミング、特定の時刻にSLIが悪化していることが分かったりします。この下に貼ってある画像の緑と赤の境界線が設定されている閾値で、ここを超えないように日々SRE活動を実施しています。 SLI/SLOレビュー会では、カラーミーショップ担当エンジニアとSREチームが参加し、現在のサービスの状態の認識共有を行う場として設定されています。具体的にこの会では、次のようなことをします。まず直近1週間のSLIを確認し、SREチームとカラーミーショップ担当エンジニアとの間で、現状のサービスの信頼性の状態を確認します。その後、SREチームが事前にこのままではSLIを違反してしまいそうな項目について調査をしておき、この場で共有します。最後に、次のSLI/SLOレビュー会までに実施する改善策、いわゆるアクションアイテムを設定します。この会を毎週毎週繰り返すことで、サービスの信頼性をより向上させていっています。 次に、エラーバジェットについてお話しします。 エラーバジェットは、サービスの信頼性がどの程度損なわれていても許容されるかを示す値です。例えば、SLOで30日間に来るリクエストのうち、99.99％は正しいリクエストを返すというものを設定した場合、30日間で約4.3分間はエラーを返してもよいということになります。 さて、エラーバジェットがだいたいどんなものか分かったところで、これをどう信頼性の維持・向上の活動に含めていくかです。カラーミーショップでは、エラーバジェットをすべて使い切った時に、カラーミーショップ担当エンジニアと、サイトリライアビリティエンジニアがとる行動についてルールを定めています。それが、エラーバジェットポリシーです。カラーミーショップでは、ちょうど運用を始める段階です。エラーバジェットポリシーは、サービスの機能開発と信頼性のバランスをとるという目的で設定されています。また、ここにはエラーバジェットポリシーはSLOの未達に対する罰としては運用しないということも明記されています。これは、このポリシーが信頼性回復を目的としてカラーミーショップ担当エンジニアとサイトリライアビリティエンジニアが協力するために設定されているのであって、対立するためには設定されていないことを重要視しているからです。 もう少し具体的にカラーミーショップのエラーバジェットポリシーについて見ていきます。 もし、エラーバジェットを使い切ってしまったら、まず信頼性回復のためのタスクが最優先になります。そのうえで、もしアプリケーションが起因でエラーバジェットを使い切ってしまった場合は、SREチームとカラーミーショップ担当エンジニアそれぞれ1人ずつ、信頼性回復のためのタスクに専任でアサインします。もしインフラ起因でエラーバジェットを使い切ってしまった場合は、SREチームから1人を専任でアサインします。 次に改善もくもく会についてお話しします。 改善もくもく会は、カラーミーショップ担当エンジニアとSREチーム合同で一緒にサービス改善を実施する会です。 もう少し具体的に話すと、この会では主に3つのことを行っています。まず、SREチームが改善できそうなエンドポイントの洗い出しを実施してカラーミーショップ担当エンジニアに共有します。カラーミーショップ担当エンジニアはSREチームが洗い出したエンドポイントに関する実装についてSREチームに説明をします。ここまでで出た情報をもとに、実際に手を動かしてサービス改善を実施していきます。 ここまでSLI/SLOの観測や改善もくもく会などのお話をしてきました。それらから生まれた改善活動として、実際に次のようなことを実施しています。 インフラの最適化としては、需要の予測とキャパシティプランニングや、Webサーバーの設定値の変更などのチューニング等、アプリケーションの改修としては、クエリチューニング等を実施しています。 SLI/SLOを用いた改善活動の事例紹介 それでは、先ほどの話を踏まえて実際に行った改善活動の事例を紹介します。 具体的な例の前に、アーキテクチャの話を少しだけ前提知識としてさせてください。 カラーミーショップの一部はGMOペパボのプライベートクラウド基盤であるNyah上でVMとして稼働しています。もちろんコンテナ化されている部分もあります。また先ほど言ったNyahにはGMOペパボが提供している別のサービスも含めて共存しています。これらを頭の片隅に置いた状態でこれから話す事例を聞いていただければと思います。 はじめに、インフラ最適化による改善活動を2例紹介します。 インフラの最適化による改善活動の例　～その１～ 1つ目は、エンドポイントレイテンシが悪化して閾値を超えてしまった例についてお話しします。 我々SREチームは、以下のような手順でこの問題を改善しました。 まず1つ目、まず我々はSLIダッシュボードから何か問題がありそうだぞとなったあと、もともと収集しているメトリクスを確認し、一部のインスタンスのみのレスポンスが悪化していることが分かりました。さらに、別のメトリクスを見ていくと、CPUstealの値が増加していることが判明しました。ここで出てきたCPUstealとは、ハイパーバイザー型VMにおいて仮想CPUが実CPUを待っている時間のことで、同じホストにいる別VMと実CPUのCPU 時間を奪い合うことで発生します。カラーミーショップは先ほど説明した通りVM上で動いているため、このような問題が発生していました。 さて、CPUstealの値が増えていることから我々はノイジーネイバー問題を疑い、インスタンスのライブマイグレーションを実施しました。ノイジーネイバーとは、日本語だと「うるさい隣人」という意味です。同じホストに存在する他のVMがホストのマシンリソースを大量に利用することで十分なリソースが利用できない状態のことです。なので、うるさい隣人のいないホストへ移動すべく、ライブマイグレーションという、仮想マシンを別のホストに移動するという対応をとりました。さらに、再度同じような問題が起こった時に、毎回手動で同じような対応をするのは大変なので、それらを自動化する仕組みを用意しました。こちらに関しては、テックブログに詳しく書いておりますのでぜひ見てみてください。 Pepabo Tech Portal「クラウドのノイジーネイバー問題を解決する動的スケジューラー」https://tech.pepabo.com/2022/04/18/instance-migrator/ インフラの最適化による改善活動の例　～その２～ 2つ目はアプリケーションのデプロイを行うためにエラーレートが上がっていた例を紹介します。 この例では、以下のような手順でこの問題を改善しました。まずAPMやログを調査したところ、デプロイ時のフローとして実施されているPHP-FPMのリスタートのタイミングで502エラーが頻発していることが判明しました。その後、開発環境で確認したところ、PHP-FPMはデフォルトでGraceful Restartをするのを期待していましたが、実はそうではないことが判明しました。 ここで、期待していた動作であるGraceful Restartについて軽く説明します。Graceful Restartとは、プロセスを再起動する際に古い子プロセスへ新しいリクエストを受け付けない状態にして、すでに受け付けているリクエストを処理し、新しい子プロセスと入れ替わる動作のことをいいます。もしGracefulでないRestartをすると、すでに受け付けているリクエストの処理は終わらせずに、そのままバツンと切ってしまって新しい子プロセスと入れ替わります。そうすると今回のようにプロセス再起動のタイミングでエラーが出るようになってしまいます。我々はGraceful Restartを実現するために、PHP-FPMの設定のprocess _control_timeoutの値を、デフォルト値である0から直近のレスポンスタイムの95%タイルをもとに設定しました。このprocess_control_timeoutという値は、子プロセスがマスターからのシグナルを待つ最大時間を設定する値で、これを変更することによりGraceful Restartのようなことを実現することができました。これによって、デプロイのタイミングでエラーレートが上昇することがなくなりました。 先ほどまでの例は、インフラの最適化による改善活動のお話でしたが、次はアプリケーション開発による改善の例を紹介しようと思います。 アプリケーション改修による改善活動の例 この例ではSLO違反の調査から特定エンドポイントの処理が意図したよりも長かったことが判明した例を紹介します。 まずメトリクスより複数のインスタンスにおいてレイテンシが悪化していることが分かりました。複数のインスタンスで出ていることから、先ほどの例で出てきたノイジーネイバーが原因である線は薄くなりました。APMから特定エンドポイントの処理の中で投げられているクエリを確認したところ、N+1クエリが存在していることが分かりました。こちらはアプリケーション側の修正であることから、変更した部分の影響範囲の確認も含めて、カラーミーショップ担当エンジニアにレビューをもらったうえでクエリを修正しました。 これらの行動により、該当エンドポイントのレイテンシが改善されたことが確認されました。 おわりに まとめに入ると思いきや、タイトルにも「新卒2年目から見る」という言葉が付いているので、SREチームに配属されて丸1年経った今と配属当初で自分の中で変わったことを少しだけ喋らせていただこうかなと思います。 まず1つ目が、SLI/SLOをベースとして物事を考えられるようになりました。 自分はそもそも配属時はSREのことをよく理解していなかったので、最初はできなかった行動でした。今はSREの先にお客様がいるということを考えながら行動することで、すべての行動やタスクの優先順位付けに良い影響を及ぼしているのではないかというふうに考えています。 2つ目に、何事も手順化するようになりました。タスクをこなしていくうちによく分からないことが出てくると、とりあえずチャットツールの検索を使って過去に同じようなはまり方をしている人を探したり、GitHubで似たようなことを調べたりします。ただ何度も同じような検索、調べたりする行動をすると時間がもったいないので、二度とイチから調べなくてもよいように、ドキュメント化するようになりました。 自分で言うのもなんですが、1年前に比べるとできることが広がったなと感じています。 というわけで、自分の感想はここまでにしたいと思います。 最後に、今回お話ししたことは以下の通りです。 一般的なSREに関する話として、SREとはサービスの信頼性を維持・向上することを目的としたアプローチのことを指す、というお話をしました。 次に、カラーミーショップのSRE活動について、SLI/SLOの観測を監視ダッシュボード、レビュー会などの手段を用いて実施しているということ、またエラーバジェット運用を開始したことなどをお話ししました。 最後にカラーミーショップにおけるSLI/SLOを用いた改善活動についてインフラからのアプローチとアプリケーションからのアプローチ、合計3例をお話しさせていただきました。 以上で発表を終わらせていただきます。ご清聴ありがとうございました。 アーカイブ映像 https://www.youtube.com/embed/lz4IVcds9Fo PHP Conference Japan 2022: 17年続くWebサービ… / やんまー、ほみるん | GMOペパボ – YouTube

2022年9月24日（土）～25日（日）に「PHPカンファレンス2022」が大田区産業プラザにて開催されました。GMOインターネットグループはスペシャルスポンサーとして協賛・登壇しました！今回は、スポンサーセッション「17年続くWebサービスを改善する　～新卒2年目からみるカラーミーショップ～」の書き起こし記事となります。ぜひご覧ください。イベント告知：https://developers.gmo.jp/23482/ 登壇者（敬称略） GMOペパボ株式会社　EC事業部ECグループCCXチーム中山 慶祐（やんまー）GMOペパボ株式会社　技術部プラットフォームグループ新宮 隆太（ほみるん） 冒頭 やんまー本日は2人で発表させていただきます。まず、私がGMOペパボ株式会社の中山慶祐と申します。社内では"やんまー"と呼ばれております。 GMOペパボ株式会社の新宮隆太と申します。社内で"ほみるん"と呼ばれております。どうぞよろしくお願いいたします。ほみるん やんまー本日は、前半と後半の2つに分けて、2つのお話をさせていただきます。前半は、私から「切り取り方を工夫してWebアプリケーションを漸進的に改善する」について30分弱ほどお話しさせていただきます。 後半は、私から「カラーミーショップの改善におけるSRE活動について」を30分お話しさせていただきます。ほみるん カラーミーショップについて （以下、やんまーより）発表の前に、タイトルにありましたカラーミーショップについてご説明させてください。 カラーミーショップは、弊社GMOペパボ株式会社が運営するネットショップ作成サービスです。無料で始められ、ECサイトの流通規模が大きくなっても使い続けられるECプラットフォームとなっています。2005年にサービスを開始し、今年で18年目になります。昨年末時点で約45,000ショップのお客様にお使いいただき、年間の流通総額は2,070億円となっております。 このカラーミーショップは、主に2つの開発組織に属する複数のチームで開発運用しております。1つはカラーミーショップを直接運営するEC事業部に所属する複数の開発チームです。私はこちらに所属しております。もう1つはGMOペパボ株式会社の全社横断組織である技術部に属するチームです。ほみるんは、この中のインフラに専門性を持ったサイトリライアビリティエンジニアが所属するチームに属しております。また、システム構成はデータベースを中心とした複数のサブシステムで構成されています。これら全体のWebアプリケーション群からなるECプラットフォームがカラーミーショップです。PHPで開発されているサブシステムも多数ありまして、私も普段PHPを書いて開発しております。この後の発表でカラーミーショップの具体的なシステムの問題や、課題解決を紹介させていただくので、カラーミーショップの前提について少しお話しさせていただきました。 このようなバックグラウンドで今日はお話を進めさせていただきます。どうぞよろしくお願いいたします。 前置きは以上といたしまして、本日の前半のトピックにまいります。 【前半】「切り取り方を工夫してアプリケーションを漸進的に改善する」 https://speakerdeck.com/yammerjp/incremental-improvement-by-devising-application-change-boundaries まず、漸進的とは何か、なぜ漸進的なのかについて説明します。 そして、そのあと漸進的な改善に必要なアプリケーションの一部を切り取る工夫について、2つの事例を示します。発表の内容が何か皆様のお役に立てれば幸いに思っております。 ここで改めて自己紹介をさせていただきます。 私は中山慶祐と申します。GMOペパボ株式会社のカラーミーショップの開発をしているWebアプリケーションエンジニアです。弊社に入社したのは昨年の4月で、研修のあとカラーミーショップの配属になり、今日でちょうど1年1ヶ月経ちます。このような物理の会場での登壇は実は初めてでして、ちょっと緊張してさっきもあたふたしてしまったのですけれども、ここからは堂々と進めさせていただければなというふうに思っております。 GMOペパボ株式会社では、お互いをあだ名で呼び合う文化があり、私は”やんまー”と呼ばれています。またインターネット上では「@yammerjp」というIDで活動しております。趣味はdotfilesの管理で、設定ファイルを日々コツコツ管理することをしながら毎日を過ごしています。 ということで発表に入らせていただきます。 なぜ漸進的なのか 今日の私の前半のタイトルは、「切り取り方を工夫してアプリケーションを漸進的に改善する」でした。 ところでこの漸進的という言葉は何を指す言葉でしょうか？ 辞書によると、「目的、理想などを急激ではなく、順を追ってだんだんと実現しようとする傾向にあること」とあります。 「順を追って」「だんだんと」改善する、それが漸進的な改善です。 ではなぜ漸進的なのでしょうか？これを考えるために少し戻ってみます。 今日はタイトルがもう1つありまして、「新卒2年目からみるカラーミーショップ」となっていました。ということで新卒で配属された頃のことを思い出しています。 今から約1年前、カラーミーショップに配属された当初のことです。 私が感じていたこととしては、「でかい」ということでした。 カラーミーショップは冒頭で示しましたように多数のサブシステムで構成されており、コードはそれぞれのリポジトリで管理されています。でかい、すなわち大きいというのは、コードベースが大きいという意味です。これはカラーミーショップが17年開発運用の続くECプラットフォームであるというだけでなく、私が新卒で入ったので、他のシステムを知らなかったという側面ももちろんあると思います。 複数のサブシステムが協調して動作しており、アプリケーションの全容をすぐに把握するのは難しい…と、配属直後は想像していました。さらに、開発の際に変更を加えるのは大変ではないだろうか、というふうにも思っていました。確かに大きなコードベースに対して大きな変更を加えることは影響範囲も大きくもちろん大変でしょう。これはカラーミーショップに限らずどんなアプリケーションでも当てはまることだと思います。しかし一方で、多くの場合は一瞬ですべてを作り替えるなどということはありません。すべてを変更するのではなく、改修に伴う影響範囲を明らかにして、必要な一部分だけを変更することになります。 そうです。一度に変更するのは一部分だけです。 もし、複数の部分を変えたいならば、一度に一部分のみを変更することを繰り返すことになります。一度に加える変更が大き過ぎれば、影響範囲が大きくなり、リリースに伴う障害発生のリスクも高まります。特に、運用年数が長く、利用者が多いサービスでは、これは顕著でしょう。リスクを避けるには、大きな変更をするにしても、小さな変更の積み重ねになるでしょう。 このような積み重ねは、「順を追って」「だんだんと」変化するものになります。「順を追って」「だんだんと」。これはつまり漸進的な改善です。漸進的に進めることで、影響範囲をコントロールしながら改善を進めることが可能になります。私が一番最初に感じた「でかい」という感想は、ある側面では正しいのですが、一方で開発を進める時にはそのでかいアプリケーションの一部をいかにうまく切り取るかが大事になってくると考えます。実際私も今日までの1年1ヶ月で一部を切り取ることを繰り返してきました。合計200以上のプルリクエストを作ってマージすることになりましたが、これは私に限らずどのエンジニアも一部を切り取って改善を続けています。 というわけで、今日は漸進的な改善についてお話しさせていただきたいと思います。 先ほど、一部を切り取るという風に話しましたけれども、ではこの一部というのはどのようにして決めるのでしょうか？これは開発者が「今回はここを一部とする」と範囲を決めることになります。その切り取り方が大きくなりすぎないよう、また冗長にならないようアプリケーションの一部をうまく切り取るための工夫がカラーミーショップでは実装され、利用されています。 ここではそのアプリケーションの一部を切り取る工夫を2つ紹介させていただきます。 一部を切り取る工夫：モダンWebフロントエンド開発環境の漸進的な導入 事例の1つ目は、「モダンWebフロントエンド環境の漸進的な導入」です。 カラーミーショップは複数のサブシステムからなりますが、そのうち管理画面サブシステムのWebフロントエンド開発環境に課題を抱えていました。状態を変化させるための手続き的なUIが複雑化し、メンテナンスコストが肥大化すること。HTML・CSS・JavaScriptが画面ごとにバラバラに配置されてそれぞれ記述が独自の基準でされているので管理がしづらいということ。また、コードベースが大きく一括でこれらの環境で手を加えるのが難しいこと、などです。 これらの課題に対して宣言的なUIで記述できるようにしたい、もしくは統一的な記述が期待できるフレームワークに則りたい、もしくは大きなコードベースに対しても影響範囲を限定できるよう、漸進的に導入したいといった要求がありました。合わせて、新しい技術の導入にあたっては、開発者に使いやすいインターフェースが求められていました。これは一部の限られた人間のみが開発するわけではないからです。複数のサブシステムの中でも管理画面サブシステムは事業部内の多くのエンジニアが変更を加えることのある場所であり、デザイナーによるUIの開発も一般的に行われています。ここに示した4つの要求－宣言的なUI、フレームワークに則って統一された記述、漸進的な導入、開発者が使いやすいインタフェース、これらすべての要求を満たす方法としてVue.jsとCustom Elementsを用いた方式がとられることになりました。簡単に導入した技術要素について説明させていただきます。 Vue.jsは宣言的なUI記述が可能なJavaScriptフレームワークとして広く知られているものと思います。カラーミーショップにおいても複数のサブシステムで利用されており、事業部内ですでに広く浸透していたことから採用されました。 もうひとつはCustom Elementsです。Custom ElementsはHTMLにおいて独自の要素を定義できる仕様のことです。JavaScriptを用いて、その独自の要素に対する振る舞いを実装することになります。 例えば、あなたが<H1>要素の代わりに<my-element>要素を用意したい、というふうに思ったとしましょう。この時、まずJavaScriptで<my-element>要素を定義し、独自の要素とその振る舞いを定めます。続いて、HTMLのコード内に<my-element>要素を記述し、これを描画します。このような手順を踏むことで、独自の要素を用意できました。 このような前提のうえで、カラーミーショップではVue.jsのコンポーネントをCustom Elementsとして利用できるよう、ビルドする方式がとられました。Vue CLIのWeb Componentモードというものを用いると、Vue.jsのコンポーネントそれぞれをCustom Elementsとして利用できるようにビルドすることが可能です。 このVue CLIのWeb Componentモードについて少しご説明いたします。 Vue CLIのデフォルトのビルドターゲットである Appモードというものは、Vue.jsの単一の<div>要素にVue.jsの親コンポーネントをマウントするような index.htmlが一緒に出力されます。スライドの左のように、画面全体であったりとか、場合によっては画面の一部分がVue.jsで描画されるようになるということです。 一方でWeb ComponentモードではVue.jsのコンポーネントごとにCustom Elementsが定義され、HTML上に独自のタグを記述して利用することになります。独自のタグが書かれた任意の個数の任意の箇所がVue.jsで描画されるようになるということです。スライドの右に示すように、例えば<my-element-hoge>要素や、<my-element-fuga>要素などのコンポーネントが定義されているとして、これらがHTMLの中の好きな場所に出現させることができるというふうになっています。 このような方式をとることで、当初の要求をすべて満たすことができます。宣言的なUIと、フレームワークに則った記述は、Vue.jsを導入することで実現されました。漸進的な導入と使いやすいインタフェースは、Custom Elementsへのビルドで実現されました。 ここでは後者2つに焦点を当ててみます。 漸進的な導入は、Vue.jsのコンポーネントのマウントする個数や箇所を任意に決められることで柔軟に変えられるという特性をもって実現しています。 例えば、スライドに示したスクリーンショットは管理画面サブシステムのとある2つの画面です。画面に表示された要素の詳細は特に重要ではありません。ここでは赤い部分がVue.jsをCustom Elementsにビルドしたコンポーネントが含まれている箇所というふうに認識していただければよろしいかと思います。どちらの画面も複数の箇所に利用されており、また画面ごとに利用されている範囲が異なるので、これらがコントロールされているというようなことが分かるかと思います。漸進的な導入は、このようにして実現されています。 もうひとつの使いやすいインタフェースについては、独自のタグを記述するのみで実現できることからこれを満たしていると考えます。 画面の開発をする際に、Custom Elementsのビルドされたタグを埋め込むことになります。普段の開発では HTMLのコード内にタグを記述するというようなことは変わりません。例えば、管理画面サブシステムではPHPのあるテンプレートエンジンを用いているので、そのテンプレートファイル内にタグを記述して画面を構成するというような構成は従来と変わっていません。変わるのは、一般的な要素ではなく、独自のタグを記述することです。ここで<my-element>要素を記述しているように、例えば<button>要素ではなく<colorme-shop-xxx-button>要素を記述するといったように、独自のタグを記述するということだけでコンポーネントを埋め込むことになります。このようなコンポーネントは、事前に用意することが必要になる一方で、利用する際はこのタグを記述するだけでリッチなUIを実現できます。 改めて利点を示します。詳細を述べた2点を含め、Custom Elementsをビルドすることは管理画面サブシステムに多くのメリットをもたらしました。宣言的なUI、フレームワークに則って統一された記述、漸進的な導入、開発者が使いやすいインタフェースです。 ここまでのまとめです。モダンWebフロントエンド環境の漸進的な導入としてCustom ElementsとしてビルドできるようにビルドされたVue.jsコンポーネントを用いて既存画面の一部置き換えや新規実装というものを進めています。新たなUIフレームワークを導入しても、画面全体の再実装が必要になることを避け、必要に応じて柔軟に組み合わせることができるようになっています。このような方法を通してWebフロントエンド領域において変更の粒度を小さくし、切り出しやすい一部を柔軟に決めて、漸進的に改善できる方法が提供されています。 ここまでが、Webフロントエンドの領域における漸進的な改善でした。 一部を切り取る工夫：Feature Toggleの活用と管理 PHPカンファレンスですので、バックエンドに関心を強く持たれる方が多いかと思うのでもしかしたら少し退屈だったかもしれませんが、ここからはWebのバックエンド領域も含めたお話になってまいります。 ここからは、先ほどは少し視点を変えて、アプリケーションの一部を切り出す工夫のもう1つを紹介させていただきます。それはFeature Toggleの活用と管理です。 まずはFeature Toggleについてです。 トグルと聞くと、電気のスイッチを想像されるのではないかと思います。ここではFeature Toggleを「特定の機能の有効や無効といった状態を、コード内の条件で切り替える手法」とさせていただきます。実装が存在してもトグルを有効化していないと機能が動作しないように制御することが可能です。 スライドに示したコードは、単純な実装例です。まず、真偽値を持つ変数isEnabledNewFeatureに、falseを代入しています。次の行は同じ変数isEnabledNewFeatureにtrueを代入している行ですが、これはコメントアウトされています。 続いて、isEnabledNewFeatureがtrueならば新しい機能、falseならば既存の機能を実行するというような分岐が記述されています。このようなコードを埋め込むことで、開発を行ったあと機能を無効にしたまま本番環境へリリースできるようになります。 ここでの例は大変原始的で単純な例ですが、もう少し高度な例として、if-elseをこの処理と切り離すために抽象化層を導入したり、設定ファイルに真偽値を分離したり、開発環境でだけ有効になるようにしたりといった仕組みを導入するという実装も考えられます。 いくつかの実装は考えられますが、どの実装もFeature Toggleは開発中の機能を無効化した状態でリリースできるというメリットがあります。機能がユーザーから利用できない状態になるので、全容が完成していなくとも完成した一部分を、レビューを経てリリースできるようになります。これはアプリケーションに対する変更の粒度を小さくし、既存機能への影響がないことが常に確認された状態を維持したまま開発を進められることになります。つまり、その一部を切り取ることができるようになります。 ところで、先ほどのコードにはいくつか課題がありますが、1つにはトグルの変更にデプロイが必須というようなことが挙げられます。 スライドに示したのは、先ほどと同じコード例です。 ここでは、isEnabledNewFeatureにtrueを代入している部分がコメントアウトされていますけれども、この行と上のfalseが代入されている行を編集してレビューしてCIを通してデプロイするといった流れを踏むことになりますけれども、これはどうしても多少の時間がかかってしまいます。 デプロイをせずともトグルを変更できるようにして、リリースやその切り戻しを素早く行いたいといった需要があります。 このような需要への対応として、Feature Toggleの管理を外部化することが挙げられます。トグルの有効もしくは無効といった状態をアプリケーションのコードの外で保持するような手法のことです。例えば、トグルの状態をデータベースに保存しておき、開発者が変更可能にします。また、アプリケーションはトグルの変更を取得して分岐するようにします。 ここでもまた、少しコードを示させていただきます。画面に示した例では、FeatureToggleクラスというものがすでに定義されていて、このFeatureToggleクラスのisEnabledメソッドが外部から状態を取得して戻り値を返しているということを前提にしたコード例です。このisEnabledメソッドの真偽値がtrueならば新しい機能を、falseならば既存の機能を実行するというコード例です。 このような方式をとる時にはこのFeatureToggleクラスのisEnabledメソッドが通信する先として、例えばアプリケーションのデータベースを使ってそこにトグルの情報を入れておく、そのトグルを変更する場合には管理画面を別に用意しておく、というような自作する方法が考えられます。他にはこのようなFeature Toggleの管理を行えるようなサービスというものがあり、これを使うという方法もあります。 このFeature Toggleの管理をするサービスの1つに、Unleashが挙げられます。 カラーミーショップを含むGMOペパボでは、Unleashを利用してFeature Toggleの管理の外部化を実現しています。Unleashはマネージドサービスとして利用することも、自前でホストすることも可能です。スライドに示しているのはUnleashの管理画面のデモページの例です。 このUnleashは、スライドに示している管理画面を含む管理を行うアプリケーションと、もう1つはFeature Toggleの状態を取得するSDKがあり、これらが合わせて提供されています。トグルの状態はUnleashの管理画面から操作可能です。アプリケーションの実装時には、SDKを使い、トグルの状態を取得できるようにしておきます。 なお、SDKにはPHP向けのものもありまして、Composerを用いてPHPアプリケーションに導入することも可能です。 このようなFeature Toggleの管理を外部化することで、デプロイをせずともトグルの変更が可能になります。リリースの時点では管理画面からトグルを変更するだけで済みますし、切り戻しも同様です。これはデプロイとリリースを切り離すということになります。これはFeature Toggleの管理を外部化することのメリットとなります。もう1つ大きなメリットとして、Unleashに付属している便利な機能として、条件を満たした一部の場合のみトグルを有効化することができます。例えば、ユーザーのアカウントIDを渡して本番環境で特定のアカウントのみをトグル有効にしたり、リクエストごとやセッションごと、アカウントごとに任意の割合で有効にしたりするということです。一部のユーザーのみのトグルを変更するというようなことは、新しい機能を開発者や社内のユーザーのみが利用できるようになるということです。また、一定の割合でリリースできるようになるということは、すなわちカナリアリリースとしてアプリケーションのメトリクスや利用者の反応を見ながら提供の割合をコントロールするようなことができるようになります。つまり、アプリケーションの実装ではなく、ここではリリースの範囲を一部に切り取ることが可能になります。これは漸進的なリリースといえると思います。 ここまでのまとめです。 ここまではFeature Toggleについて紹介しました。Feature Toggleを用いてユーザーが利用できる機能の全容でなくとも完成した一部分のみをリリースすることができるようになります。また、Feature Toggleの管理を外部化することでより柔軟な運用を可能とします。これらは変更の粒度を小さくし、アプリケーションの実装やリリースの範囲を一部に切り出すということを実現しています。 以上、アプリケーションの一部を切り取る工夫として2つの事例を紹介させていただきました。1つ目はモダンWebフロントエンド環境の漸進的な導入、2つ目はFeature Toggleの活用と管理でした。 おわりに 最後に、ここまでの発表を振り返ることで前半の締めとしたいと思います。 本発表では、カラーミーショップを含むWebアプリケーションの開発が、一度に一部分のみを変更するということを繰り返す漸進的な改善によってなされていることを説明しました。また、アプリケーションの一部を切り取る工夫として、その範囲を柔軟に決めやすくなるような取り組みを2つ紹介しました。 これからも、切り取り方を工夫しながらアプリケーションの漸進的な改善を続けていきたいと思っております。 以上で前半の発表を終わります。ご清聴ありがとうございました。 後半 https://developers.gmo.jp/24747/ アーカイブ映像 https://youtu.be/lz4IVcds9Fo PHP Conference Japan 2022: 17年続くWebサービ… / やんまー、ほみるん | GMOペパボ - YouTube

　Microsoft365のSharePoint Onlineは情報共有の場として、共同作業のプラットフォームとして、クラウドストレージとして、さらにTeamsのバックエンドシステムとして様々な機能が提供されています。SharePointのサイトは社内のポータルサイトとして活用されるケースも多いようです。今回は、少しマニアックに、2種類あるサイトのうち、コミュニケーションサイトでディスカッション掲示板を利用する方法と、さらに「いいね！」ができる機能の実装方法を紹介してゆきます。 SharePoint 2種類のサイト 　SharePointで新しいサイトを作成する場合「チームサイト」と「コミュニケーションサイト」の2つのテンプレートを選択できるようになっています。「チームサイト」はプロジェクトごとに限定されたメンバー間での情報交換の場として、Teamsのプラットフォームとしても機能します。「コミュニケーションサイト」は社内のポータルサイトとして多くのメンバーを対象にした情報発信の場所として機能します。コンセプトの違いからそれぞれ利用できるサービスなどが異なる部分があり、場合によっては使いづらいとも感じられる部分があります。今回はSharePointの情報交換の場として人気のある「ディスカッション掲示板」に注目してみます。 サイトの作成 　まずは、チームサイトを作成してみましょう。 サイトの作成自体は簡単です。チームサイトが作成されました。 続いてコミュニケーションサイトを作成してみます。 こちらも簡単に作成されました。チームサイトと比べてレイアウトの違いが分かります。 それぞれのサイトの異なる点を挙げると結構な数になりますので、追加できるアプリを見てみましょう。 ディスカッション掲示板 　SharePointサイトは、サイトやページ内にアプリや様々な機能を追加できるといった特徴があります。アプリを追加してみましょう。　チームサイトの「新規」-「アプリ」を選択します。 SharePointストアが用意されて、スマートフォンのアプリを追加する感覚で色々な機能拡張が可能となっています。 SharePointストア以外にも、元々SharePointの機能として提供されている組み込みアプリもあり、人気のあるアプリが数多く用意されています。「マイアプリ」のページから「追加できるアプリ」-「従来の環境」を選択します。 チームサイトでは追加できるアプリはこれだけ用意されています。この中で「ディスカッション掲示板」を選択して追加してみましょう。 コンテンツ内に追加されました。 実際に使ってみましょう。最初の投稿です。 情報交換の場として以前から人気のあるいわゆる、スレッド型の掲示板です。この掲示板には、今時のSNSのように「いいね！」や☆で投稿に対して評価を付けられる機能が用意されています。こちらを有効にしてみましょう。「リスト」メニューから「リストの設定」を選択します。 「全般設定」-「評価の設定」を選択します。 「評価の設定」で“はい”を選択して、「いいね！」もしくは「星評価」のどちらかを選択します。 掲示板に戻り、「リスト」メニューから「ビューの作成」を選択します。 「管理」を選択します。 「いいね！」関連の表示チェックが入っていることを確認して、ビュー名を指定して保存します。 掲示板に戻ると「いいね！」関連の列が追加されています。「いいね！」をクリックするとカウントされるようになっています。 このようにスレッド形式でディスカッションが進みます。 チームサイトとコミュニケーションサイトの違い 　では同様にディスカッション掲示板をコミュニケーションサイトに追加してみようと思います。コミュニケーションサイトのアプリ一覧を見てみるとこれだけしか参照できません。チームサイトと比較してみると大きくことなります。コミュニケーションサイトの追加可能なアプリ チームサイトの追加可能なアプリ 多くのメンバーに向けて情報を一方的に発信するというポータルというコンセプトがコミュニケーションサイトの考え方なので、相互に情報交換をするアプリな不要との考えからでしょうか。 コミュニケーションサイトでディスカッション掲示板を追加する 　それでも、ポータルサイト内に相互に情報発信できる場所としてディスカッション掲示板を利用したいという要望も多くあります。そこで、今回はコミュニケーションサイトでディスカッション掲示板を追加できるようにしてみます。まず、作成したコミュニケーションサイトを表示して、「設定」-「サイト情報」を選択します。 「すべてのサイト設定を表示」を選択します。 「サイト機能の管理」を選択します。 「チームのグループ作業リスト」を“アクティブ”にします。 ホーム画面に戻り、あらためてアプリを追加してみましょう。今度はチームサイトと同様に追加できるアプリが増えています。早速「ディスカッション掲示板」を追加しましょう。 これで、コミュニケーションサイトでディスカッション掲示板ば利用できるようになりました。 コミュニケーションサイトのディスカッション掲示板で「いいね！」を有効にする 　続いて、「いいね！」をできるようにしてみましょう。　先ほどと同様に、「全般設定」-「評価の設定」を選択します。「全般設定」を見てみるとはあるはずの「評価の設定」の項目が見当たりません。コミュニケーションサイトでは、「いいね！」の機能も意図的に非表示にされているようです。 では、「いいね！」ができるように設定を行いましょう。こちらの設定はPowerShellで行うことになります。Connect-PnPOnline　にしてするURLはコミュニケーションサイトのトップページのURLとなります。それ以外はこのまま実行します。 Install-Module PnP.PowerShell Connect-PnPOnline -url "https://hj545rkw.sharepoint.com/sites/demo_Communication" Enable-PnPFeature –identity 915c240e-a6cc-49b8-8b2c-0bff8b553ed3 -Scope site 実行後、リストの設定を確認してみると、「評価の設定」が表示されています。早速先ほどと同様に「いいね！」の設定を行って、カスタムビューを作成して確認しましょう。 「いいね！」できました。 　以上が、コミュニケーションサイトにディスカッション掲示板を追加して「いいね！」ができるようになる設定方法の紹介となります。SharePointは多機能ゆえに、設定項目も数えきれないくらい用意されています。サイト一つを見ても、利用用途によって、機能制限や仕様が異なる部分が多くなっています。場合によっては、隠れている機能をPowerShellで表示させるといった裏技的なものまであるようです。一方、必要な機能をその都度検証、研究して使えるようにしてゆく楽しさもあります。じっくり時間をかけてSharePointに向き合ってみるのもよさそうです。

初めまして。GMOインターネットグループ株式会社の清水です。みなさんは電気通信主任技術者という国家資格をご存じでしょうか。みなさんがインターネットを使っている裏側ではこの資格を持った人が必要不可欠なのですが、何をしているのかはおろか資格自体初耳という人も多いと思います。この記事では電気通信主任技術者とは何か、そしてインターネットの裏側で電気通信主任技術者はどのようなことをしているのか解説したいと思います。 電気通信主任技術者とは？ インターネットプロバイダサービスを提供している会社では、各家庭からインターネットに接続するための回線設備の維持・運用・管理を行っています。一定以上の規模の回線設備に対してアップグレードなどの理由で工事をするときや、運用管理をする場合にはこれらを監督する責任者が必要になります。その監督するうえで必要な資格が電気通信主任技術者になります。現実の世界でも道路工事や建設工事などには責任者が必ずいると思いますが、電気通信主任技術者はそれのインターネット版だと思っていただけたらイメージしやすいかと思います。 なぜ監督責任者に資格が必要なのかというと、インターネット回線設備を扱うためには専門知識を持った人が必要であり、ひとたび誤った扱いをすると非常に広範囲に影響が出てしまうからです。言うまでもないことですが皆さんが毎日のように利用しているインターネットは生活になくてはならないものであり、電気・ガス・水道といったインフラのように一度止まってしまうと社会に与える影響が非常に大きなものになっています。しかしながら上述した誤った扱いにより非常に多くの人が長時間インターネットを使用できない障害がたびたび発生しています。そのためインターネット回線設備を正しく扱える専門知識を持っていることの証明として電気通信主任技術者があり、それを監督責任者とすることで社会がいつでもどこでもインターネットを使うことができるようにしているのです。 資格を取得するには 電気通信主任技術者の資格を取得するためには、一般財団法人日本データ通信協会が運営する電気通信主任技術者試験に合格する必要があります。試験内容は選択問題のペーパーテストで、3科目すべてで60%以上の点数を取る必要があります（学歴・実務経験により科目免除あり）。 勉強方法としては電気通信主任技術者試験のホームページに過去問が提供されていますので、そちらを確認して試験傾向をつかんでおくのがいいかと思います。また過去問の解説や過去問に出題されている技術内容の解説をしている試験対策本やWebサイトがありますので、過去問を解いて出題内容がわからない場合はそちらを参照するといいと思います。筆者は過去問のほかに下記のような試験対策本をGMOインターネットグループの福利厚生の一つである「学ぼうぜ！」で購入して勉強しました。 https://www.amazon.co.jp/dp/4274217922 資格取得のきっかけ GMOインターネットグループではインターネットプロバイダサービスとしてGMOとくとくBBを10年以上にわたって運営しており、大変多くのお客様がご利用されています。ご利用されているお客様が大変多いため、ひとたび通信障害が発生するとそれが与える社会的影響が甚大なものになります。総務省ではそのようなサービスを提供している会社を法律に基づき、プロバイダサービスを提供するうえでの管理規定の策定と、その管理規定の遵守およびインターネット回線の維持運用管理の監督責任者として電気通信主任技術者の選任を義務付けています。弊社も総務省から指定をいただきましたので、管理規定の策定と電気通信主任技術者の選任を進めていました。 その中でGMOインターネットグループの商材を支えるデータセンターネットワークを担当していた私に資格取得の話が舞い込んできました。 話を聞くうちに自分のスキルアップにつながると考え、数か月間にわたり勉強した結果、無事試験に合格し資格を取得しました。 さいごに 電気通信主任技術者は知名度こそ低いものの、インターネットを安定して使えるようにするためには欠かせない資格です。普段インターネットを使っているときに「インターネットが使えているのは電気通信主任技術者が裏で頑張っている」ということを思い出していただければ幸いです。 ※本記事の情報は記事執筆時点（2022年9月）の情報を基に記載しています。　最新の情報は電気通信主任技術者試験のホームページをご確認ください。

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューション部の梅崎です今回はローカル5G案件でfree5GCをVMで動かしどれだけのトラフィックをさばけるのか試しました 構成 free5GCの全コンポーネント入のVMを一台UERANSIMのUE&gNB相乗りを偶数台 一台のサーバーの中に↑をVMとして作成してそれぞれは同じブリッジに接続しています 端末の接続を行うとデータ通信はUE（端末）<==>UPF（コア）間でカプセリングされやりとりされます 主に使ったもの 5Gコアfree5GCリンク１リンク２5Gアンテナ/端末シミュレーターUERANSIMリンクOSUbuntu 22.04.1 LTSトラフィック生成ツールiperf version 2.1.51台目のサーバー(他にもいろいろ相乗り)CPU: Intel(R) Xeon(R) CPU E5-2630 v2 × 2ソケット（計12コア/24スレッド）メモリー: 128GB* qemu-kvm* libvirt-daemon-system* virtinst* ovmfこの辺をインストールしています2台目のサーバー(次回記載予定) CPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GB トラフィック印加試験 1台目のサーバーのみ #双方向にトラフィックを200M上限で流す(以下同様のコマンド、上限だけ変更している) #出す側 iperf -i 1 -t 600 -b 200M -l 1400 -c ${受け側の端末へ払い出されたIP} -d #受け側 iperf -s -i 1 この構成だと1ペアだけの通信でも上下合わせて260Mbps弱しかでずさらには10～90秒ほどでUEがシグナルロストしてしまう事象が発生しました 次に4ペアでそれぞれ100Mbps上限でトラフィック印加したところ1ペアのときとは異なり、上下すべて合計で400Mbps程度は出たものの1ペアのときと同じく10～90秒ほどでUEがシグナルロストしてしまう事象が発生しました なお、躓いたポイントとしてを後ほど書くのですがもともとはすべての通信が一つのコアで捌いていたようで上下200Mbpsほどで頭打ちだったのでこの400Mbpsでも良くなった方ではあります ただし、最後のペアは100Mbpsは切断されることはなく7分間は通信し続けることができましたが、やはりしばらく時間が経つと途中で切断されてしまいました…… （この構成ですと400Mbpsの通信の時点でホストマシンのCPU使用率がえらいことになっていました全コアが60数%を超えてくれないのでハイパースレッディングがうまくいってないんですかね？） はまりポイント セキュアブート 今回のfree5GCではUPFのパケットの処理にカーネルモジュールの読み込みが必要なのですがそのままmake installでインストールエラーが出ていました 調べていくとどうも署名が無い（？）ようでセキュアブートが有効になっていると失敗しているようでした なのでセキュアブートを無効化するためvirsh-editでVMの設定の該当の箇所へ↓を追記しました <domain type='kvm'> <os firmware='efi'> <loader secure='no'/> <bootmenu enable='yes'/> ブートメニューの選択肢が出ないようになっていたのでVM側でも↓の設定をしています /etc/default/grubへ↓ ------------------------------ GRUB_TIMEOUT_STYLE=menu GRUB_TIMEOUT=0 GRUB_HIDDEN_TIMEOUT_QUIET=false GRUB_HIDDEN_TIMEOUT=10 ------------------------------ ↑を追記/書き換え sudo update-grub で反映 その後VMを起動するとブートメニューが表示されその中に「UEFIの設定」の項目があるはずなのでそれを選択して設定を開き、セキュアブートを無効化しました net.ipv4.ip_forward free5GCのUPFを動かすサーバーで /etc/sysctl.conf の↓ --------------------- net.ipv4.ip_forward=1 --------------------- ↑のコメントアウトを外すか末尾に追記 を実施することでパケットフォワードしてくれるようになります（iptablesなども適宜許可が必要です） virtio-netのチューニング デフォルトだと一つのコアでしかパケット処理をしてくれないらしく一つのコアだけが使用率100%になっていることがあったのでこちらを参考にキューの数を増やすことでトラフィックフローごとに複数のコアにバランシングされるようにしました また、こちらも行っています（ただ、こちらで性能向上したかはあまり体感はできなかったです……） 所感 色々全部のせでVMを作ったところハイパーバイザ側のブリッジングの処理などですかね？結構CPU負荷が高いようでしてトラフィックを捌くどころかCプレーン的な通信も落としちゃっているような気がしています 一応トラフィック制限をかけ50Mbps程度の通信なら落ちないようなのですがこのままでは実機アンテナとの接続試験どころではないなと感じました 次回 Linux側のチューニングを行うことで多くのトラフィックをさばけるのかもしれないのですが正直今の性能を見るに、チューニングでの性能向上は疑っております…… なので次回は「小技ではなく力技で」ということで5Gコアを別筐体で構築し改めて試験しようと思います

お久ぶりです。GMOインターネットグループ株式会社の中村です。前回のSeleniumの紹介で環境構築部分をサボって省略してまったので、改めてご紹介させていただきます。なお、seleniumに対応しているブラウザは複数種類ありますが、今回はchromeについての利用方法をご紹介します。 OSの違い 今回はLinux/Windows2つの環境構築についてご紹介します。個人的な所感ですが、 実際に目で見ながらデバッグを行う面では統合開発環境などの面でWindows完成したプログラムを定期実行するならランニングコストが安いLinux どちらもできないことはないのですが、自分がやりやすい環境で行うのが一番だと思います。早速、実行環境を構築していきましょう。 環境構築 Linux編 ConoHaでVPSを申し込み 家に余っているハードウェアあったり、仮想環境を構築済みの場合は良いのですが、そうでない場合はイニシャルコストが高くついてしまいます。ConoHa VPSであれば時間単位の課金で安価に使用できます。今回はOSに【Alma Linu（アルマ リナックス）】で環境構築を行います。サーバー追加の流れは下記の画像をご覧ください。スペック/OS/パスワード/VM名を画面指示に従うだけで簡単に作成が可能です。 SSHクライントでの接続確認 申し込んだサーバーができたところで手元で楽に操作ができるようにSSH接続を行います。SSHクライアントソフトは色々なツールがありますが、下記はteratermで説明しています。 まず、申込後に表示されたサーバーのIPを入力します。 その後、下記を入力します。 ユーザ名【root】パスフレーズ【申込み時に設定したパスワード】 下記のような黒い画面が出れば接続成功です。 python インストール Seleniumの実行にはPythonが必要です。Alma Linux9.0の場合には【Python 3.9.10】がデフォルトで入っていますので今回は追加不要です。 ◆バージョン確認コマンド python3 --version ◆(例)バージョン確認 [root@160-251-22-89 ~]# python3 --version Python 3.9.10 [root@160-251-22-89 ~]# pipインストール seleniumのインストールにはpythonの拡張ライブラリを管理する【pip】が必要になります。下記コマンドでpipのインストールを行います。 yum -y install pip seleniumのインストール pythonがSeleniumを使用できるように下記コマンドでインストールを行います。 pip install selenium chromeのインストール 今回の記事では【google chrome】を使用した自動操作の方法をご紹介します。デフォルトではインストールされていないので下記の方法でインストールを行います。 ◆リポジトリの追加 echo /etc/yum.repos.d/google.chrome.repo << 'EOF' [google-chrome] name=google-chrome baseurl=http://dl.google.com/linux/chrome/rpm/stable/$basearch enabled=1 gpgcheck=1 gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub EOF ◆chromeをインストール yum -y install google-chrome-stable ◆chromeのバージョン確認 google-chrome --version ◆(例)バージョン確認の実行 [root@160-251-22-89 ~]# google-chrome --version Google Chrome 105.0.5195.125 [root@160-251-22-89 ~]# chromeドライバーのインストール SeleniumをChromeで使用する場合は【chromedriver】が必要になります。これがない場合、selenium↔cherome間でのやり取りができず、ブラウザ自動操作ができません。chromeDriverとchromeのバージョンは合わせる必要があります。そのため、先程確認したchromeのバージョンを控えておきます。その後下記のURLの中でバージョンが合うchromeDriverのダウンロードリンクをコピーします https://chromedriver.chromium.org/downloads今回はchrome側のバージョンが【105.0.5195.125】のため 【Supports Chrome version 105】の表記がある一番新しいバージョンのchromeDriverが対象になります。 ◆対象のzipファイルをダウンロード wget コピーしたURL ◆zipファイルを展開 unzip chromedriver_linux64.zip ◆展開したファイルを移動、実行権限の付与 mv chromedriver /usr/local/bin/ chmod 755 /usr/local/bin/chromedriver ◆zipファイルの削除 rm -f chromedriver_linux64.zip ◆実行できるかバージョン表示を確認 chromedriver --version ◆（例）ファイルダウンロード wget https://chromedriver.storage.googleapis.com/index.html?path=105.0.5195.52/chromedriver_linux64.zip ◆（例）バージョン確認例 [root@160-251-22-89 ~]# chromedriver --version ChromeDriver 105.0.5195.52 (412c95e518836d8a7d97250d62b29c2ae6a26a85-refs/branch-heads/5195@{#853}) [root@160-251-22-89 ~]# 日本語フォントのインストール デフォルトでは日本語フォントが入っていません。そのため、chromeで開いたときに日本語があると文字化けしてしまいます。 文字化けになるのは避けたいため日本語フォントのインストールを行います。 ◆日本語フォントファイルのダウンロード wget https://moji.or.jp/wp-content/ipafont/IPAexfont/IPAexfont00401.zip ◆zipファイルを展開 unzip IPAexfont00401.zip ◆フォルダ作成/展開したファイルを移動 mkdir /usr/share/fonts/ipa mv IPAexfont00401/*.ttf /usr/share/fonts/ipa/ ◆フォントファイルの再読み込み fc-cache -fv ◆対象フォントが読み込まれているかチェック(明朝とかがあればOKです) fc-list | grep IPA ◆zipファイルの削除 rm -f IPAexfont00401.zip 実行テスト これで実行環境が整いました。早速、実行テストを行っていきましょう。 下記のファイル【linux_test.py】を作成し、下記コマンドで実行します。正常に実行できた場合はConoHaのTOPページのキャプチャが作成されます。 # coding: utf-8 #ライブラリ読み込み from selenium import webdriver import time # ドライバーの準備(CUIだと非表示モードでしか起動不可なため) options = webdriver.ChromeOptions() options.add_argument('--headless') options.add_argument('--no-sandbox') #クロームの立ち上げ driver=webdriver.Chrome(options=options) #ページ接続 driver.get('https://www.conoha.jp/conoha/') #10秒終了を待つ time.sleep(5) #画面キャプチャを取得 driver.save_screenshot('conoha.png') #クロームの終了処理 driver.close() ◆ファイル作成 vi linux_test.py ◆スクリプトの実行 python3 linux_test.py ◆ConoHaのキャプチャ(conoha.png)が出力されているかチェック ll 環境構築 Windows編 ConoHaでもWindowsServerの申し込みが可能です。ただ、Windowsについては手元のPCで動かす方のほうが多いと思うので、申し込み方法は割愛させていただきます。こちらの紹介では【Windows10】を例にしています。 pythonインストール Windowsにpythonはデフォルトインストールされていませんので、下記リンクより安定版（Stable Release）のダウンロードを行います。現時点の最新安定版は【3.10.7】になります。 https://www.python.org/downloads/windows/ ダウンロードしたexeファイルを実行します。この際に赤線部分の【Add Python 3.10 to PATH】にチェックを入れるようしてください。チェックを入れない場合は手動で環境変数の変更が必要です。 pip インストール seleniumのインストールにはpythonの拡張ライブラリを管理する【pip】が必要になります。Windowsではpythonインストール時に同時にインストールされるので割愛します。 selenium インストール pythonがSeleniumを使用できるようにしていきます。 まず、スタートボタンをクリックし、Windowsシステムツール→コマンドプロンプトを管理者権限で実行します。 コマンドプロンプトに下記コマンドを打ち込みインストールを行います。 pip install selenium chromeのインストール 次にchromeのインストールを行います。下記のURLよりインストールファイルをダウンロードし、進めてください。 https://www.google.com/intl/ja_jp/chrome/ インストールが終わったら、chromeを立ち上げてバージョンを確認していきます。確認方法は下記画像を参照してください。 chromeドライバーのインストール SeleniumをChromeで使用する場合は【chromedriver】が必要になります。これがない場合、selenium↔cherome間でのやり取りができず、ブラウザ自動操作ができません。chromeDriverとchromeのバージョンは合わせる必要があります。そのため、先程確認したchromeのバージョンを控えておきます。その後下記のURLの中でバージョンが合うchromeDriverをダウンロードします。 https://chromedriver.chromium.org/downloads今回はchrome側のバージョンが【105.0.5195.127】のため 【Supports Chrome version 105】の表記がある一番新しいバージョンのchromeDriverが対象になります。 ダウンロードしたファイルを、下記のように展開をします。 展開してできたフォルダ【chromedriver_win32】を任意の場所に移動します。後から変更もできますので、迷った場合はCドライブ直下でも問題ありません。 移動が終わったら、環境変数への登録を行います。Windowsキー＋Sで検索ボックスが開くので【環境変数】と入力すると、【システム環境変数の編集】がHitするのでクリックしてください。 画面下部の【環境変数】をクリックします。 Pathと書いてある行を選択して編集ボタンをクリックします。 画面下部の空白に移動した先のディレクトリを入力します。Cドライブ直下にディレクトリを配置した場合は下記の例になります。 実行テスト これで実行環境が整いました。早速、実行テストを行っていきましょう。 下記のファイル【windwos_test.py】を作成し、下記コマンドで実行します。正常に実行できた場合はConoHaのTOPページのキャプチャが作成されます。 # coding: utf-8 #ライブラリ読み込み from selenium import webdriver import time #クロームの立ち上げ driver=webdriver.Chrome(options=options) #ページ接続 driver.get('https://www.conoha.jp/conoha/') #10秒終了を待つ time.sleep(5) #画面キャプチャを取得 driver.save_screenshot('conoha.png') #クロームの終了処理 driver.close() ◆cmdでスクリプトの実行 python windows_test.py 準備完了！ これで実行環境が整いました。更に開発環境を快適にしたい場合はVisual Studio codeなどのエディタを入れると便利です。関連記事では、Seleniumでどんな事ができるのかを紹介していますのでそちらも是非ご覧いただけると幸いです！ 関連記事はこちら https://developers.gmo.jp/15591/ https://developers.gmo.jp/19932/

こんにちは。GMOインターネットグループ株式会社新卒1年目の山名です。今回は、Webページにおける横並びの実装方法を調査、比較しましたのでご紹介します！ 執筆の背景 皆さんはWebページで要素を横並びにしたいなーって時、どんな方法で実装していますか？Webコーディングをする上で必須とも言える横並びレイアウトですが、その歴史は深くWebの技術やHTML,CSSがアップデートされる度にさまざまな実装方法が生まれてきました。私自身、複数ある実装方法の中でどれを使うか迷ってしまうという状況によく直面します…今回は、そんな「何を使えばいいんだろう」という悩みを解決するとともに、数年前まで横並びの最前線で使用されていたfloatが現在では使われなくなってしまった理由を明らかにしていこうと思います！ なぜfloatは駆逐されたのか 早速ですが、floatを使った横並びはなぜ駆逐されていったのか...その理由を考えてみます。 このブロックには、想定されていないか無効なコンテンツが含まれています。ブロックのリカバリーを試行 一言で言えば「flexが便利すぎて戻れない！！」floatで作るレイアウトの自由度が低かったり、実装に手間がかかるという理由もあるにはあると思いますが、何よりもflexレイアウトが便利すぎるんです。というのも、昨今の横並びレイアウトで主に使われているflexレイアウトは複雑な配置でも柔軟に対応できるというで、floatで出来ることのほとんどはflexに取って代わられてしまいました。また、機能面の改善だけでなく「 flex って書けば、初期値でだいたい望む配置にできてしまう」「クリエイターが言葉で表現しにくい細かい部分も勝手に調整してくれる」「何より実装が簡単で戻れない」といった、実装するコーダー本人の体験が改善されていったことも大きな理由です。他にもgridレイアウトを使った横並びでもできることが多く、結局floatを使わなくてももっと簡単に便利に実装できるようになってしまったことで、現在ではほとんど出番がなくなっています。 横並びレイアウトとは 横並びレイアウトとは、文字通りWebページの要素を横並びで配置することです。<span>タグや<a>タグのようなインライン要素と呼ばれるものを除き、Webページでは基本的に要素の後に自動的に改行が入るため縦方向に要素が連なっていきます。それらの要素を横並びに設定し直すことで、ページが長くなりすぎることを防ぎ、ページ全体の可読性を向上させる効果があります。実際には、グローバルナビゲーションやサイドバーとメインコンテンツの配置等に主に用いられている横並びレイアウトですが、その実装方法は複数存在しているため以降ではいくつかの実装方法とその特徴をそれぞれ説明していきます！ 横並びレイアウトを比較解説 今回は、「float」「flex」「grid」の3つの実装方法で以下のデザインを作成し、それぞれの特徴を比較していきます。※サンプルコードにCSSの共通部は記載していません。 「float」の特徴と実装方法 floatは、CSS3が普及するより以前に横並びを実装するために一般的に使用されていたCSSプロパティです。本来floatは文章の中に画像を差し込んだり、要素の周りに文章を回り込ませることが目的のプロパティですが、その要素が回り込むという性質を利用することで横並びレイアウトを実装しています。 メリット 「flex」「grid」を使った実装と比べ、古いブラウザまで対応できる→ float以外の新しい技術に関してもブラウザ対応が進んでいることもあり、横並びでfloatを使用するメリットはかなり少なくなっています。 デメリット 配置の自由度は高くない予期せぬ回り込み等でデザインが崩れることが多い 使用する際は、横並びにしたい対象に対して「float:left（またはright）」を指定することでその要素を横並びにすることができます。 .box{ float: left; } .clearfix::after { display: block; clear: both; content: ""; } <h1>「float」を使った横並びの実装</h1> <div class="clearfix"> <div class="box box1"></div> <div class="box box2"></div> <div class="box box3"></div> </div> <p>サンプルテキスト</p> floatを使って横並びにした場合、それ以降の要素に回り込みが設定され続けてしまうため、その都度回り込みを解除する記述が必要になります。上記のコードでは「clearfix」を使用した手法で解除しており、親要素の疑似クラスに解除用のスタイルを適用することで以降の要素を縦並びに戻しています。他にもclearプロパティを使った方法やoverflowを使った方法があり、それぞれ記述量が少ないため用途やデザインによって使い分けるのが良さそうです！ 「flex」の特徴と実装方法 flexは、CSS3から追加された縦横配置のレイアウトを簡単に実現できるプロパティです。 現在は極端に古いブラウザを除きほとんどのブラウザで対応している点と、レイアウトが柔軟でなんでも作れてしまうという特徴も相まって、flexレイアウトは横並びのスタンダードになっていると言っても過言ではありません。 メリット 要素の縦横並びの変更だけでなく表示の順番や要素間の幅、高さなどさまざまな値が柔軟に調整できる実装が比較的少ないコード量でできる デメリット 入れ子構造が複雑になりがち 基本的な実装方法は簡単で、配置を変えたい要素の親要素に「display:flex」を設定することで子要素にflexレイアウトが自動で適用されるようになります。 .boxflex{ display: flex; } <h1>「flex」を使った横並びの実装</h1> <div class="boxflex"> <div class="box1"></div> <div class="box2"></div> <div class="box3"></div> </div> <p>サンプルテキスト</p> 今回は使用していませんが、flexレイアウトには多くのプロパティが用意されており、使いこなすのは難しいですが様々な組み合わせによってより複雑なレイアウトや状況に応じたレスポンシブ対応の実現が可能になっています。特に、折り返しのスタイルを指定する flex-wrap やレスポンシブ対応等で配置の方向を変更したい時に使用する flex-direction は使用する場面も多く便利なプロパティなため、ぜひ覚えて使ってみてください！ 「grid」の特徴と実装方法 gridは、格子状のマス目のグリッドに要素を配置し、順番を変えたり結合することで様々なレイアウトが実現できるプロパティです。実際にgridレイアウトを使用する場合は、あらかじめ格子のレイアウト決めておき、そこに要素を割り当てていく方法が基本になります。 メリット 縦横の配置に対して比較的自由にレイアウトできる デメリット 要素の増減に対しては柔軟に対応しづらい古いブラウザだとまだ対応していないこともある→ 使用する際には事前に対応しているブラウザの確認が必要 実装方法はflexレイアウトと同様で、配置を変えたい要素の親要素に「display:grid」を指定することで子要素の配置を変更できるようになります。今回の場合は、幅100pxの四角形を横に3つ並べるため「grid-template-columns」でマス目の幅を100pxで3つ並ぶように設定しています。 .boxgrid{ display: grid; grid-template-columns: 100px 100px 100px; } <h1>「grid」を使った横並びの実装</h1> <div class="boxgrid"> <div class="box1"></div> <div class="box2"></div> <div class="box3"></div> </div> <p>サンプルテキスト</p> gridレイアウトは、そもそもfloatやflexで作るレイアウトとは配置を指定する方法も違っているため、最初は難しく感じることもありますが、覚えてしまえば二次元的に自由な配置ができるためとても頼もしい存在です！また、使用すると要素（グリッド）間の幅を細かく調整することができる gap というプロパティがあるのですが、これはflexレイアウトにはないプロパティのため、使えるのはgridレイアウトのみになります。 まとめ Webページにおいて横並びは一般的なレイアウト手法ではありますが、その実装方法はCSSの発展と共に変化しています。しかし、今は使われなくなっている技術も確実にCSSの一時代を支えていたと思うと、今からでも知識として持っておくことに損はないと思います。また、現在でもテキストの回り込みにはfloatを使うのが便利であり、これが本来の使い道だということを考えると、適材適所に戻ったとも言えるのではないでしょうか。 これを機に、横並びレイアウトの変化だけでなくCSSの全体の歴史にも興味を持っていこうと思います！

こんにちは。GMOインターネットグループ株式会社の久野です。今回は、私の過去に体験に基づいて、DNSサーバーの仕組みと重要性についてお伝えしたいと思います。 DNSとは DNSとは、Domain Name Serverの略で、DNSサーバーはドメインとIPアドレスの紐づけを行っています。私たちが普段サイトにアクセスする時、DNSサーバーに問い合わせて得られたIPアドレスに対して接続しています。 例えばGoogleにアクセスする時、ブラウザに「google.com」と入力してアクセスするとします。すると、DNSサーバーに「google.comのIPアドレスは何ですか？」という問い合わせが行われ、「google.comのIPアドレスは”xxx.xxx.xxx.xxx”」という応答が返ってきます。DNSサーバーから返ってきたIPアドレスに接続することで、Googleへのアクセスが成功します。 何が起きた？ ある日突然、自宅のPCでYoutubeとTwitterにだけ接続できなくなってしまいました。同じネットワークに繋がっているスマホからは接続できるので、問題はPC側にあると判断しました。 そこでまず初めに、IPアドレスとホスト名の対応を記述したhostsファイルを確認しました。 このファイルはPCでサイトにアクセスする時、記載があれば最初に参照されます。もし、サイトのドメインが本来とは異なるIPアドレスと紐づけされていれば、通常のサイトを見ることができなくなってしまいます。 hostsファイルを書き変えられたとすれば、IPアドレスとドメイン名の対応が追加されているはずですが、デフォルトの状態から変わった様子はありませんでした。 原因はDNS設定だった PCにはHostsファイルともう1つ、ネットワークに関わる重要な設定項目があります。それがDNSサーバー設定です。DNSサーバーは世界中に存在し、どれを使うか指定することができます。 Windowsであれば「ネットワーク設定」からDNSサーバーを変更できます。 私の場合、ここに見覚えのないサーバーのアドレスが設定されていました。このサーバーについて調べたところ、海外の会社が運営しており、仕様として特定のサイトへのアクセスを禁止していたようです。この仕様により、一部のサイトだけ接続できなくなっていたようです。 なぜDNS設定が変わってしまったのか？ 原因について、事象が発生したのが家族共用のPCだったので特定は難しいですが、おそらく誰かがフリーソフトをインストールした時に一緒にインストールされた別のソフトによって書き変えられたのだと思います。フリーソフトの中には、ユーザーの気づかないところで設定を変えてしまうものがあります。 今回の被害は、特定のサイトにアクセスできなくなる程度でしたが、個人情報の取得などを目的とした攻撃の場合もあります。もし、悪意のある人がDNSサーバーを用意して、偽サイトに接続するように設定したとします。そのDNSサーバーを使うように設定変更された場合、偽サイトに接続していると気づかずに個人情報やクレジットカードの番号などを渡してしまうことになります。 また、過去には「DNS Changer」というDNSサーバーの設定を書き変えて偽サイトに誘導するマルウェアが実際に報告されています。このようなマルウェア感染も疑いましたが、今回はDNSサーバーの運営元が分かっており、偽サイトへの誘導も見られなかったので可能性は低いと判断しました。 狙われるのはPCだけではない 私の場合はPCのDNSサーバー設定を書き変えられましたが、DNSサーバーの設定はルーターにも存在し、ルーターを狙った攻撃も存在します。確認されている手法では、ルーターの脆弱性(弱点)を突いて管理画面にログインし、DNS設定を書き変えるというものがあります。 ルーターの設定が変わった場合、そのルーターを介するネットワークを使う他の機器にも影響が出るので、スマホやタブレット、OSに関係なく被害に遭うことが考えられます。特に、ルーターのファームウェアが古いものや管理画面のパスワードが初期値のままだと狙われやすくなります。ルーターに限った話ではないですが、パスワードは初期値から必ず変更しましょう。また、公式サイトなどでファームウェアのアップデートが提供されていないか定期的に確認し、もしあれば更新することをお勧めします。 まとめ PCで使用するDNSサーバーが、何かの拍子にデフォルトから変わってしまい、そのDNSサーバーの仕様により特定のサイトにアクセスできなくなりました。DNSサーバー設定が書き変えられると、気づかないうちに偽サイトに誘導されたりするリスクがあります。 一方で、DNSサーバーの中には「パブリックDNS」と呼ばれる、アドレスが一般に公開させていて無料で使えるものが存在します。広告ブロックや危険なサイトへのアクセスを遮断してくれるなど便利な機能を持つものもあるので、興味がある方は調べてみてはいかがでしょうか。 また、ルーターに関して公式サイトで脆弱性情報が公開されていると書きましたが、ルーター以外にも様々なハードウェア・ソフトウェアに脆弱性があります。その情報を1つずつ公式サイトから調べることもできますが、JVN iPediaという脆弱性情報のデータベースを使えば、任意のキーワードや脆弱性情報が公開された日付など、さまざまな条件で検索することができ、対策方法も掲載されています。自分の使っている製品にリスクがないか調べるのはもちろん、てきとうに検索してどんな脆弱性があるのか読んでみるだけでも面白いですよ。

みなさん、こんにちは。GMOインターネットグループ株式会社の斉藤です。・・・、私はいつも上記のご挨拶でブログを書き始めますが、ちょっと変わりましたね。お気づきになりましたか？弊社は2022年9月1日付けで商号変更いたしました。GMOインターネット、「GMOインターネットグループ株式会社」に商号変更https://www.gmo.jp/news/article/7964/　-旧: GMOインターネット株式会社　-新: GMOインターネットグループ株式会社引き続き、GMOインターネットグループ株式会社をよろしくお願いいたします。 Google アナリティクス4とAPI 前回の「CryptoName byGMOでNFTドメインを取得しよう」と言う記事でご紹介したCryptoName byGMOですが、サイトへのアクセスを調べるためにGoogle アナリティクス4（GA4）を導入しています。これは以前からあるユニバーサルアナリティクス（いわゆるグーグルアナリティクス）の置き換えに当たるものです。 GA4にはそのデータにアクセスするためのAPIが用意されていて、Google Analytics Data API（GA4）と呼ばれるものです。このAPIを利用するとGA4に関する様々なパラメータが取得できるので、マーケティング分析などの強い味方になります。 現在APIで実行可能なのはレポートの作成のみです。レポートの作成というのは、GA4上のデータをいろいろ組み合わせて一つのレポートを作成し、APIの出力結果として受け取るものです。 Google Analytics Data API（GA4）https://developers.google.com/analytics/devguides/reporting/data/v1 早速使ってみましょう。今回はPHPを利用します。 サンプルコードを実行してみよう 1. GCPアカウントの作成 Google Analytics Data APIはGoogle Cloud Platform（GCP）のサービスの一つです。GCPのアカウントをお持ちでない方はまずアカウントを作成する必要があります。既存のGoogleアカウントを連携できるので、お持ちであればすぐです。 https://console.cloud.google.com/apis/dashboard?hl=ja 2. APIを有効にする 次に、オフィシャルドキュメントのQuick Startにある以下の[Enable the Google Analytics Data API v1]ボタンからGCPのプロジェクトを作成します。これを実行するとGCPアカウントにテストプロジェクトが作成されて、APIの実行準備が整います。GCPに慣れているのであれば自分でプロジェクトを作成してもOKです。 この後、自動的に「credentials.json」というファイルがダウンロードされます。このファイルは認証ファイルです。重要なので忘れずに保存するようにしましょう。 https://developers.google.com/analytics/devguides/reporting/data/v1/quickstart-client-libraries 3. GA4にGCPサービスアカウントを設定する 一つ前のステップでダウンロードしたファイルを開くと、[email protected] のようなメールアドレスに似た文字列があります。これを以下の手順でGA4のユーザーとして追加します。権限は閲覧者のみで構いません。 GA4の「管理」を開きます 「アカウントのアクセス管理」を開きます 右上のボタンからユーザーを追加します 4. Google Analytics Data API を実行する これでGoogle Analytics Data API を実行する準備が整いましたので、実際にスクリプトを書いていきましょう。2. で保存した credential.json もスクリプトと同じフォルダに入れておきます。 PHPでAPIを実行する場合、オフィシャルのライブラリがあるのでこれを利用します。まず以下のようにcomposerをインストールします（インストール済みの場合はスキップします）。 php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" php -r "if (hash_file('sha384', 'composer-setup.php') === '55ce33d7678c5a611085589f1f3ddf8b3c52d662cd01d4ba75c0ee0459970c2200a51f492d557530c71c15d8dba01eae') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" php composer-setup.php php -r "unlink('composer-setup.php');" そしてGoogle Analytics Data APIのライブラリをインストールします。 ./composer.phar require google/analytics-data ライブラリをロードするには、composerのお約束で vendor/autoload.php をrequireします。ライブラリのクラス群はGoogle\Analytics\Data\V1beta\ 名前空間の下にありますので、これらを必要に応じてuseします。 また、GA4にアクセスするための認証情報をセットする必要があります。これは環境変数で行いますが、PHPの場合はputenv関数を使うとスクリプト内から環境変数をセットできます。 <?php require 'vendor/autoload.php'; putenv('GOOGLE_APPLICATION_CREDENTIALS=' . __DIR__ . '/ga4-api-******-**********.json'); use Google\Analytics\Data\V1beta\BetaAnalyticsDataClient; ... 最初に触れたとおり、現在APIで実行できるのはレポートの作成のみです。早速作ってみましょう。 レポートの作成はGA4の「プロパティ」に対して実行されます。プロパティにはIDが割り振られていて、それを確認します。IDは「管理」のページなどにあります。 プロパティID これらを踏まえ実際のスクリプトを記述していきますが、やることはとても単純で、BetaAnalyticsDataClient を作成してrunReport()を実行するだけです。ただ渡すパラメータが少し複雑なので、実際にコードを見てもらう方が理解が早いかと思います。 試しに日付毎のセッション数をレポートにしてみたいと思います。 <?php require 'vendor/autoload.php'; use Google\Analytics\Data\V1beta\BetaAnalyticsDataClient; use Google\Analytics\Data\V1beta\DateRange; use Google\Analytics\Data\V1beta\Dimension; putenv('GOOGLE_APPLICATION_CREDENTIALS=' . __DIR__ . '/ga4-api-******-**********.json'); $client = new BetaAnalyticsDataClient(); $response = $client->runReport([ 'property' => 'properties/320171287', 'dateRanges' => [ new DateRange([ 'start_date' => '7daysAgo', 'end_date' => 'today', ]), ], 'dimensions' => [ new Dimension( [ 'name' => 'date', ] ), ], 'metrics' => [ new Metric( [ 'name' => 'sessions', ] ), ] ]); foreach ($response->getRows() as $row) { foreach($row->getDimensionValues() as $v) { print "dimension: " . $v->getValue() . "\t"; } foreach ($row->getMetricValues() as $v) { print "metric:" . $v->getValue() . "\n"; } } 出力例は以下です（数値はダミーです）。 dimension: 20220905 metric:99999 dimension: 20220906 metric:99999 dimension: 20220901 metric:99999 dimension: 20220831 metric:99999 dimension: 20220902 metric:99999 dimension: 20220904 metric:99999 dimension: 20220903 metric:99999 "dateRange", "dimensions", "metrics"でレポートに出力される項目を決めることができます。今回使ったdate, sessions以外にも、GA4でおなじみのディメンションを使うことができます。一覧が以下のスキーマドキュメントにありますので確認しましょう。 https://developers.google.com/analytics/devguides/reporting/data/v1/api-schema またrunReport()関数に渡せるパラメータもいろいろあります。今回私は実際の業務で dimensionFilter を使いました。これは名前の通りディメンションを絞り込んで出力させるもので、たとえばURL毎のセッション数を出すときに、特定の文字列を含むURLだけを抽出することができたりします。これは以下のようなコードになります。 $client->runReport([ "dimensionFilter" => new FilterExpression([ 'and_group' => new FilterExpressionList([ 'expressions' => [ new FilterExpression([ 'filter' => new Filter([ 'field_name' => 'landingPage', 'string_filter' => new StringFilter([ 'match_type' => MatchType::BEGINS_WITH, // 前方一致 'value' => '/hogehoge', // フィルタする文字列 ]) ]), ]), ], ]), ]), ... パラメータの一覧は以下のページで見ることができます。 https://developers.google.com/analytics/devguides/reporting/data/v1/basics おわりに ユニバーサルアナリティクスの提供終了がアナウンスされてからしばらく経ちました（提供終了は2023年7月1日）ので、Googleアナリティクス4への移行も進んでいるのではないでしょうか。Googleアナリティクス4はマーケティングツールではありますが、Webやアプリに関わるエンジニアにとっても有用なツールです。自分が関わっているプロダクトに関する数字を把握するのは大事です。 Google Analytics Data APIを使うとスクリプトを活用した高度な分析が行えるでしょう。またレポートのオートメーションもやりやすくなります。 PHPはWeb系エンジニアで書ける人が多いので、そのスキルをそのままデータ分析に生かせるメリットは大きいでしょうか。この記事とサンプルコードがお役に立てば幸いです。 それではまた次回お目にかかりましょう。