はじめに BASE Order Section でWebアプリケーションエンジニア をしている Capi(かぴ) です。 2026/3/20（金）- 3/22（日）の3日間、BASE株式会社もゴールドスポンサーとして協賛した PHPerKaigi 2026 が開催されました。今回はPHPerKaigi 2026に参加したメンバーのコメントや感想をお届けします！ PHPerKaigiとは PHPerKaigiは、オープンソースのスクリプト言語 PHP （正式名称 PHP:Hypertext Preprocessor）を使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。コミュニティ貢献活動の一環として、今年もゴールドスポンサーとして協賛しました。 登壇者コメント 川島慧 モジュラモノリスを導入してから4年が経ち、「そろそろ答え合わせができるのでは」という気持ちで今回の発表に臨みました。 「何を解決しようとしているのか分からないままマイクロサービス（orモジュラモノリス）を開始しようとするのはほとんど悪いアイディアだ」という、技術主導は大抵誤りであるという意識を４年前からずっと持って挑んできました。結果的に思いがけないつまづきもありましたが、無事に解決するべきIssueの解像度が上がった４年間でした。 スライド中では「AIに要約させながら読むことを推奨」と書いたのですが、アップロード後に試してみると、意外なことにChatGPTやGeminiでは何度訂正させても全く違う内容が返ってきました。どうやら100枚超のスライドをAIに要約させるのはまだ難しいようです。ClaudeとNotebookLMだとある程度うまくやってくれます。 個人的にはかなり痛手です。これほどの文量を読むエンジニアは今の時代にまずいないので、ほとんどの人に届かない内容になってしまったと思います。スライドを読む際はご自身の目でしっかり読んでいただくか、動画を見るか、ClaudeまたはNotebookLMあたりににお願いするのがおすすめです（個人の感想です）。 speakerdeck.com プログラミングをするパンダ セール開始のバッチのパフォーマンスをチームで改善したという話を共有しました。発表後に「うちでも遅いバッチがある」という話を聞いたり、「しっかり遅いことに気づいて改善に持っていける体制が作られているのが素晴らしい」とお褒めの言葉をいただいたりしました。 特にポストモーテム共有会をやっているということが今回のバッチの改善の起点になったのですが、その取り組みがとても良いと言ってもらうことが多く、ポストモーテム共有会も別のメンバーが始めていたので大変ありがたいなと思っています。 スライドの最後の方でも触れましたが、今回の発表を機にもう一段改善できるところを見直そうと思うので、さらに早くできるのではないかなと思っています。当日発表を聞きに来てくださった方、ありがとうございました。そうでない方もぜひスライドを一度ご覧ください。皆様のお役に立てれば幸いです。 speakerdeck.com 02 PHP8.5に追加されたarray_first / array_lastの歴史的背景について話しました。5分という短い時間で7年分の議論の流れを追いましたが、重要な話はできるだけ削らずに伝えられたと思います。 さまざまな観点から議論を重ねて未解決の疑問をなくす必要がある一方で、発散した議論はスコープを絞ったり、特定の観点を重視して仕様を決めたり・・・仕事の進め方やファシリテーション、マネジメントなど、普段のプロダクト開発で重要な力が、RFCの採択においても重要だという所感を感じました。 PHP Internalsの議論の流れを追う中で学びが多く、今回のarray_first / array_last以外の議論も追ってみたいと思いました。興味を持った皆さんも、まずは参考文献のURLからarray_first / array_lastの議論を追ってみてください！ speakerdeck.com パンフレット記事執筆者コメント meihei 「カンファレンスが終わったあとに」というパンフレットを寄稿しました。先日のPHPerKaigiでは多くの学びがあったかと思います。それらを自分の中で、またチームメンバーとともに知識として再構築し、今後さまざまな機会で活かせる武器にしてもらえたら嬉しいです。 パンフレットはマンガで解説していますので、お気軽にお読みください！ 現地で見たセッションを一部紹介 当日イベントに参加した自分含む弊社メンバーが現地で見たセッションのうち特に気になったセッションのレポートです！ 1. 「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜 by 武田 憲太郎さん 高トラフィックを捌く技術的な解決を自信持って行うためにできることを紹介していただきました。アプリケーションコードよりもミドルウェアの話が中心でした。 Keep Alive、Persistent Connection、コネクションプール… 単語は知っているけれど自分が使いこなせていないものがたくさん出てきて非常に勉強になりました。スライドには図やグラフ、コードが添付されていたので難しい内容でも理解しやすかったです。興味のある方はぜひスライドだけでもみていただきたいです。オススメです。 自分は登壇の中で武田さんがおっしゃっていた「計測は仮説を持って行う」という言葉が印象に残っています。また、登壇を聞きながらシステムの接続はとても奥が深く技術者の腕の見せ所なのではないかと考えました。 (BASE Order Section @Capi) 2. プログラミング言語論から覗くPHPの正体 by うさみけんたさん 「PHPがどんな歴史を積み重ね、今の書き方になったのか」を紐解いていきました。PHPがゆるふわ言語というのは自分もなんとなく理解していますが、想像以上にゆるふわ言語であることを知り、PHPらしさを再度認識する良い機会になりました。 また、登壇の中ではPHP作者Rasmus Lerdorf(ラスマス・ラードフ)氏の発言を取り上げていました。言語作者の人となりを知るのも面白いなと登壇を聞きながら考えました。なぜ言語が作られたのか、どんな思想で言語が成長してきたのかを知ることでその言語への愛着が強まります。 登壇で出てきたこのスライドが自分は好きです笑 (BASE Order Section @Capi) 3. 俺の/私の最強アーキテクチャ決定戦開催 ― チームで新しいアーキテクチャに適合していくために by 髙橋直規さん 持続可能なチーム開発を目指す中で、「アーキテクチャを刷新する必要があるが、トップダウンで決めるのは避けたい」という背景から、「最強アーキテクチャ決定戦」を開催したという内容のライトニングトークでした。 2人程度で似たようなイベントを開催したことはありましたが、経験値に差があるチームで実施したことはなかったため「すべての処理を神メソッドで実現する」という提案のハードルを下げるための工夫や、イベントの流れなど開発チームの運営において大変参考になる内容が多かったです。（Pay ID Engineering Section 岡部 @rerenote） 4.AI時代の脳疲弊と向き合う ~言語学としてのPHP~ by さくらいさん 日々の業務の中で、何かしらAIとやりとりする機会が増えています。その中で、抽象的な内容を具体的な表現に落とし込む場面が以前より多くなっていると感じていました。また、AIと長時間やりとりした後に強い疲労感を覚えることも増えてきています。 このライトニングトークでは、こうした疲れがどこから生じるのか、そしてその対策について解説されていました。対策の中でも「意識して時間を使い分ける」はすぐに実践できそうだと感じ、早速取り入れています。以前と比べて、疲労感を覚える場面が少なくなってきたように感じています。（Pay ID Engineering Section 岡部 @rerenote） おわりに 去年に引き続きレポーターとしてPHPerKaigiに参加させていただきました。 今年も協賛活動、社員のスピーカー参加を通して PHPコミュニティの盛り上がりに貢献でき、弊社としても大変有意義な時間となりました。 スタッフの方々には業務でお忙しいにも関わらず、多くの時間をイベント準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。

こんにちは。SCSKの井上です。 この記事では、New Relic APM エージェントを導入した後に、アプリケーション監視画面をどのように読み解けばよいかを解説します。インフラとアプリケーション双方の状態を理解することで、ボトルネックを特定し、問題の早期発見や性能改善につなげられるようになります。 はじめに アプリケーションを安定して動かすには、どの処理に時間がかかっているのか、どこで性能低下が起きているのかを把握することが重要です。New Relic APM を使うことで、アプリケーション内の動きを可視化し、ボトルネックの発見や改善ポイントの特定が迅速に行えます。APMエージェントの導入方法については、過去の記事からご確認いただけます。 【New Relic】分散トレーシングの仕組みとPHPへのAPM導入 複雑なマイクロサービス環境で、障害の原因を素早く特定するには分散トレーシングが欠かせません。本記事では、分散トレーシングの仕組みとAPMをPHPアプリに導入する手順もあわせて解説します。 blog.usize-tech.com 2026.02.05   APMのUI構成 この画面ではAPMの見方を解説します。 主要部分UI New Relic APM の Summary 画面は、サービスの状態を一目で把握できるように、役割の異なる4つのエリアで構成されています。上部のフィルタ、ヘルス指標、時間範囲、右側のアクティビティなど、各エリアが いま何が起きているか”を素早く理解する手がかりになります。まずは、この4つのエリアがそれぞれどんな役割を持っているのかを簡単に説明します。   エリア 内容 1.画面上部のフィルタ & 表示切替エリア どの条件でデータを見るか（比較・フィルタ） 昨日・先週の同時間帯との比較、web全体像やAPI単位での絞り込み等 2.ヘルス指標パネル サービスの健康状態の概要（異常の早期発見） 3.期間選択 データの時間範囲を選択（変化点の確認） 4.アクティビティ履歴 & 関連エンティティ デプロイ・関連サービスなどのヒント（依存関係調査）   APM 概要ページを使用したトラブルシューティング | New Relic Documentation With the New Relic APM summary page, run diagnostics with application monitoring tools to quickly resolve incidents. docs.newrelic.com 実際にSummary画面に表示されている情報を解説していきます。 【Web transactions timeの推移グラフ】 アプリの遅延要因が「どこで発生しているか」「いつ発生しているか」 を読み取ることができます。    【Throughputの推移グラフ】 アプリがどれくらいの数のリクエストを処理しているかを示します。急激な増加や低下もなく、負荷が一定している場合はリクエストが安定していると読むことができます。 【エラー発生率の推移グラフ】 アプリ側のロジックや特定の処理で断続的にエラーが出ているかを確認できます。Throughputの上下と連動している場合は、負荷が原因でエラーが増えている可能性があると読むことができます。   【Transactions】 最も遅い5件のトランザクションが表示されています。 平均応答時間は速いが最悪時は非常に遅いトランザクションがあります。処理が遅い原因はSlowest traceの時間をクリックすることで深堀することができます。 【Logs】 実際のエラー内容や例外スタック” を直接確認できます。エラー率は上がっているのに原因が分からない時は、最後にLogs を開いて実際にアプリがどんな状態なのかを確認します。 【Infrastructure】 アプリ側に問題がない場合、インフラ側のCPUスパイク・メモリ不足などが原因のケースも多く、その兆候をまとめて確認できます。Infrastructureエージェントが導入されている場合に表示されます。   Distributed tracing 分散トレーシングとは、ネットで商品を注文するような1つの操作が、裏側でいくつものサービス（ログイン確認、在庫チェック、支払い処理など）を通って処理されるときに、それぞれのサービスで”いつ始まって、いつ終わったか”を記録して、全体の流れを見えるようにするしくみです。   ディストリビューティッド（分散）トレーシング：マイクロサービス全体でリクエストを追跡 | New Relic Documentation What is distributed tracing? An intro to New Relic's distributed tracing feature. docs.newrelic.com Servicemap (Maps) サービスマップでは、システム全体の構成要素（ユーザー体験、サービス、インフラ、アプリ）とそれらの依存関係を可視化しています。この画面は主に 障害発生時の影響範囲分析や、依存関係を把握してトラブルシューティングを行うときに使います。 システム全体の構成要素を役割ごとに分類して依存関係をわかりやすくするため、4つに分類されています。この分類により、どの層で問題が発生しているかを迅速に特定し、影響範囲を把握することができます。 マップ上の階層 説明 User experience ユーザーに直接影響するフロントエンドやUI関連のエンティティ Services アプリケーションのビジネスロジックやAPIなど、サービス層のコンポーネント Infrastructure サーバー、ホスト、ネットワークなど、サービスを支える基盤 Engineering operations デプロイ、CI/CD、アラートなど、運用や管理に関する要素 赤枠のRelationship depthは、サービスマップで表示する依存関係の階層の深さを設定します。どこまで依存関係を掘り下げて表示するかを制御する設定で、障害調査時に影響範囲を広く見るか、直接関連だけ見るか、を切り替えるために使います。 サービス マップ: エンティティを視覚化する | New Relic Documentation New Relic's service maps are visual, customizable representations of your application architecture. docs.newrelic.com Dependencies システム内のエンティティ(アプリケーション、サービス、DB、ホストなど)が他のエンティティにどのように依存しているかを示します。Service Mapはシステム全体のアーキテクチャを視覚化に対して、Dependenciesは特定のエンティティが依存しているリソースやサービスに焦点を当てています。Relationship列にて選択したEntityとの接続関係を示します。対象のエンティティから見て上流（called from)や下流（called to）の依存関係があり、どのサービスがどれに依存しているかを確認できます。 Dependencies UI。エンティティのアップストリームおよびダウンストリームの依存関係の表示 | New Relic Documentation An entity's dependencies page shows the selected entity's upstream and downstream dependencies for apps, services, datab... docs.newrelic.com   Transactions アプリケーションのリクエスト処理状況を可視化し、どのトランザクションが遅いのか、どの時間帯に負荷が高いのか、リソース使用率がどうなっているかを把握するために使います。主に、レスポンス遅延やサーバー負荷の原因を特定する際に役立ちます。 Sort by 意味 利用シーン 活用例 Most time consuming 合計処理時間が最も長いトランザクション アプリ全体のパフォーマンス改善 サービス全体の遅延要因を特定し、最適化対象を絞る Slowest average response time 平均応答時間が最も遅いトランザクション ユーザー体験の改善 UXに悪影響を与えている処理を特定し、応答時間を短縮 Highest error rate エラーが最も多く発生しているトランザクション 障害対応・品質改善 エラーの多い処理を調査し、例外処理や再試行ロジックを見直す Throughput (calls per minute) 最もリクエスト数が多いトランザクション 負荷対策・スケーリング 高頻度の処理に対してキャッシュ導入やスケールアウトを検討 Apdex by most dissatisfying ユーザー満足度が最も低いトランザクション 顧客満足度の向上 Apdexスコアが低い処理を改善し、ユーザー離脱を防ぐ   上記画面のトランザクションをクリック後、パフォーマンス状況を詳細に把握することができます。トランザクションに絞った平均応答時間、スループット、エラー率、レスポンス時間の内訳などを分析できます。主にボトルネックの特定や遅延原因の詳細調査に使います。   Histrical Performance 過去のパフォーマンスデータ(yesterday,lastweek)を時系列で可視化・比較分析ができます。 利用シーン 説明 目的・メリット 傾向分析 過去のレスポンス時間やエラー率の推移を確認 パフォーマンスの悪化や改善の兆候を把握 障害調査 特定の時間帯に発生したスパイクやエラーを分析 インシデント対応・根本原因分析 リリース影響確認 デプロイ後のパフォーマンス変化を比較 新機能や修正の影響を定量的に評価 キャパシティプランニング 時期や時間帯ごとの負荷傾向を把握 サーバー増強やスケーリングの判断材料 改善施策の効果測定 チューニング前後のパフォーマンスを比較 最適化の成果を確認し、次の施策に活かす ユーザー体験の推移確認 Apdexスコアの変化を時系列で確認 UX改善の効果を測定し、満足度向上へ   Databases アプリケーションのデータベースの状態やパフォーマンスを示します。どのデータベース操作に時間がかかっているのか、どの時間帯に負荷が高まっているのか、接続試行の状況などを確認できます。アプリケーションのレスポンスが遅くなったときや、ピーク時の負荷を監視したいとき、頻繁に時間がかかるクエリを特定して、インデックスの追加やSQLの改善を検討する際にも役立ちます。 ソート方法は以下3パターンが利用できます。 Sort by 意味 利用シーン 具体例 Most time consuming 合計実行時間が最も長いクエリ。頻度と実行時間の両方を考慮。 パフォーマンスに最も影響を与えているクエリを特定し、最適化対象を絞る。 頻繁に呼び出される SELECT * FROM  が全体のDB時間の50%を占めている。 Slowest query time 単一実行で最も時間がかかったクエリ。 異常に遅いクエリや、インデックスが適切に使われていないクエリ、非効率な結合処理を含むクエリを特定する。 一度だけ実行された JOIN クエリが5秒以上かかっていた。 Throughput (calls per minute) 単位時間あたりのクエリ実行回数（通常は1分あたり）。 負荷の高い時間帯や、スケーリングの必要性を判断する。 毎分1000回以上 INSERT INTO logs が実行されており、DB接続が逼迫している。   External services External services(外部サービス機能)は、サービス間の依存とボトルネックを可視化し、応答時間が急に長くなった場合や、外部API呼び出しがボトルネックになっているか、サービス間の依存関係や遅延の原因を調べたいときに使います。   外部サービス | New Relic Documentation The external services page captures metric details about out-of-process services such as web services, cloud resources, ... docs.newrelic.com JVMs Javaアプリの内部状態（メモリ・CPU・スレッドなど）をリアルタイムで可視化し、パフォーマンスや障害の兆候を早期に発見できる機能です。 JVMページ（Java）：JMXからアプリサーバーのメトリクスを表示 | New Relic Documentation APM's JVM page for Java: Thread pools, HTTP sessions, and transactions; WebSphere PMI and WebLogic JMX metrics. docs.newrelic.com Threads Threads機能は、スレッドが何をしているのかを観察するツールです。アプリケーションの中では、いろんな処理が同時に動いていることが多く、これらの処理はスレッドと呼ばれます。 Threadsの特徴 ：関数やメソッド単位で時間を特定、CPU消費の可視化、スレッド動作分析、全体のコード実行状況把握 使用シーンと具体例 ：アプリ遅延、CPU高負荷、並列処理の詰まり、トランザクショントレースでは見えない問題       スレッド状態 意味 次のアクション RUNNABLE 実行可能状態。CPUを使って処理中またはすぐに処理できる状態 多すぎる場合は、CPU負荷が高い可能性 → 処理の最適化やスレッド数の調整を検討 WAITING 他のスレッドの通知を待っている状態（例：Object.wait()） 長時間待機している場合は、同期処理の見直しやロックの解消を検討 TIMED_WAITING 一定時間待機している状態（例：Thread.sleep()） 不要な待機がないか確認。待機時間の短縮や非同期処理への変更を検討 BLOCKED 他のスレッドがロックを保持していて、処理できない状態 ロック競合が発生している可能性 。ロックの粒度を下げる、非同期化などの改善策を検討 NEW スレッドが作成されたが、まだ開始されていない状態 多すぎる場合はスレッド管理の見直しを検討 TERMINATED スレッドが終了した状態 終了済みなので問題なし。ただし異常終了がないかログ確認は有効   Identity Security for the Digital Enterprise | Ping Identity support.pingidentity.com   Vulnerability APMエージェントを活用してアプリ全体の脆弱性状況を可視化・依存関係の脆弱性を自動検出し、CVSSやランサムウェア情報に基づいて修復の優先度を決定します。AWS Security Hub の調査結果やAWS GuardDuty と Inspector の結果をインポートし、ダッシュボードまたはNRQLで表示することもできます。 AWS セキュリティ統合 | New Relic Documentation Send your security data from AWS Security Hub, GuardDuty, and inspector directly to New Relic. docs.newrelic.com   All Vulnerabilities 脆弱性が CVSS（重要度）、EPSS（悪用可能性）、ランサムウェア使用状況のデータに基づいて優先度順にランク付けされています。 優先順位付けにより、アプリの公開範囲や影響に応じた対応計画が立てやすくなります。 アラート設定も可能なため、継続的な脆弱性管理を提供できます。   Security RXを使い始める | New Relic Documentation Use Security RX to identify blindspots and remediate vulnerabilities docs.newrelic.com アプリケーションの脆弱性の優先順位を理解する | New Relic Documentation Learn how Security RX prioritizes application vulnerabilities based on CVSS, EPSS, and active ransomware data. docs.newrelic.com   Apps Overview APMエージェントを使ってアプリ依存ライブラリの脆弱性を自動検出し、CVSSやEPSSなどで優先順位を付けて修復を支援します。組織全体／個別アプリの視点で脆弱性状況を可視化することができます。 画面 内容 確認観点 ①Total vulnerabilities 検出された脆弱性の総数と重大度別件数 全体のリスク規模を把握 ②Vulnerability exposure window 脆弱性が放置されている期間を重大度別に表示（ヒートマップ） 長期間放置されているCritical脆弱性は最優先で対応 ③Library status 脆弱性を含むライブラリの件数（Critical、High、その他） ライブラリ単位でアップグレード対象を確認 ④Service・APM status APM監視サービスの脆弱性状況（CriticalやHighを含むサービス数） 影響範囲をサービス単位で把握 ⑤High priority vulnerabilities 優先度の高い脆弱性一覧（CVE番号、重大度、優先度スコア） 修正すべき脆弱性を特定 ⑥Top library upgrades 脆弱性解消のためにアップグレードすべきライブラリ一覧（現行バージョンと推奨バージョン） アップグレード計画に活用 ⑦Top vulnerable entities 脆弱性が最も多いエンティティと重大度分布（赤＝Critical、オレンジ＝High）を表示 Criticalを含むエンティティは最優先で対応   DevSecOps、プラットフォーム、セキュリティチームとしてアプリケーションの脆弱性を管理する | New Relic Documentation Monitor and remediate application vulnerabilities across your entire organization with Security RX. docs.newrelic.com   アプリケーションの脆弱性を管理 | New Relic Documentation Monitor and remediate vulnerabilities in a specific application with Security RX entity-scoped views. docs.newrelic.com 障害対応の流れ(一例) 障害対応は最初の一手で混乱しがちですが、まずは全体をざっくり見るところから始まります。もちろん、アラートで原因がほぼ特定できているケースや、過去の経験からこのサービスが落ちると大体ここが怪しいと目星がつく場合もあります。その場合は、最初からSummary画面を見ることも多いです。状況によって入り口は変わりますが、どこが赤くなっている？どのサービスが遅れている？と俯瞰しておくと、全体像が掴みやすく、原因の方向性も自然と見えてきます。この記事では、私が New Relic を使って実際に辿っている障害調査のステップをまとめました。   1.全体像の把握（どこで起きているか？） 今どこで何が起きているのかをざっくり掴むところからスタートします。個人的には、障害対応の時はアタフタしがちなので、まずService Mapで全体の流れを眺めます。赤くなっているサービスや、突然応答が遅くなっている部分がないか？この時点で、障害が特定のサービス単体なのか、依存関係（上流・下流）によるものかを確認します。   2. サービス概要の確認（何が起きているか？） 対象のサービスを特定したら、APMのSummaryページでGolden Signals（応答時間・リクエスト数・エラー率）を確認します。普段と比べてどうなのかを確認したいときは、「Compare with yesterday/last week」 を使うと異常が出始めたタイミングが一目でわかります。エラーのスパイクや、普段ない遅延が出ていれば、ここで気づくことができます。   3. 原因の深掘り(どんな処理の流れか？) 次は Transactions を確認します。ここを見ると「/api/v1/data が妙に遅いな…」みたいに 遅延の正体がスッと腑に落ちる瞬間があります。さらに掘るときは Transaction Trace が便利で、どのメソッドが重いのか、どの SQL が詰まっているのか、ここで原因の目星がつきます。   4. エラーの詳細確認（なぜ起きたか？） エラーが増えているときは Errors Inbox が頼りになります。似たようなエラーをまとめてくれるので、「エラーが多すぎて追えない」という状況でも、原因パターンが整理されます。   5. 外部要因の調査（データベース・外部API） アプリ側が正常でも、依存先が遅れているだけ、というのはよくあります。Databases で遅いクエリを確認したり、External Services で外部 API（決済・認証など）の応答遅延を調べるのも重要です。インフラ側の CPU・メモリ・ネットワーク I/O も見ておくと、原因を取りこぼしにくいと言えると考えています。   さいごに この記事では、New Relic APM が提供する主要な可視化機能や、日々の運用で役立つ画面の見方について解説しました。APM を活用することで、アプリケーション内部の処理を詳細に把握でき、ボトルネック調査や性能改善に役立てることができます。また、トランザクションの流れや外部サービスとの連携状況、データベース処理の負荷といった運用上重要なポイントを多角的に分析できる点も大きな特徴です。APM のデータを Infrastructure やログ、分散トレースと組み合わせることで、アプリケーションとインフラ全体を通した統合的な可視化が可能になります。これにより、個別のコンポーネントだけでなく、システム全体を俯瞰した観点での最適化や改善にもつながります。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

はじめに 普段はRuby, PHP, Typescriptを主に使ってアプリ開発をしているITエンジニア4年目のY.Mです。 AWSを勉強していく中で、「サービスめっちゃ多い」とか「どんな用途で使えばいいか毎回忘れる・混乱する」なんて経験ありませんでしょうか？ また、実際にAWSを触ってみて、VPC・ECS構築やCI/CD自動化などで「今自分って何でこの操作しているんだろう．．．」と思うことありませんでしょうか？ 自分はもうすぐ社会人4年目を終えるところで、AWSもちょこちょこ触ったりしているのですが、あまり頻繁に構築したりもしていないせいか、悲しいことに忘れてしまうこともかなり多いです。 そこで、どうしたらAWSを包括的にかつ長期的に概念を覚えられて、実務にも活かせるんだろうと考えていました。その時に思いついたのが、今回執筆する AWSの全体像をスーパーマーケットに例える という内容です。身近なものに例えて、脳に長期記憶を促そうといった狙いです。 今回の記事は、 AWSの基本構成を包括的に理解したい AWSの概念を長期記憶化したい といった初級者向けの記事になっています。 私は、実務ではCloudWatchでのログ監視やS3バケットへのデータ格納は使っていますが、正直AWSの理解が断片的であったり、1からAWSサービスを構築した経験はほぼないので、これを機にAWSのサービスを包括的に覚えてみようと思いました。私も実際にこの例えを活用したことで、AWSに対する全体の理解が一気に深まりました。 今回、身近なものに例えていくため、厳密な定義ではないところもあるかもしれませんが、この記事にて 「包括的」かつ「長期的」 にAWSサービス全容の大枠な理解が深まれば幸いです。 AWSの学習ロードマップ 今回、AWSの全体像を掴んでいくにあたって、 AWS学習ロードマップ （制作者 くろかわこうへいさん、小山雄太さん）が非常に有用だなと思ったので、こちらを使って解説していきます。 上記URLから、PDFでAWS学習ロードマップをダウンロードできます（営利目的の使用は厳禁と記載があります）。 こちらの学習ロードマップですが、全部でセクション数が12個あり、大きく3つに区切ると綺麗かなと思ったので、3つに分けてそれぞれ図解も交えて解説していきます。 AWSの基本構成 （Section 7まで） サーバレスなサービス導入 （Section 10まで） 分析・マルチアカウント作成 （Section 12まで） AWSの基本構成 (〜Section 7) AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例 (サービスはめ込み版) 解説 ここでは、スーパーマーケット、隣接する工場やオフィス、そして面している道路を使ってサービスの解説をしていきます。無色・薄い灰色のエリアがパブリック空間（一般市民が出入りできる空間）・濃い灰色のエリアがプライベート空間（専用の人間しか入れない空間）になっています。 AWS（Amazon Web Service） 概要：Amazonが提供するクラウドコンピューティングサービス 例示：地域全体 AWSは、Amazonが提供するクラウドコンピューティングサービスで、シェアNo.1を誇っています。 AWS空間にて、サーバーの構築・管理までを一貫して管理する集合体になります。 実世界では、地域全体と同等になるかと思います。 Route53 概要：ドメイン名を検索してIPアドレスに変換するサービス 例示：自動車のカーナビ Route53は、ドメイン名をIPアドレスに変換することで、コンピュータ内部で通信できるようにする役割を持っています。 例えば、「mynavi.jp」が入力されたら、「3.165.11.119」といったように変換されて通信されます。 これが、実世界では自動車のカーナビ（目的地名を入力し、ナビでもわかるようにピン表示へ変換する）でも同様なことが言えると思いました。 CloudFront 概要：コンテンツを近くから配信し、高速通信を可能にするサービス 例示：配送センター CloudFrontは、コンテンツを近くから配信することで、低遅延・データ転送性能向上を可能にするサービスで、コンテンツをキャッシュする役割を持っています。 実世界では、配送センター（中継所）のようなイメージで、遠方の倉庫から運搬してきた荷物を配送センターで保管し、必要な時に配送センターから届けることで、より短い時間で出荷可能になるのと同様になるかなと思います。例えば、スーパーで発注した食材が必要になった時に、倉庫（県外にあるとする）から出荷すると運送時間に比例して、鮮度やおいしさが落ちてしまうリスクがあります。ただ、配送センターから出荷を行うと、短い運送時間で出荷ができるため、新鮮な状態で食材を届けられるというイメージです。 ACM（AWS Certificate Manager） 概要：SSL/TLS証明書を管理できるサービス 例示：公認バッジ ACMは、SSL/TLS証明書を発行・更新・管理することで、安全な通信の一助を担うサービスになっています。 先ほどの配送センターの場合、配送センター自体が本物なのか、或いは悪徳業者が運営しているのかといった見分けが一般市民からは分かりません。そのため公認バッジを発行することで、本物・信頼の証であることを証明でき、安心安全な運送が提供できることを市民へも理解させることができます。 S3（Simple Storage Service） 概要：データを保存・取得できるストレージサービス 例示：倉庫 S3は、静的なデータ（ファイル・画像など）を保存・取得できるストレージサービスです。 実世界では、巨大な倉庫に例えるのが妥当です。 VPC（Virtual Private Cloud） 概要：専用のプライベート仮想ネットワーク 例示：スーパーマーケットの敷地内全体 VPCは、論理的に分離されたプライベートの仮想ネットワークです。この中で、EC2やRDSなどの個人情報が絡むサービスを設計していきます。 今回は、スーパーマーケットの敷地内全体が、プライベートの仮想ネットワークに該当します。 以降のサービスは、VPC内のサービス（スーパーマーケット内）を中心に解説をしていきます。 Internet Gateway 概要：VPCの内外間で通信を行うサービス 例示：スーパーマーケット駐車場出入口（警備員） Internet Gatewayは、VPC内部とインターネット間を通信するためのサービスです。 グローバルIPアドレスをプライベートIPアドレスへ変換し、セキュリティ機能を担保しながら通信する役割を持っています。 実世界に例えると、スーパーマーケットの駐車場の出入口に該当します。この出入口付近で警備員が立っており、怪しい市民を排除することで、スーパーマーケット内の安全性を高めています。 Public Subnet 概要：ブラウザから直接アクセスすることができる領域 例示：スーパーマーケットの商品陳列エリア Public Subnetは、ブラウザから直接アクセスできる領域になります。 実世界では、スーパーマーケットの商品陳列エリアに該当します。ブラウザを世界中の人間の集まりだとした時に、スーパーマーケットで通常の人間が入れるエリアは限られていて商品陳列エリアは入れるものの、従業員専用のバックヤードや有人レジの中には入ることができません。 Private Subnet 概要：ブラウザから直接アクセスすることができない領域 例示：スーパーマーケットのレジ（捜査側）・従業員専用部屋 Public Subnetに対して、Private Subnetはブラウザから直接アクセスできない領域になります。 実世界では、スーパーマーケット内のレジ（操作側）や従業員専用部屋など、一般の人が入れない領域に該当します。 ALB（Application Load Balancer） 概要：サーバに負荷を分散させるためのサービス 例示：レジの案内係 ALBは、サーバに負荷がかからないように適切に通信量を分散するサービスになります。 実世界では、レジの案内係に例えることができます。買い物客が一つのレジに集中的に並んでしまった場合、レジが混んでパンクしてしまいます。それを防ぐために、レジの案内係を用意して、レジへ均等に人が並ぶように調整することで、人の流れを最適化しています。 ECS（Elastic Container Service） 概要：完全管理型のコンテナオーケストレーションサービス 例示：レジ管理人 ※私の調べた限りだと、AWS学習ロードマップの各Private Subnetに置かれているECSはEC2インスタンスであり、それらのコンテナを管理するサービスがECSだったので、それを基に解説します。スーパーマーケット例では修正しています。 ECSは、アプリケーションを動かすためのコンテナを効率的に自動管理してくれるサービスです。 EC2インスタンスへの通信量に応じて、必要なコンテナ（タスク数）を自動増減してくれる役割を持っています。 スーパーマーケットでは、レジの管理人に例えることができて、レジに待つ人に応じて、稼働するレジの台数を増減する指揮官のような役割を果たします。 EC2（Elastic Compute Cloud） 概要：クラウド上の仮想サーバサービス 例示：レジ本体 EC2は、クラウド上の仮想サーバサービスで、アプリケーション本体を動かす根幹を担っています。 スーパーマーケットでは、レジ本体に例えることができて、店舗自体もレジ（売上収集）が存在するからこそ営業することができます。 RDS（Amazon Relational Database Service） 概要：クラウド上の仮想データベースサービス 例示：PC上での売上管理 EC2がサーバであれば、RDSはデータベースサービスになります。 スーパーマーケットでは、レジの売上データに例えることができて、一般人が入れない場所（今回の例では本社オフィスに置きました）で管理しています。 IAM（Identity and Access Management） 概要：役割に対する権限を管理するサービス 例示：スタッフの従業員証 IAMは、役割に対する権限を管理するサービスで、統合管理にあたってセキュリティを強固にする役割を持っています。 実世界では、スタッフの従業員証が該当します。有人レジの操作や従業員更衣室、本社オフィス内部など、一般の人が立ち入ることが禁止されているエリアにて、スタッフの従業員証（IAMロール）が付与されていれば、そのエリアへ入ることができるイメージです。 NAT Gateway（Network Address Translation） 概要：プライベートサブネット内から外部へ通信をするためのサービス 例示：従業員専用部屋（バックヤード）の出入口 NAT Gatewayとは、プライベートサブネットから外部へ通信するためのサービスになり、EC2インスタンスで構築されたアプリケーションから外部APIの接続など、インターネット側で通信したい時に使われます。 実世界では、バックヤードの出入口に該当します。お店の開店前に、レジでの売上金をATMへ入金する時や、発注商品の受け取りなどを行うイメージです。 CodePipeline 概要：CI/CDを自動化するためのサービス 例示：製品組立の現場監督 CodeDeployとは、アプリケーションを自動化するための管理サービスです。GitHubでソースコードの変更を検知したときに、ビルド・デプロイを一貫して自動で行ってくれる役割を持っています。 これを実世界に例えると、依頼された製品の組み立て・取り付けを監督する現場監督員が妥当です。製品の組み立てから取り付けまで一貫してサポートします。 CodeBuild 概要：自動テストやビルドを実行してくれるサービス 例示：製品の組み立て CodeBuildとは、ソースコードの自動テストやビルドを実行してくれるサービスです。 実世界では、現場監督管理のもとで、依頼分の製品の組み立てを行います。 ECR（Elastic Container Registry） 概要：コンテナイメージの保存・共有ができるサービス 例示：完成製品の保管庫 ECRとは、ビルドが完了したイメージの保存や共有ができるサービスになっています。 実世界では、完成製品の保管庫が近いかなと思います。AWS学習ロードマップでは、NAT GatewayとECRがつながっていることより、従業員がバックヤードから出て製品を確認できるようなイメージです。 CodeDeploy 概要：ソースコードの反映を行うサービス 例示：製品の取り付け CodeDeployとは、ソースコードの反映を行うサービスです。 上記のスーパーマーケットの図の例だと、顔認証システムの製品を取り付けているイメージです。 余談ですが、最近AI顔認証決済というものが出てきていて、事前に登録した本人の顔にクレジットカードを登録しておくと、財布やスマートフォンを出さずに登録したクレカで会計ができるみたいです…笑 世の中の進化で、どんどんデジタル化が進むなあと思い知らされます。 https://jpn.nec.com/fintech/face_settlement/index.html CloudWatch alerm 概要：AWSサービス監視にて使用率が閾値を超えた場合にアラートを検知するサービス 例示：異常検知センサー CloudWatch Alermとは、AWSサービス監視にて使用率が閾値を超えた場合にアラートを検知するサービスです。 実世界では、異常検知センサーが近いと思います。レジが混んできて待ち時間が長くなってきた場合に、スーパマーケット内の異常検知のセンサーの作動・放送が行われるイメージです。作動後は次で説明する「SNS」にて解説します。 SNS（Simple Notification Service） 概要：ユーザへメールを送信するサービス 例示：緊急連絡先センター SNSとは、ユーザへメールを送信するサービスを表しており、対策メンバーへの周知を行う役割を担っています。本ケースでは、Cloudwatch alermからアラートを受け取ったタイミングで、メールを送信するような流れになっています。 実世界では、レジの待ち時間が長くなってきた時にセンサーが発動し、緊急連絡先センターに連絡が届き、当該店舗の従業員へ応援を要請するようなイメージです。 Terraform 概要：オープンソースのインフラコード 例示：街を再現する設計図 Terraformとは、Hashicorp社が開発したオープンソースのインフラコードで、AWSの構築内容をコードで管理するサービスです。 具体的には、街を再現するための設計図のようなイメージです。仮に街で災害が発生して建物や周辺の道路が損壊してしまった時に、設計図が無いと元に戻すことはできません。そこで設計書があることで、万が一街が壊れてしまっても、構築内容を元通りに戻すことができます（ただし、ECSやRDSといった中身のデータは復元できないので注意してください）。 サーバレスなサービス導入（〜 Section 10） AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例　（サービスはめ込み版） 解説 Section7までで説明した基本構成より、オフィス内で分業化をしました。これまでオフィスにあったサービスはシステム部へ、今回説明する部署を総務部へそれぞれ部署を分割しました。総務部の中で、Lambdaを用いたサーバレスなサービスの解説をしていきます。 API Gateway 概要：APIリクエストの集中管理・ルーティング制御を行うサービス 例示：受付窓口スタッフ API Gatewayは、APIリクエストの集中管理やルーティング制御を行うサービスで、どのサービスにアクセスするかを振り分ける役割を担っています。 実世界では、総務部で働いている受付窓口スタッフに該当します。ここで受け取ったお問合せ内容について、誰に仕分けてもらうかを振り分けるのと同等になります。 WAF （Web Application Firewall） 概要：攻撃と思われる通信を遮断するサービス 例示：受付窓口スタッフ （門番役） WAFは、SQLインジェクションやXSSなどの攻撃などと思われる通信を遮断するサービスで、脆弱性を狙った攻撃攻撃に防ぐ役割を持っています。 先ほど説明した受付窓口スタッフは、お問い合わせ内容の仕分けだけでなく、怪しい人が入ってきた場合はオフィスへの侵入を阻止させることで、内部処理を安全に実行することができます。 Lambda 概要：サーバレスでプログラムを実行できるサービス 例示：作業者 Lambdaは、クラウド上に直接プログラムを定義・実行するサービスです。サーバ構築も不要であり、複雑化した機能ではなく1つの機能を実行するときに役立ちます。 今回の例では、作業者（仕分け人、実行者、回答作成者、感謝文面作成＋手紙送付者）に例えることができます。このように1つの作業の橋渡し役となる大事な役割を担っています。 DynamoDB 概要：高速なNoSQLデータベース（RDSと対で使われる） 例示：問い合わせ内容の記録簿 DynamoDBは、高速なNoSQLデータベースであり、RDS（高度なMySQLデータベース）とは対で使われる。RDSは高度なSQL操作ができるが取得に時間がかかり、DynamoDBはキーバリュー型（具体例として後述）で高度なSQL操作ができないものの、高速（数ms単位）で取得可能です。 今回の例では、スーパーマーケット利用者から頂いた問い合わせ内容の記録簿として機能を果たします。問い合わせ内容は、名前（キー）と問い合わせ内容（バリュー）で紐づけることができるため、検索が容易で高速に取り出すことができます。 SQS（Simple Queue Service） 概要：メッセージを受信・保存し、順番に送信するサービス 例示：お問い合わせ書類 SQSは、メッセージを受信・保存し、順番に送信するサービスです。 今回の例では、作業者（仕分け人）が仕分けたお問い合わせ書類が保管されており、作業者（実行者）によって処理されるイメージです。 Step Functions 概要：実行対象のワークフローを自動化できるサービス 例示：現場マネージャー Step Functionsは、実行対象のワークフローを自動化できるサービスで、今回はLambda関数を順番に実行する処理を管理しています。 オフィス（総務部）の例では、作業者（回答作成）→作業者（感謝の文面作成＋送付）の流れが問題なく動いているかを、現場マネージャーが監視しています。 Bedrock 概要：高機能な基盤モデル（FM）を搭載したサーバレス生成AIサービス 例示：専門家 Bedrockとは、高機能な基盤モデル（FM）に基づいて、サーバレスな生成AIを実現するサービスです。RAGと呼ばれる最新・関連情報を優先的に検索できるデータベースを使い、その知識を基に学習をしています。 実際には、作業者の回答作成の手助けをする専門家が妥当だと思います。専門家の長年培ってきた知識情報を駆使できるため、生成AIに近い表現ができると考えられます。 SES（Simple Email Service） 概要：クラウド型のメール送信・受信サービス 例示：郵便ポスト SESとは、クラウド型のメール送信・受信サービスで、受け取った回答情報を問い合わせをしたユーザへメールを送信する役割を果たしています。 今回の例では郵便ポストに例えられて、回答作成した内容を郵便ポストに投函し、やがて利用者の手元へ届く流れとなっています。 分析・マルチアカウント対応 （〜 Section 12） AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例（サービスはめ込み版） 解説 Section10の段階から新たに赤枠の部分である、データの分析・マルチアカウント対応・監視体制の強化が加わったことで、活用かつ堅牢であるサービス構成になったのかなという感じがしています。実際にスーパーマーケット版でも、本社オフィスのシステム部が追加されて、それぞれシステム部内で部署が新たに新設されたことで対応できていることが確認できると思います。このように、データの利活用・監視を市街地でも実施していくことで、安全なまちづくりを行える意向が伺えます。 また、追加した部署の概要は下記になります。 データ管理部 ：データの分析・可視化を行う部署（Glue, Athena, QuickSight） 店舗監視部 ：店舗の設備情報・利用者の動向を監視する部署（AWS Config, CloudTrail, GuardDuty, SecurityHub） 統制部 ：店舗全体のルール作成を行う部署（AWS Organizations, ControlTower, Terraform） Glue 概要：DBに登録されているデータの収集・変換を行うサービス 例示：スーパーマーケットの売上データの収集・変換 Glueとは、DBに登録されているデータの収集・変換を行うサービスで、データの分析や可視化をしやすい状態にする役割を持っています（＝SQL実行できる状態にします）。 今回の例では、DB＝スーパーマーケットの売上データになっており、分析・可視化しやすい状態にします。 Athena 概要：変換されたデータに対して、SQL実行を行うサービス 例示：売上データ（売上高・購買率など．．．）の分析 Athenaとは、Glueによって変換されたデータに対して、SQL実行を行うことで、データ分析ができるサービスです。 今回の例では、スーパーマーケットでの売上データをデータ単位で見やすくするようにします（例：利用者Aさんは今月10万円お買い物した、利用者Bさんの今月の購買率は40%だったなど．．．）。これにより、スーパーマーケットの運営改善を行うことができます。 QuickSight 概要：変換されたデータに対して、データの可視化を行うサービス 例示：売上データ（売上高・購買率など．．．）の可視化 QuickSightとは、変換データに対して、データの可視化を実施できるサービスです。AthenaはSQL実行して指定したデータを抽出するのに対して、QuickSightはグラフを用いて可視化する役割を持っています。 今回の例では、スーパーマーケットの利用者単位での売上高・購買率の可視化などが挙げられます。 AWS Config 概要：AWSの構成情報を管理するサービス 例示：スーパーマーケット内のレジ台数・従業員数の管理 AWS Configでは、EC2やRDSなどのサービスの設定を管理するサービスで、変更履歴も検知しています。 スーパーマーケットの例では、本社オフィスの店舗監視部が店舗内のレジ台数・従業員数を管理しており、変更をした場合は、具体的な日時まで記録しておくイメージです。 CloudTrail 概要：AWS内の操作を記録・保存するサービス 例示：店舗でのレジ利用者の行動監視 CloudTrailとは、AWSの中で行われた操作を「いつ・誰がしたか」という形式で記録・保存するサービスです。 スーパーマーケットの例では、各店舗でのレジ会計時に、利用者のログを記録して監視している表現が近いかなと思います。 GuardDuty 概要：AWS上のセキュリティの脅威を継続的に検出するサービス 例示：店舗の不審者・侵入者検知 GuardDutyとは、AWS上にてセキュリティの脅威がないかを継続的に検出し続けるサービスです。 スーパーマーケットの例では、店舗内で不審者・侵入者がいないかを継続的に検知し続け、発見次第アラートを鳴らすイメージが近いかなと思います。上記で説明した「CloudWatch Alerm」と一定の基準でアラート発動という観点で同一なのですが、それぞれ検知する種類が違いがあります。 GuardDuty：「悪意あるアクセス」を検知（＝侵入者を検知） CloudWatch Alerm：「リソースの逼迫」を検知（＝混雑状況を検知） SecurityHub 概要：セキュリティ設定・監視を一元管理するサービス 例示：店舗監視部の一覧表示モニター SecurityHubとは、セキュリティ設定・監視を一元管理するサービスを表します。 本社オフィスの例では、店舗監視部が確認している設定情報の管理（AWS config）、利用者の行動監視（CloudTrail）、不審者検知（GuardDuty）を、一覧でモニターに映し出すのと同等になります。 AWS Organizations 概要：複数のアカウントを一元管理するサービス 例示：各店舗リストの保管 AWS Organizationsは、複数のアカウントを一元管理するサービスになっています。 本社オフィスの例では、各店舗（本店舗だけでなく、A店、B店、C店など）のアカウント情報を一元管理するイメージです。 AWS ControlTower 概要：複数のアカウント管理にあたって、AWSのセットアップをしてくれるサービス 例示：各店舗のマニュアルブック AWS ControlTowerは、複数のアカウント管理にあたってAWSのセットアップを行うことで、ベースラインが構築できるサービスです。 本社オフィスの例では、各店舗に対応したマニュアルブックを指します。マニュアルがあることで、スーパーマーケットの規範が成り立つので、本サービスと同等の役割を果たします。 最後に 本記事では、約40のサービスを載せていたAWSの全体像に対して、スーパーマーケットを中心とした街で例えてみました。 それぞれのサービスについての説明もしましたが、各サービスの概要・役割のみの説明で、技術的な詳細な説明はしていないので、気になるサービスは調べていただけたらと思います。 僕もこの記事執筆から、ここで紹介しきれていないサービス含め、さらなるAWSサービスへの理解を深めていけたらと思います！ 最後に、スーパーマーケット図示完成版を下記に共有いたします。