本記事では、AWS CDK（Cloud Development Kit）を用いて、ECSとRDSの監視アラーム、ECSのオートスケーリング、そしてそのイベントをSlackに集約する通知基盤をIaCとして一括で構築する方法を解説します。

監視・通知アーキテクチャの全体像

採用するアーキテクチャは以下の通りです。

事前準備: AWS ChatbotとSlackの連携

CDKデプロイの前に、AWSアカウントとSlackを連携させるためのAWS Chatbotクライアントを作成しておく必要があります。

1. AWS Chatbotコンソールで、Slackワークスペースとチャンネルを連携させます。
2. この設定により、通知先のSlackチャンネルIDとワークスペースIDが取得できます。これらはCDKコード内で使用します。

監視とオートスケール基盤の構築

今回は、ECSサービスとRDSインスタンスが既に存在することを前提に、その監視・スケール設定を定義するCDKスタックを作成します。

CDKスタックのセットアップ

必要なCDKライブラリをインポートし、スタックを定義します。

// lib/monitoring-stack.ts

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as sns from 'aws-cdk-lib/aws-sns';
import * as cloudwatch from 'aws-cdk-lib/aws-cloudwatch';
import * as actions from 'aws-cdk-lib/aws-cloudwatch-actions';
import * as events from 'aws-cdk-lib/aws-events';
import * as targets from 'aws-cdk-lib/aws-events-targets';
import * as autoscaling from 'aws-cdk-lib/aws-applicationautoscaling';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as chatbot from 'aws-cdk-lib/aws-chatbot';

// 環境依存の定数を定義 (適宜置き換えてください)
const CLUSTER_NAME = 'your-ecs-cluster-name';
const SERVICE_NAME = 'your-ecs-service-name';
const RDS_IDENTIFIER = 'your-rds-instance-identifier';
const SLACK_CHANNEL_ID = 'C01234567'; // 取得したチャンネルID
const SLACK_WORKSPACE_ID = 'T01234567'; // 取得したワークスペースID

export class MonitoringStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 既存のECSサービスを参照
    const ecsService = ecs.FargateService.fromFargateServiceAttributes(this, 'ExistingEcsService', {
      serviceArn: cdk.Stack.of(this).formatArn({
        service: 'ecs',
        resource: 'service',
        resourceName: `${CLUSTER_NAME}/${SERVICE_NAME}`,
        sep: '/',
      }),
      cluster: ecs.Cluster.fromClusterAttributes(this, 'ExistingCluster', {
        clusterName: CLUSTER_NAME,
        vpc: ({} as any), // 参照のため空オブジェクト
        securityGroups: [],
      }),
    });
  }
}

通知用SNSトピックとChatbotの設定

アラームやイベントが通知を送るSNSトピックを作成し、それをAWS Chatbotに連携させます。

// 1. 通知用SNSトピックの作成
    const alarmTopic = new sns.Topic(this, 'AlarmTopic', {
      displayName: 'System-Monitoring-Notifications',
    });

    // 2. AWS ChatbotとSNSトピックの連携 (Slackへのルーティング)
    new chatbot.SlackChannelConfiguration(this, 'ChatbotConfig', {
      slackChannelConfigurationName: 'EcsRdsMonitoring',
      slackWorkspaceId: SLACK_WORKSPACE_ID,
      slackChannelId: SLACK_CHANNEL_ID,
      notificationTopics: [alarmTopic], // このトピックへの通知がSlackに送られる
    });

ECSとRDSの監視アラーム設定

主要なメトリクスに対してCloudWatchアラームを作成し、アクションとして上記SNSトピックを設定します。

// --- ECS Fargate アラーム ---
    // ECS CPU利用率が80%を超えた場合にアラーム
    const ecsCpuAlarm = new cloudwatch.Alarm(this, 'EcsCpuHighAlarm', {
      metric: cloudwatch.Metric.fromNamespaceAndName('AWS/ECS', 'CPUUtilization').with({
        dimensionsMap: { ClusterName: CLUSTER_NAME, ServiceName: SERVICE_NAME },
      }),
      threshold: 80, 
      evaluationPeriods: 2,
      comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
      alarmDescription: 'ECS Service CPU utilization is too high.',
    });
    ecsCpuAlarm.addAlarmAction(new actions.SnsAction(alarmTopic));
    // ecsCpuAlarm.addOkAction(new actions.SnsAction(alarmTopic)); // 復旧時も通知したい場合は追加

    // --- RDS アラーム ---
    // RDS CPU利用率が70%を超えた場合にアラーム
    const rdsCpuAlarm = new cloudwatch.Alarm(this, 'RdsCpuHighAlarm', {
      metric: cloudwatch.Metric.fromNamespaceAndName('AWS/RDS', 'CPUUtilization').with({
        dimensionsMap: { DBInstanceIdentifier: RDS_IDENTIFIER },
      }),
      threshold: 70, 
      evaluationPeriods: 3,
      comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
      alarmDescription: 'RDS CPU utilization is too high.',
    });
    rdsCpuAlarm.addAlarmAction(new actions.SnsAction(alarmTopic));

ECSサービスのオートスケーリング設定

ECSサービスをCPU利用率$60%$を目標に自動スケーリングするように設定します。

// 3. ECSサービスのオートスケーリング設定
    // サービスのDesired Countをスケーリング対象にする
    const scalableTarget = autoscaling.ScalableTarget.forEcsService(this, 'EcsScalableTarget', {
      service: ecsService,
      minCapacity: 1, // 最小タスク数
      maxCapacity: 5, // 最大タスク数
    });

    // 目標CPU利用率 60% を維持するように調整するターゲット追跡スケーリングポリシー
    scalableTarget.scaleToTrackMetric('CpuScalingPolicy', {
      metric: ecsService.metricCpuUtilization(), 
      targetValue: 60,
      scaleOutCooldown: cdk.Duration.seconds(60),
      scaleInCooldown: cdk.Duration.seconds(300),
    });

// 4. オートスケールイベントを捕捉しSNSトピックへルーティング
    new events.Rule(this, 'AutoScalingNotificationRule', {
      description: 'Notify Slack on successful ECS Auto Scaling events.',
      eventPattern: {
        source: ['aws.application-autoscaling'],
        detailType: ['Application Auto Scaling Policy Execution'],
        detail: {
          // 成功したスケーリング操作のみを通知
          statusCode: ['Successful'], 
        },
      },
      // ターゲットは既存のSNSトピック
      targets: [new targets.SnsTopic(alarmTopic)],
    });

すみません。いきなり煽りから入ってしまいました。

最近、サーバー構築作業をしている中でセキュリティ担保の方法を学ぶことがあったので、皆さんに共有したいなーと思い記事を書いています！

EC2へSSH接続を行い、サーバーでの作業を行っているバックエンド側の人の幸せにつながってくれたら嬉しいです〜

EC2のSSH鍵の扱いどうしている？

複数人でプロジェクトを組んでいる場合、サーバーで作業をする人が複数出てくると思います。

そうなってくると以下の作業を 作業者の人数分 × サーバーの台数分 実施しなければいけなくなります。

1. 作業者Aのユーザーを登録
2. 各作業者のローカルでSSH鍵の生成 && サーバー上で公開鍵の登録

この時点で億劫ですね。

また、上記の作業に加えて 鍵の定期的なローテーション、チームの入退場が発生した時のユーザー管理が発生してしまいます。

死ぬほど面倒くさい！！！！！！！！

更にセキュリティに興味が無いメンバーが存在すると、鍵のローテーションはやらなくていいじゃんとか抜かすんですよ。。あー、面倒くさい。

ECS Instance Connect で解決しましょう

鍵のローテーションも面倒くさい作業も全てやらなくて済む方法が一つだけ存在するのです。

それが、AWSのコンソールパネルから該当EC2にSSH接続を行うことができる EC2 Instance Connect という機能です。

この機能は~/.ssh/authorized_keys に一時的なキーを付与するという特徴があります。

そのため、僕達ユーザーが鍵の管理をする必要がなくなるので、運用の手間をかなり減らすことができます。
（サーバー運用やったことにしか伝わらないと思いますが、管理するものを減らすという事は運用において絶大に効果があるのです！！！！

しかもこの機能、API と CLI にも対応しているのでちょっとした作業時にも効果があるのですよぉぉぉぉ！！！

基本的に権限さえ付与してしまえば使える機能ですので、皆さん使ってみて下さい！

一応セキュリティグループも絞っておこう

EC2 Instance Connect を使う際には、セキュリティグループで SSHのポート 22 を開放して置く必要があります。

22番ポートを開けるのは多少なりとも気が引けますよね〜

最低限のセキュリティ担保として、 EC2 が所属する Region のみからアクセスできるようにIP指定をすることができます。

下記のサイトにリージョン単位かつサービス単位でIP範囲をまとめてくれています。

https://ip-ranges.amazonaws.com/ip-ranges.json

今回の例でいうと ap-northeast-1 に所属するEC2のSSH接続を制限する場合は、 3.112.23.0/29 を セキュリティグループのIP範囲に指定してあげると良いです。

これで、IAMで認証されたユーザーかつ東京リージョンからのSSH接続に制限することができます。

    {
      "ip_prefix": "3.112.23.0/29",
      "region": "ap-northeast-1",
      "service": "EC2_INSTANCE_CONNECT",
      "network_border_group": "ap-northeast-1"
    },

幸せになりたい

運用負荷が下がると幸せになれます。

幸せになろう。

今回は、ソフトウェア開発の一環として非常に重要なインフラストラクチャ（以下、インフラ）についてお話ししたいと思います。

多くのプログラマーがコードを書くことに夢中になる一方で、インフラについてはあまり関心を持たないことがあります。
しかし、インフラに興味を持つことは、より強力でスケーラブルなアプリケーションを作成するために不可欠です。

インフラとは？

インフラとは、ソフトウェアが動作するための基盤となるハードウェア、ネットワーク、ストレージ、クラウドサービスなどを指します。これには、サーバーの設定、ネットワークの構築、データベースの管理、スケーリングのためのクラウドサービスの利用などが含まれます。

なぜインフラに興味を持つべきか？

1. パフォーマンスの最適化: インフラの知識があると、アプリケーションのパフォーマンスを最適化するための適切なリソースを選択し、設定することができます。
2. 信頼性の向上: 適切なインフラの設計は、アプリケーションのダウンタイムを最小限に抑え、信頼性を向上させるのに役立ちます。
3. スケーラビリティ: インフラを理解していると、トラフィックの増加に対応できるスケーラブルなアーキテクチャを設計することが可能です。
4. セキュリティの強化: インフラのセキュリティを強化することで、アプリケーションを攻撃から守ることができます。
5. 多角的な課題解決: プログラム以外の手段として、インフラの変更や最適化を考慮することで、課題解決の選択肢が増えます。例えば、コードの最適化だけでなく、サーバーのスケールアップやネットワーク設定の見直しも有効な解決策となります。

具体的に考えてみよう

例えば、あるウェブアプリケーションのパフォーマンスが悪く、ユーザーからのクレームが増えている状況を考えてみましょう。

この場合、最初に考えるのはコードの最適化かもしれません。
効率的なアルゴリズムを使用したり、データベースクエリを最適化することが効果的です。

しかし、これだけが解決策ではありません。

インフラ観点で考えてみましょう。

サーバーのスケールアップ

現在のサーバーがトラフィックに対応しきれていない場合、サーバーのスケールアップ（より強力なサーバーにアップグレード）を検討できます。

これにより、リソース不足によるパフォーマンス低下を防ぐことができます。

例えば、EC2インスタンスのサイズをt3.smallからt3.largeに変更することで、CPUとメモリリソースが増加し、パフォーマンスが向上する可能性があります。

ロードバランシングの導入

トラフィックが特定のサーバーに集中している場合、ロードバランサーを導入することで、トラフィックを複数のサーバーに分散させることができます。これにより、各サーバーの負荷が軽減され、全体のパフォーマンスが向上します。

AWS Application Load Balancer（ALB）を使用して、複数のEC2インスタンス間でトラフィックを分散することで、スケーラビリティと信頼性を向上させることができます。

また、ALBではパスルーティングを設定することが可能なため、重たい処理専用のサーバーで処理をするといったことも考えることができます。

その際にはログイン情報を引き継ぐといったことも考える必要が出てくるため、Redisなどのミドルウェアも視野に入れる必要があります。

サーバーレスの選択

AWS Lambda といったサーバーレスアーキテクチャを選択することも視野に入れると良いです。

サーバーレスを利用することで、サーバーの管理が不要になり、スケーリングも自動で行われます。

（Lambdaには制約があるので注意。この記事わかりやすいよ

キャッシュ戦略

結果をキャッシュサーバーに格納していこうぜぇぇぇ

ネットワーク設定の最適化

ネットワークの設定を見直し、遅延を最小限に抑えるための最適化を行うことも重要です。

例えば、コンテンツデリバリネットワーク（CDN）を使用して、静的コンテンツをユーザーに近い場所から提供することで、応答時間を短縮できます。

CloudFrontを利用して、画像やJavaScriptファイルなどの静的リソースをキャッシュし、グローバルに分散されたエッジロケーションから提供することで、ユーザー体験を向上させることができます。

具体的に何を学ぶべきか？

1. サーバー管理: Linuxの基本的なコマンド、サーバーのセットアップ、SSHの使用方法を学びましょう。
2. クラウドサービス: AWS、Azure、Google Cloudなどの主要なクラウドプロバイダーのサービスについて理解し、使いこなせるようにしましょう。
3. コンテナ技術: DockerやKubernetesなどのコンテナ技術を学ぶことで、アプリケーションのデプロイメントが効率的になります。
4. ネットワークの基礎: IPアドレス、サブネット、DNS、ロードバランシングなどの基本的なネットワーク概念を理解しましょう。
5. インフラストラクチャー・アズ・コード（IaC）: TerraformやCloudFormationを使用して、コードでインフラを管理する方法を学びましょう。

最後に

インフラの知識は、プログラマーにとって非常に有益です。

コードを書くことだけでなく、そのコードが動作する環境について理解することで、より優れたソフトウェアを作成することができます。
さらに、プログラム以外の手段としてインフラを活用することで、課題解決の幅が広がります。ぜひ、インフラに興味を持ち、自身のスキルセットを拡充していきましょう。

このブログが皆さんのインフラへの関心を高めるきっかけとなれば幸いです。次回もお楽しみに！

Zabbixとは？

Zabbixはエンタープライズクラスのオープンソース監視ソリューションであり、ネットワーク、サーバー、仮想マシン、およびクラウドサービスの監視に使用されます。このツールは、複雑なITインフラストラクチャの状態をリアルタイムで監視し、運用の効率を大幅に向上させることができます。

Zabbixの良いところ

1. コスト効率

Zabbixはオープンソースであり、ライセンス料が不要です。これにより、企業はコストを大幅に削減しながら、包括的な監視ソリューションを実装することが可能です。

そのかわりめっちゃ設定難しいです。書籍が出るくらいなので、すごく難しいです。

[getpost title=”Za” id=”1243″ cat_name=”1″ date=”0″]

Zabbix統合監視徹底活用──複雑化・大規模化するインフラの一元管理 Software Design plus

2. 柔軟性とカスタマイズ性

ユーザーは自由にカスタマイズして、自社のニーズに合わせた監視を設定することができます。これにより、特定の監視要件に対応するためのプラグインや追加機能を独自に開発することが可能です。

3. スケーラビリティ

大規模なネットワーク環境でも、Zabbixは高いスケーラビリティを持ち、数千台のサーバーを同時に監視することができます。

OSSの素晴らしさ

コミュニティとの協力

OSSは世界中の開発者が協力して作成・改善されるため、多様なアイディアや技術が組み込まれ、より速く、より安全なソフトウェアが生まれます。

透明性

ソースコードが公開されているため、誰でもコードを閲覧し、潜在的な問題を特定して修正することができます。これは、セキュリティの面で大きな利点です。

教育的価値

OSSを使うことで、技術者はより深い理解を得ることができ、キャリアの発展に役立つ知識とスキルを習得する機会を持つことができます。

先人は偉大だ

OSSの世界には無数の先駆者がおり、彼らの努力により、今日我々が享受している高度なテクノロジーが存在します。彼らのオープンな精神は、知識を共有し、全ての人が技術を利用できるようにすることで、ITの世界を豊かにしています。

OSSとしてのZabbix、またオープンソースの精神がいかにしてIT業界に革新をもたらしているのか、この記事が皆さんの理解の一助となれば幸いです。是非、この力強いコミュニティの一員として、OSSに参加し、貢献してみてはいかがでしょうか。

RDS

RDSの自動起動対策

RDSは7日間の停止後に自動で起動してしまう仕様が存在する。

稼働していないシステムで使用しているRDSは止めておきたいという要望が上がってきた。

7日間ごとに停止を手動で行うのは面倒くさすぎるし、ヒューマンエラーが発生する可能性がある。

そんな時に EventManeger にてRDSの自動停止を達成する事ができた。

やったこととしては、以下の通り。

• RDSの自動停止/起動 のスクリプトをLambda で定義
• Lambdaスクリプトを EventManeger にて7日周期で実行するように定義
  • 起動 → 停止 の順番で実行するようにしないと、RDS本体の再起動とLambdaスクリプトの停止処理が同時刻に実行されてしまい、自動停止が出来ないよ

Aurora

クラスターとインスタンスという概念がある。

Blue/Greenデプロイ

ダウンタイムを限りなく減らすデプロイ手法のこと。（2系統の環境を作成し、ユーザーが使用しているシステムに影響を少なくする）

当手法では、エンドポイントの切り替えを行う必要がないため、プログラマー目線だとかなり作業が楽。（インフラ担当の作業範囲で収まるため）

実際に経験したユースケースは以下の通り。

• RDS for MySQL の5系から8系へのアップグレード
• インスタンスサイズの変更

上記対応を行った際のダウンタイムは2 ~ 3分程度で切り替えが行われた。これはかなり凄いことだと思う。
以前までの対応だと、以下の対応があると思われるが、当手法ではコンパネから手軽に実施することができる。

• 本番環境とは別にMySQLサーバーを構築し、各種テストを実施後に現環境と旧環境の切り替え
  切り替え後はエンドポイントの切り替えを行う必要がある。
• システムメンテナンス期間を設け、現環境の変更を行う。

Blue/Greenデプロイは素晴らしい。。。

インスタンスタイプのサポート期日は守ろう

とあるタスクにて、RDSの インスタンスタイプのアップグレード & MySQLのバージョンアップ の作業があった。

その際の作業方法として、ダウンタイムを可能な限り削減するべくBlue/Greenデプロイを想定していたが、T2系インスタンスのサポートが終了していたため、Blue/Greenの作成が出来なかった。

本来であれば Blue/Green を作成後にGreen環境でインスタンスタイプのアップグレードとMySQLのバージョンアップを考えていたが、こうも上手くいかないとは思わなかった。

代替手段として、RDSのスナップショットからサポートされているインスタンスタイプで新規インスタンスを起動し、アプリケーションのエンドポイントを切り替える方法を考えたが、エンジニアが関与していないシステム（Redash等が上がっていたが、複数のサービスが連携していると報告が上がってきた）があるため、この手法は取れなかった。

そのため、エンドユーザーにダウンタイムを許容してもらう形で現行環境のRDSをインプレースで対応することになった。

エンジニアのプライドとして許せなかったが、前任の構築者が既にいなかったことやI/Oの遅さからユーザーからのクレームがあり早急に対応する必要があったので仕方がない結果となった。
（このタスクは他チームのインフラを面倒みることになっていたので余計に情報が絡み合ってめんどくさかった）

最終的には深夜作業で対応することになり、なんとか目的を達成することが出来た。

今後の教訓としては、インスタンスタイプのサポート期限は守ろう。

パラメータグループはデフォルトを使うな

時間がないからと言って、AWSが用意しているパラメータグループを使うな。

以下の問題が起きる

• Slow Query の出力がない
• クエリの実行時間の制限がない

問題の発生に気付けないのは大きな問題だ。

[getpost id=”1829″ cat_name=”1″ date=”0″]

EC2

Amazon Linux2023 は remiリポジトリが使えないぞ

Amazonlinux2023 はAWSさんが独自で管理しているOSらしいので、remi リポジトリがサポートされていない。

epel も使えない。

Q: AL2023 は AL2 のような Amazon-Linux-Extras を搭載していますか?

A: いいえ。AL2023 には extras はありません。言語ランタイムなどの高レベルのソフトウェアパッケージの場合、四半期ごとのリリースを使用して、リポジトリで提供されるデフォルトパッケージに加えて、個別の名前空間化されたパッケージとしてメジャー/マイナー更新をパッケージに追加します。 例えば、Amazon Linux 2023 のデフォルトの Python バージョンは 3.8 である可能性がありますが、Python 3.9 (python39) が利用可能になると、別の名前空間化されたパッケージとして追加されます。これらの追加パッケージは、アップストリームリリース頻度とサポートモデルに厳密に従います。また、それらのサポートポリシーは、コンプライアンスとセキュリティのユースケースのために、パッケージマネージャーによってアクセスされることがあります。デフォルトパッケージは、AL2023 の存続期間を通じてサポート対象であり続けます。

サポート切れの PHP7.4 を使いたいという要件を達成するため、PHPの公式サイトからソースをビルドする事を考えたが、 php-fpm の導入及び関連する拡張機能の有効化の方法が分からなかったため、当手法は断念。

代わりに Rocky Linux を選択し、remi リポジトリからPHP7.4のインストールを行った。

（そもそもサポートの切れている言語Version 使うなよというお話でした

OSのメンテナンスは定期的に

10年近く稼働している一度もOSの再起動を行ったことのない EC2 のメンテナンス作業を行うタスクがあった。
（何で誰も手つけて来なかったの？馬鹿じゃないの？

構築した人は既におらず、インスタンスの中身がどうなっているかわからない状況だったため、作業前に以下の対応を行った。

• EBS バックアップ取得
• AMI バックアップ取得
• インスタンスの中で使用しているプログラムについての調査
  • 各種言語のバージョン(拡張機能
  • cron
  • シェル
• VPCの構成

とりあえず結果からいうとデータの損失等が発生せず作業を終了することができた。

（やったこととしては、インスタンスサイズのアップグレード と ストレージのアップグレード。

若者に伝えたいのが定期的にメンテナンスを行うことと運用がしやすいように設計書なり構成図なりを残すこと。
（まじで何でも良いので、データとして残すことをオススメします。分かる人が見たら多少ズレのある設計書でもなんとなく予想がつくため。

ALB

リスナールールのデフォルトルールは503返したほうが無難

ALB は2つ以上のパブリックサブネットを設定する必要があります。

Route53 の Aレコード にALBのエイリアスを設定している場合は、ALBのパブリックIPが返ってくるようになる。

nslookup xxxx.com

返却されるIPにアクセスするとALBで設定されているリスナールールに従った、ルーティングが行われる。

そのため、リスナールールのデフォルトルールが APPサーバーへのルーティングを行うターゲットグループを指定すると ALB のパブリックIP でアクセスすることができるようになってしまう。

これの怖いところが、EC2のセキュリティグループでは弾くことが不可能なため、意図しないルーティングが行われてしまう可能性があることです。

直近、 us-west-2 から大量のアクセスが来てしまい、アプリケーションサーバーが落ちるといった事業が発生してしまった。
リスナールールの設定は適切に。。。

[getpost id=”2083″ cat_name=”1″ date=”0″]

炎上案件とは？

何らかの理由でとにかく燃えている案件のことです。

• シンプルな短納期（多分炎上の理由1位）
•  チーム内における重要人物のプロジェクトからの離脱
• 神様（クソ客）による土壇場での仕様変更
• イキり営業による全てできますスタイルによる契約

プロジェクトに関わるすべての人が何かしらに追われている状況になるため、関係者各位で揉め事が起こっています。
ステークホルダー > 営業 > PL > SE > プログラマー

僕が経験した炎上案件では、短納期 + 急な仕様変更（馬鹿な営業のせい） により開発と営業の間で戦争が勃発しプロジェクトが崩壊しかけた事があります。
最終的には客先への調整（謝罪） + 営業と開発の戦争に部長が仲裁する形 で終着することでギリギリのところで丸く収まりました。

しかし一度崩壊しかけたプロジェクトなのでチーム内でのいざこざは残ったまま開発を続けていくことになりストレスの掛かるプロジェクトでした。

このように炎上案件は誰も幸せになりません。

今回は炎上案件について僕の実体験を簡潔にお話したのですが、一口に炎上案件と言っても様々な理由があることを覚えていただければ幸いです。

炎上するとどんな事が起きるのか

お客さんに詰められる

受託企業における一番恐ろしいタイミングがお客様から詰められる時です。
当たり前の話ですが、身銭を切ってシステム開発を依頼されているので、全力で詰めてきます。

お客さんが詰めるときはだいたい以下の理由かと思います。

• 納期に間に合わない
• 契約時に想定していた要件を満たせていない

これらの理由で怒られるのが本当に本当にストレスでした。(契約不履行と言われたときにはゾッとします。

上長から詰められる

お客様から詰められるということは必然的に上司からも詰められます。

お客さんからの評価が悪いと次回の契約や会社の評判が下がるといった悪影響が発生する可能性が高くなるため、上司もピリピリします。

炎上は炎上を生むだけです。

メンバーから不満が出る

他方から詰められるとチーム内からも悲惨な声が聞こえてきます。

「後少しでリリースできるから一緒に頑張りましょう。」という声がけしかできません。

世知辛いです。

炎上したときには死ににいく姿勢が大事

ようやく本題です。

炎上案件に参画すると全員が「この案件から抜け出したい」と願っている事は目に見えるのですが、そういった願いは儚く散っていきます。どうにか納品することが唯一の地獄からの脱出する道です。

全員がギリギリのところで踏ん張っているタイミングでは率先して死にに行く姿勢がメンバーを勇気づけると考えています。

一度プロジェクトを崩壊させた目線から思うことが誰かがアクセルを踏んで頑張ることが誰かの活力につながることを強くお伝えしたいです。

今炎上案件に参画している人はぜひ、死にに行く姿勢を持ってほしいなと思います。（限界だったら逃げてください。本当に逃げてください。）

炎上案件は悪いことばかりではない

精神的にしんどい事が多い炎上案件ですが、悪いことばかりではありません。

サイヤ人の理論と一緒でギリギリのところで生き抜くと確実に成長します。成長するのは技術力かもしれませんし、人間力かもしれません。

とにかくあなたの何かが確実に成長します。

また、炎上案件の凄いところが普通に過ごした期間と炎上案件に関わった期間の成長の度合いに大きな差があります。

それだけ炎上案件には人を成長させるパワーがあります。

一度経験しておくのをオススメしますよ。

[getpost id=”1204″ target=”_blank” cat_name=”1″ date=”0″]

エンジニア歴は短いのですが、これまでに以下の形態の会社で働いてきました。

• SES
• 受託
• 自社

そんな僕からエンジニアとして働くべき会社を解説します。笑

SES 時代

入社した経緯

まずは SES 時代です。

当時の僕は異業種からの IT 業界への転職を目指していたこともあり、IT 業界に対する知識が全くない状態でした。

そのため手当たり次第に面接を受けまくっていた記憶があります。（今考えるとかなりアホですね。笑）

当時の世界情勢的にはコロナが大流行していた時期ということもあり、求人数はかなり狭めらていた状況でした。
そのような中、転職活動を進めていくにあたり戦略として以下の対策を講じました。

• 自作のウェブアプリケーションを作る
• 資格を取得する
• 技術記事を書く

[getpost id=”606″ cat_name=”1″ date=”0″][getpost id=”590″ cat_name=”1″ date=”0″]

転職活動という大航海を戦うには心細い能力値の低い武器を揃えて旅に出ていたため、条件の悪い求人にしか出会うことが出来ませんでした。

そんな中、あるSES会社と出会い入社をしました。

• 僕の揃えた武器に対して「君は努力のできる人だと思う」と評価
• 先輩のアセットとしてシステム開発の現場に入れてもらえる

中々良い出会いが無い未経験からの転職活動だったので、このSES会社に出会えた事はとても嬉しかったです。

業務内容

本当に末端の作業員だという内容の業務をこなしました。（未経験で入社したのでそれは仕方がない）

具体的には以下のような内容です。

• テスト仕様書に沿ってテストを実施する
  • エビデンスをスクショし、 Excel に貼り付ける
• HTML で書かれているページを Excel におこす
  • 現在の画面を仕様書に残すため
  • Git 使えや。クソが。
• データ移行（DB移行）
  • これは勉強になった

良かったこと

未経験からの IT業界への初参入ということだったので、全てが学びになったという自負があります。

質問の仕方や会話の仕方など他の業界とは異なっている事を知れたのはエンジニアとしての学びでした（特に質問の仕方は何度もご指導いただきました。笑）

また、システム開発の概要を知れたのはかなり大きかったです。
多くの人がそれぞれの役割をこなし、納期や予算と戦いながらゴールに向かった進んでいく姿勢はプログラムを書くだけが仕事ではないという事を学ぶことが出来ました。

その他にも何かしらの病気を抱えている率が高いこと(生活習慣病、精神疾患)や小汚いおじさんに見える人が実はかなり稼いでいる事など業界 の知見が増えたのは人生の経験という観点からもすごく勉強になりました。

悪かったこと

悪いことを上げればキリがないのですが、特に印象深かったものを紹介します。

1. 先輩社員に意識を高く持っている人がいない（自社の先輩）
2. 商流が深すぎて末端の作業
3. 三次受けだが二次受けとして入場

特に1番の意識の高い人がいなかったという事は エンジニアとして終わっている と思います。

当時の僕もそうですが、経験のない人はその現場が IT業界 の全てだと思ってしまいます。

そのためそれがデフォルトとなってしまうため、害悪以外の何物でもありません。（当時は分からなかったのですが、今となってははっきり言えます）

技術力が低くても高い志は持つべきというのが僕の信念です。

SES をやめようと思った理由

未経験からIT業界を目指した理由である「システムを作ってみたい」という目標にたどり着くのに時間がかかってしまうと考えたため、転職しました。

未経験から拾ってもらったこの会社には恩しかないのですが、なんのために頑張っているかを考えた結果、次のステップに行く決意をしました。

今となっては当時の決断と行動は良かったと思っています。

受託会社時代

入社した経緯

当時はとにかく開発がしたいという気持ちがかなり強く、プログラムを書けるお仕事に就く事を目的に仕事を探していました。

当時のスキルセットというか僕の経歴上、なかなか僕自身が目指していた仕事に就くことは難しい状況でした。
その当時のスキルセットは以下になります。（未経験の実務経験1年に仕事があるはずがない

またスキルセットが薄い上に経歴もかなり汚れていたため、ハードルはかなり高い状況です。笑

これ以上経歴を汚さない + 目標にしていた業務内容（開発業務）の両方を達成するためには普通のやり方だと絶対上手くいかない事が目に見えていたので、派遣としてやっていこうと作戦を練りました。

派遣なら現場を転々としても履歴書には「202x年 x月 〇〇 入社」という形で書くことになるので、経歴が汚くなることを防ぐ事ができます。

また、開発業務に携わるのが難しいと判断したら次の現場に向かうのも正社員と比較して容易です。

上記の考えから以下の派遣会社に登録し、いくつかの面談を受けました。

作戦はズバリ的中し、受託開発を行っている企業にプログラマーとして派遣されることが決まりました。
この受託開発企業では3ヶ月の派遣期間が終了と同時に派遣元から引き抜きという形で正社員として入社させてくれたので何だかんだ運がよかったかもしれません。（かなりブラックでしたが笑）

良かったこと

本当に信じられないくらいの様々な経験をすることができました。

• 顧客との打ち合わせ
• 要件定義
• インフラ構築
• 開発
• テスト
• 運用

経験のない人間に上記のフェーズ全てを任せるのは企業としてはどうかと思うのですが、僕個人にはメリットしかない期間でした。

この企業で大きな学びとなったのは以下2点です。

1. 各フェーズにおける苦労
2. セキュリティ
3. システムはお金を稼ぐ手段でしかない

特に3のシステムはお金を稼ぐ手段でしかないはという考えは一生の宝物だと考えています。

顧客にとって必要なものは最新の技術を使ったシステムやおしゃれなUIで仕上げられた中身のないシステムではなく今、目の前にある課題を解決するシステムが必要であるということです。

この点をあまり理解していないエンジニアは肌感として多いと感じています。

「誰のため」や「何のため」を意識していかないと自己満で業務をこなすエンジニアになってしまうので皆さんもご注意を。笑

悪かったこと

とにかく色々な案件を掛け持っていたので労働時間がかなり長かったです。（詳細は以下の記事を。笑）

[getpost id=”1204″ target=”_blank” cat_name=”1″ date=”1″]

労働時間の問題さえなければ勉強になる状態ではあったので続けたかったのが本音になります。

たくさん勉強できたので個人的には満足な期間でした。

自社開発時代

入社した経緯

受託企業では短期間で様々な経験をすることができたのですが、基礎をすっ飛ばして目の前の案件を納期までに何とか動く状態にする事を目的に開発業務を行っていました。

簡単に言うと「保守性」「拡張性」「セキュリティ強度」が低い状態のシステムを作っていました。

エンジニアとしての能力値がかなり低い状態でしたので、次の現場ではちゃんとしたシステム開発を行っている企業に入社することを目標に転職活動を行いました。

ここでいうちゃんとしたシステム開発というのは以下のことを指します。

• セキュリティ意識が強いか
• 会社内でエンジニアの人権はあるか
  →人権ないと環境が整わないのでいい加減なシステム開発になりがち
• 強強エンジニアは在籍しているか
  →知見を元に良いシステムが何なのかを考えてくれるセーフティーライン

転職活動時は受託と自社に絞って求人を探していました。

Green と 転職ドラフト, TechClips ME（テックミー）を使って本当にたくさんの求人を精査しました。

• 前回の受託企業のような詰め込み型の令和の時代にそぐわない企業を避けるため。
• どちらもエンジニア向けのサービスであり、経歴書を充実させることで企業からのオファーが来るので結構おすすめです。

結果的に転職ドラフト経由で出会った自社開発企業の面接官が以下の事を言ってくれたので転職することを決めました。

• 君はまだまだ技術力が低い
• まだまだ知るべき事はたくさんある
• 私達の会社で勉強しながら成長しないかい？

良かったこと

いいものを作るというマインドが高い人に出会えた事が何よりも得難いものでした。

いいものを作るというマインドは過程の中では正しいプログラムの書き方やシステムとしてあるべき姿を目指すことになるので、確かな技術力の向上が感じられました。
（これが当たり前と言われればそうですが…

また技術力の向上と合わせて組織の作り方 も勉強になっています。

企業自体の従業員数は2000名ほどの人数を抱えているのですが、開発部は20名弱の組織体系です。

そのため正にこれからの組織という感じで、本当に価値のあるものを届けるために色々なアプローチを試しています。
優秀な先輩たちが「これを達成したい」と目標を定めて取り組む姿は、過程も含めて勉強になっています。（エンジニアである前に人間ですからね。笑）

悪かったこと

実際のところ、自社サービスを展開しているのですが毎月赤字という状況です。

どうにかこの状況を打開するために営業と開発が肩を組みながら頑張っている状況ですが、赤字という状況は肩身を狭くします。

現在、各数値が改善してきているので近いうちに黒字になってくれるはずでしょう。（希望的観測！）

所属会社の形態によって変わること

SES を悪く言うつもりはない

上記の表で SES の評価が高くないのは、僕が所属していた SES企業 があまり良くないところだったからです。

友達が所属している SES 企業の話を聞く限り、結構条件は整っているなぁという印象があります。

• 自社プレゼン会（自分で作ってきたものがプロダクトになる可能性）
• 案件選択性
• 以外にも平均勤続年数が高い

本当にピンキリです。

エンジニアスキル

エンジニアスキルは圧倒的に自社サービスが身につきます。

自社サービスに入社してよかったことにも記載したのですが、いいものを作るというマインドはかなり大きいです。

いいものを作ったところで売上が上がるとは限らないのですが、自分たちのサービスで下手なものを作るという事は絶対にしてはいけないことです。（わざわざ負債を抱える必要はない）

いいものを作るためには技術力が必要ですから、圧倒的に自社サービスが完勝です。

ビジネススキル

ビジネススキルは圧倒的に受託開発が身につきます。

理由はお客様は神様という構図が成り立つからですあり、お客さんとの調整をミスれば炎上してしまうという恐ろしい現実が待っているからです。

受託金額が高ければ高いほど無茶な要求をしてくるというのが肌感覚としてあったり、納期もなんやかんやで短く設定してきたりします。

また、ギスギスした社内であれば社内調整も必要のため、エンジニア業務以外の時間でかなりの労力が必要です。

顧客調整と社内調整の両方の観点からビジネススキルは受託企業の完勝です。

所属会社の形態によって変わらないこと

エンジニアである限り不変なことです。

技術力があり、所属先で価値を出せていること

上記が達成できている人はどの現場に行こうがどの形態で働こうが最強のエンジニアです。

所属会社の形態に関わらず大切にしないといけないこと

会社の形態によって特徴が違うのですが、学ぶべき点はどの形態の会社に行っても必ずあります。

そのため、1エンジニアとして最大限学ぶためにはプロジェクトの中心にいることが大切になってきます。

• テックリード
• スクラムマスター
• 上流担当

「自社サービスで末端の作業員をやっています！」という人よりも「SES で俺がプロジェクト回しているぜ」っていう人の方が圧倒的に市場価値は高いです。

どの形態で働こうがこの考えは大切にするべきです。

最後に

どの形態の会社で働くにせよ、自身の技術力を向上させ、プロジェクトで中心的な役割を果たすことを大事にしてください。

自分自身が何を考え、何を大事にするかで選択は変わってくると思います。

経験を通して学び、スキルを向上させ、満足の行くキャリアを歩めるように祈っています。お互いに頑張りましょう。

1. 僕が考えるRDS を激推する理由
   • バックアップが楽ちん
   • 死活監視が楽ちん
   • フェイルオーバーが楽ちん
2. まとめ

僕が考えるRDS を激推する理由

バックアップが楽ちん

RDS を推したい理由の上位にくるのがバックアップの手軽さです。

AWS の公式にも記載がある通り、バックアップを自動で取ってくれます。

過去に クラウドサーバー 上にインストールした MySQL のバックアップ手法として、cron にて AWS SDK for PHP を用いて S3にダンプファイルを保管する手法を取っていた自分からすると RDS のバックアップはかなり楽ちんです。
だって、以下の設定が不要になりますからね。笑

1. AWS SDK for PHP のインストール
2. cron にて日次の実行処理を記述
3. S3 に送信処理を記述

デフォルトで有効になっている Amazon RDS の自動バックアップ機能により、データベースとトランザクションログがバックアップされます。Amazon RDS では DB インスタンスのストレージボリュームのスナップショットを自動的に作成し、個々のデータベースだけではなく、その DB インスタンス全体をバックアップします。

このバックアップは、バックアップウィンドウと呼ばれるユーザーが設定可能な 30 分間隔の時間に 1 日 1 回行われます。自動バックアップは、お客様が設定した日数の間、保持されます (バックアップ保持期間と呼ばれます)。自動バックアップの保持期間は、最大 35 日間まで設定できます。

Amazon RDS のバックアップと復元

また、 RDS には自動バックアップに加えてポイントインタイムリカバリという機能があり、特定の時点に戻すことができます。（5分毎にデータベースの変更ログのアーカイブが自動で実行されます）

これは、データの損失を最小限に抑えることのできる機能となっており、ポカしやすい人には必需品と言えるほどの機能となっています。

先程申し上げた日次のバックアップだけでは不足しているバックアップ分を補填しているので、個人的にはすごく好きです。

DB インスタンスを特定の時点に復元し、新しい DB インスタンスを作成できます。

DB インスタンスを特定の時点に復元し、新しい DB インスタンスを作成できます。

死活監視が楽ちん

RDS はデフォルトでメトリクスデータを1分間隔で CloudWatch に送信してくれます。
（CloudWatch はメトリクスの収集、アラームの設定、ログの収集と監視などを対応してくれるサービスです）

これも自分ごとではありますが、死活監視をするために以下のようなインフラを構築しました。

イメージ	設定手順
	アプリケーションサーバー構築 アプリケーションサーバーを監視するサーバー（監視サーバー A）を構築 Zabbix をインストール アプリケーションサーバーに 監視サーバーA のエージェントをインストール 監視サーバーA にて監視設定 監視サーバーAを監視する監視サーバーBを構築 Zabbix をインストール 監視サーバーAに監視サーバーBのエージェントをインストール 監視サーバーBにて監視設定

[getpost id=”1243″ cat_name=”1″ date=”0″][getpost id=”1220″ cat_name=”1″ date=”0″]

手順書いてみたんですけど、すっげー面倒くさいですね。。。

その反面、 RDS では上記のような面倒くさい事をしなくても死活監視が簡単にできてしまうんです。

下記のあたりを見てれば DBが生きているかどうかを判別することができるので、すごく楽です。

• データベースの稼働状況
• CPU使用率
• メモリ使用率
• ディスクストレージ
• データベースのクエリおよびスロークエリ

これらに対して閾値を設定して異常状態を感知できるようにすれば、僕が構築したよく分からない事はしなくても済むなんて素敵すぎる！！！！

フェイルオーバーが楽ちん

フェイルオーバー の構成を取っていると何らかの障害が起きた際に被害を最小限に止めることができます。

実際に手動で組み込んだことはないのですが、天下の Oracle 様の解説記事を読んでみるとごちゃごちゃと設定が必要そうで、適切な冗長構成を取るのが難しそうな印象を受けました。

対して RDS は以下の条件を満たせば、冗長構成を取ることが可能となっています。

• マルチアベイラビリティーゾーン
• ホットスタンバイオプションの有効化

実際の手法を確認したい方はこちらの記事をご確認ください。

[getpost id=”1448″ cat_name=”1″ date=”0″]

まとめ

単純なDBを構築したい場合、RDS を使うことで楽に安全に構築することができます。

過去の自分に戒めを込めて、 RDS 使うと幸せになれることを胸張って伝えていきたいです。笑

この記事はジュニアエンジニアやミドルエンジニアを想定している記事です。

同じ様な働き方やIT業界の働きづらさに怯えている方の参考になれば幸いです。

前提

所属先の簡単な概要です。

厳しい社内リソースと案件数だったため、高稼働の状態でした。

またタイトルで受託企業と謳っているのですが、元々は紙を扱った業種の会社だった為、古い体制が残り続けている会社となっています。
そのため、システムを構築する期間を度外視した案件のとり方をしてきた結果が悲惨な状態を作り上げていきました。

なぜ300時間を耐えたのか

結果的に退職することになったのですが、まずは何故300時間の働き方を耐えてきたのかをお伝えしたいと思います。

一般的に「1日8時間×月20日+残業(5〜20h)=180〜200h」の働き方が普通だと思います。

そんな普通の働き方と比較して過酷な300時間の働き方を10ヶ月間も耐えたかというと自分の技術を伸ばしたいという目標があったからです。

前職はエンジニアの人手不足、社内の技術ストックもない状態でしたので自分自身で目の前の案件を乗り切るしか方法がありませんでした。

そのような状況下で働き続けたので肉体と精神を削って確かな技術を得ることができました。
前職に入社するまでは、末端作業員レベルだったものが炎上案件を複数こなしたことで、1エンジニアとして市場に出れるレベルになったと思います。

まだまだ足りない技術のほうが圧倒的に多いのですが、エンジニアとして名乗れるラインには立つことができたので目標達成です。

300時間働いて良かったこと

1→10までやらせて貰えた

要件定義からテストまでの工程を自分が主軸となって経験できたのが何より得難いものでした。

各工程を経験したことによって、どのくらいの期間でどのレベルまで仕上げるのかが少し想像することができるようになりました。
小規模案件が多かったのでまだレベルは低いのですが、工程ごとに躓きやすい部分や作業者の負担について考える良い経験をもらいました。

また、1→10の中で特に経験できて良かったことを挙げます。

• 要件定義

本当に必要な機能なのかを含めて顧客が求めているものは何なのか、顧客が求めているものは予算と納期にマッチしているものなのかを考え、話すことができました。
※ITについて知識が浅い顧客も中には存在していたので、技術可否や機能の不必要の判断を見誤ると案件が火を吹きます。(1つの案件で火吹いちゃいました。)

• 設計

システム設計から始まり、外部設計,内部設計,DB設計などたくさんのことを考慮して、全体設計を考えていきました。
設計って経験が必要ですね。。。

• 技術選定

何を使ってシステムを構築するのか、ある機能を実装するために必要なパッケージの導入など。

受託先企業の内部を見ることができた

エンジニアならゲロを吐きそうになるデータの持ち方をしている企業さんやエンジニアなら何でも叶えてくれるという考え方を持った人に出会いました。

世間ではDXやIT化の推進などが叫ばれていますが、それらを達成するためには時間が必要なことを実感できました。

技術に対するお金の考え方が身についた

1エンジニアが個人単位で売れるものは技術ですが、会社単位で見るとお金になっているのは作り上げたシステムがもたらすITによる恩恵です。

受託企業では「複数の言語を書くことができます！」といった技術よりも、ITによる恩恵が重要だと思います。

何ができるかよりも何を達成することができるのか。

ただし、エンジニアである以上、技術にこだわる必要は絶対にあるはずです。

お金と技術が必ずしも比例していくわけではないので、ここは引き続き悩み続けていきたいですね。

300時間働いてダメだったこと

体に異変

特に感じていたのが以下の2つです。

• 体重-7キロ
• 些細なことでカッとなる

300時間働くということは何かを削る必要が出てきます。
自分の場合は「睡眠」と「食事」でした。

フルリモートということもあり1日1食、6時間睡眠がデフォルトとなっていました。

その結果、上記の異変が体に起きてしまいました。

得た経験が多かった反面、体への負担もかなり多かったと思います。笑

社内を変えることができなかった

退社する時には僕を含めて4名のチームでした。(先輩エンジニアも300時間)

月300時間働くということは人数に見合わない案件数や納期の短さ、部長がITに精通していないなどが挙げられるのですが、問題となっている原因を変えることができないまま退職することになりました。

解決できなかった問題を社内に残る人たちに押し付ける事は辛いもんですね。。

最後に伝えたいこと

目標があり、その目標を達成できる仕事ができるのであれば無茶な働き方をするべきだと思います。
技術がほしい、お金がほしいなど目標がある方であれば多少の無茶をしてでもご自身の目標を掴み取ってほしいものです。

反対に目標がない(楽できれば良い)、目標に沿わない仕事しかできないのであれば、僕のような無茶な働き方はしないで欲しいです。

炎上も悪くないものですが、ご自身で考えて決定して行動していってほしいです。

1. SSOとは
   • 認証方式
   • 構成要素
2. SimpleSAMLPHPの実装方法
   • Apacheのエイリアス設定
   • SP登録(新規)
   • SPにIDPメタデータを登録
   • 確認

SSOとは

SSOとはSingleSignONの略称です。

1回のログインで複数のシステムにログインできる機能を指します。

身近な例ですと、GoogleやTwitterとは関係のないシステムにGoogleアカウントやTwitterアカウントでログインできるシステムを思い出してほしいです。。

認証方式

以下のような認証方法がある。

• 代行認証方式
• リバースプロ式方式
• エージェント方式
• SAML認証方式

今回はSimpleSAMLPHPを使用するため、SAML認証方式となる。

構成要素

SAML認証はIDPとSPという2つのシステムで構成されいる。

上記2つのシステム間でアサーションという証明書をやり取りし、SSOを実現している。

アサーションがログインの証跡〜。

SimpleSAMLPHPの実装方法

Apacheのエイリアス設定

/etc/apache2/sites-available/ドメイン名.conf
→SSL設定時に生成したファイル

下記設定が完了したらSIMPLESAMLPHPのコンパネへアクセスする。
コンパネではメタデータの確認やSimpleSAMLPHPの設定ができる。

・・・略・・・
Alias /simplesaml /var/www/simplesamlphp/www
       <Directory /var/www/simplesamlphp/www>
           Require all granted
       </Directory>
・・・略・・・

セキュリティ観点

上記エイリアスの設定でSimpleSAMLPHPのコンパネがウェブ上に公開されることになるが、基本的にIDPとSP両方にメタデータが存在していないと成立しない認証方式のため最悪メタデータが流出しても問題ないと考える。(SimpleSAMLPHP側でログインIDとPW設定できる。)

ただし、システム的には不必要なデータを開示する意味は全く無いので、コンパネには開発者のみのIPアクセス制限を入れるなどしたほうが良い。

パスワード変更

simplesamlphp/config/config.phpの中で「’auth.adminpassword’」の値を複雑な値に変更しておいてください。

上記の設定とサーバー自体にDOS対策を入れておけば、一応は安全です。

SP登録(新規)

config/authsources.phpからdefault-spの値をコピーして、新規SP(任意名称)として登録。

test-sp' => [			//←任意で変更 (SP名指定)
        'saml:SP',			
			
        // The entity ID of this SP.			
        // Can be NULL/unset, in which case an entity ID is generated based on the metadata >			
        'entityID' => null,			
			
        // The entity ID of the IdP this SP should contact.			
        // Can be NULL/unset, in which case the user will be shown a list of available IdPs.			
        'idp' => 'https://test.com/simplesaml/saml2/idp/metadata.php',		//←任意で変更 (IDPエンドポイント指定)	
			
        // The URL to the discovery service.			
        // Can be NULL/unset, in which case a builtin discovery service will be used.			
        'discoURL' => null,			
			
        /*			
         * The attributes parameter must contain an array of desired attributes by the SP.			
         * The attributes can be expressed as an array of names or as an associative array			
         * in the form of 'friendlyName' => 'name'. This feature requires 'name' to be set.			
         * The metadata will then be created as follows:			
         * <md:RequestedAttribute FriendlyName="friendlyName" Name="name" />			
         */			
        /*			
        'name' => [			
            'en' => 'A service',			
            'no' => 'En tjeneste',			
        ],			
			
        'attributes' => [			
            'attrname' => 'urn:oid:x.x.x.x',			
        ],			
        'attributes.required' => [			
            'urn:oid:x.x.x.x',			
        ],			
        */			
    ],			

上記で作成したSPメタデータをコンパネからダウンロードする。(XML形式)

IDPがあるサーバーは基本的にSPと異なるため、IDP側サーバーに今回ダウンロードしたSPメタデータを登録する。

SPにIDPメタデータを登録

https://test.com/simplesaml/module.php/core/frontpage_federation.php
上記からSPのメタデータを取得(パース済みの奴)
※管理画面に入るとツールがあるためXMLをPHP値に変換することができる。

メタデータをmetadata/saml20-idp-remote.phpに貼り付け

$metadata['https://test.com/simplesaml/module.php/saml/sp/metadata.php/test-sp'] = [
    'SingleLogoutService' => [
        [
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
            'Location' => 'https://test.com/simplesaml/module.php/saml/sp/saml2-logout.php/test-sp',
        ],
    ],
    'AssertionConsumerService' => [
        [
            'index' => 0,
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
            'Location' => 'https://test.com/simplesaml/module.php/saml/sp/saml2-acs.php/test-sp',
        ],
        [
            'index' => 1,
            'Binding' => 'urn:oasis:names:tc:SAML:1.0:profiles:browser-post',
            'Location' => 'https://test.com/simplesaml/module.php/saml/sp/saml1-acs.php/test-sp',
        ],
        [
            'index' => 2,
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact',
            'Location' => 'https://test.com/simplesaml/module.php/saml/sp/saml2-acs.php/test-sp',
        ],
        [
            'index' => 3,
            'Binding' => 'urn:oasis:names:tc:SAML:1.0:profiles:artifact-01',
            'Location' => 'https://test.com/simplesaml/module.php/saml/sp/saml1-acs.php/test-sp/artifact',
        ],
    ],
    'contacts' => [
        [
            'emailAddress' => 'test@gmail.com', //管理者用メールアドレス
            'contactType' => '', //管理者用
            'givenName' => 'admin',
        ],
    ],
];

確認

任意のphpファイルを作成し、ソース内でSimpleSAMLPHPを呼び出す。

開発者ツールのネットワークタブを開いた状態で下記ソースが記述されているファイルにアクセスすると、IDPサーバーとSPサーバーにてリダイレクトが発生する様子が伺える。

最終的にアサーションの取得が成功するとブラウザ上にはデバッグ出力している$attributesの値が表示されているはずです。

<?php
require_once('./../../../simplesamlphp/lib/_autoload.php');
 
$auth = new SimpleSAML_Auth_Simple('test-sp');
$auth->requireAuth();
$attributes = $auth->getAttributes();

var_dump($attributes);
?>