re:Invent 2024: ブラジル公立大学入学システムSISUのAWS移行事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Democratizing access to higher education for 1.2 million students (WPS319)
この動画では、ブラジルの公立大学入学システムSISUのAWSへの移行プロジェクトについて解説しています。SISUは年間300万人の学生が利用する重要なシステムで、AWS Shield AdvancedやAWS WAF、Amazon CloudWatchなど複数のAWSサービスを組み合わせて、DDoS攻撃対策や高可用性を実現しました。OpenShiftクラスター上でアプリケーションを実行し、1秒あたり20,000リクエストのピーク負荷にも耐えられる堅牢なアーキテクチャを構築。2024年1月の本番稼働では10万4,000人以上の同時アクセスを記録し、4日間で140万人以上の学生が26万以上の空席に対して240万件以上の登録を行うという大規模なシステムの安定運用に成功しました。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
SISUプロジェクト：ブラジルの高等教育アクセス改革
みなさん、こんにちは。まず最初に、今日はブラジルの方が何人いらっしゃいますか？ポルトガル語で「Riga, Isar Aqui Boes Prova Men, a po Soiu」と言わせていただきます。ブラジル人以外の方向けですね。SISUについてご存知ですか？ご存知なくても大丈夫です。今日お話しさせていただきます。改めまして、こんにちは。私はAWS Brazilで Customer Solutions Manager for Government を務めているMaria Carolinaと申します。本日は、AlessandraさんとMakinoさんにもご同席いただいています。自己紹介をお願いします。
ご参加ありがとうございます。本日は光栄です。私はAlessandra Fariaと申します。ブラジルのPublic Sectorで Solutions Architectを務めております。こんにちは、Ricardo Makinoと申します。AWS BrazilのPublic SectorでSolutions Directorを務めております。本日はご参加いただき、ありがとうございます。
本日は、ブラジルの100万人以上の学生の大学進学機会を民主化するために、私たちがMinistry of Educationをどのように支援してきたかをご紹介させていただきます。また、私たちのお客様への献身的な姿勢とAWSの力が、ブラジルの教育にどのように意味のある影響を与えたかについてもお話しさせていただきます。 では、本日のアジェンダをご説明します。MECとSISUの概要、移行の目的、アーキテクチャ、負荷テストについてお話しします。さらに、AWSのメカニズム、本番稼働時の課題、結果、そして今後の展開についても説明させていただきます。
SISUシステムの概要と AWS移行の目的
Ministry of Education（MEC）は、国家教育政策、評価、情報、および国家研究を担当する主要な連邦機関です。MECは、就学前教育から高等教育まで、教育システム全体を管理しています。Ministry of Educationは、すべてのブラジル国民に質の高い学習機会を確保するため、ブラジルの教育における戦略的方向性を定める重要な役割を担っています。
SISU（Sistema de Seleção Unificada）は、2010年にMinistry of Educationによって導入されました。これにより、ブラジルの学生が公立大学に進学する方法が大きく変わりました。SISUは高等教育へのアクセシビリティを支援しています。全国各地の学生が、入学試験のために移動する必要なく、全国のさまざまな大学に出願することを可能にしました。また、SISUは社会的な不均衡の是正も支援しています。公立学校出身者、低所得家庭、人種的マイノリティなどの学生のために一定の割合で入学枠を確保するアファーマティブ・アクション政策を取り入れ、教育の質の向上を推進しています。SISUは毎年何百万人もの学生の人生に影響を与えています。このプロジェクトの重要性と大規模な規模を考慮し、AWSのクラウドの力を活用するためにAWSへの移行を決定しました。
SISUの概要についてお話しします。まず、学生は通常11月に実施される全国高校試験のENEMを受験する必要があります。その後、学生はSISUにアクセスします。SISUでは、第一志望と第二志望の2つのオプションで出願でき、同時に2つの異なるコースや2つの異なる教育機関に応募することができます。最終的に、成績と各大学プログラムの定員数に応じてランキングで分類されます。
志願者の視点から見ると、SISUは次のように機能します：志願者は第一志望と第二志望に出願でき、各コースには異なる重み付けと最低平均点、最低点の要件が設定されています。例えば、工学コースでは数学により重きが置かれます。その後、各コースには独自のカットオフスコアが設定されます。SISUは最終ランキングを通じて、選択したコースにおける学生の順位を表示します。
文部省と大学の視点からは、次のような仕組みになっています：まず、国立大学がシステムに募集枠を公開します。学生がENEMのスコアを入力すると、それは自動的にSISUと連携されます。学生が手動でスコアを入力する必要はありません。システムは処理を行い、各大学の募集枠に選ばれた学生の最終ランキングを返します。ランキングの過程では、公立学校出身者や人種的マイノリティなどのカテゴリーに対してクォータ制が適用されることが重要なポイントです。選考プロセス後、大学はSISU管理システムを使用して、入学資格のある学生の登録情報にアクセスします。2010年以降、1,500万人の学生がSISUを通過し、毎回約300万人の学生がこのシステムにアクセスする資格を得ています。
AWSクラウド上のSISUアーキテクチャと多層防御戦略
インフラストラクチャをクラウドに移行する決定を下した際、5つの主要な目標がありました。1つ目はコスト削減です。2つ目は、プロセス管理を文部省に戻すことです。当時、プロセスの知識はパートナー企業が持っており、それを取り戻したいと考えていました。3つ目は性能の向上です。SISUは年々志願者が増加しているため、志願者がシームレスな体験を得られるよう保証する必要がありました。4つ目はサプライヤーとコンポーネントの互換性で、重要なイベントに関連する複雑さとリスクを軽減することです。5つ目はサポートリソースの可用性で、インシデント発生時に専任のサポートチームを確保できることを保証することです。
AWS Cloud上のSISUアーキテクチャは、高度なスケーラビリティ、セキュリティ、信頼性を備えるよう設計されています。システムの中核にはVirtual Private Cloud（VPC）があり、高可用性と障害耐性を確保するために、サービスは複数のAvailability Zoneにわたってデプロイされています。 フロントエンドでは、Amazon Route 53がDNSトラフィックを処理し、Amazon CloudFrontがユーザーに静的コンテンツを配信しています。 VPC内には、志願者データとランキングを保存するSQL Serverデータベースクラスターがあります。アプリケーションはRed Hat OpenShiftを実行しているAmazon EC2インスタンス上にデプロイされ、コンテナ化された管理環境を提供しています。
外部統合とサービスを処理するために、AWS Site-to-Site VPNを使用してセキュアな接続を確立しました。AWSのセキュリティは最優先事項であるため、このアーキテクチャには様々なセキュリティサービスを実装しています。 これには、Webアプリケーションファイアウォール機能を提供するAWS WAF、インテリジェントな脅威検出を行うAmazon GuardDuty、セキュリティ管理を一元化するAWS Security Hub、そしてDDoS保護を提供するAWS Shield Advancedが含まれます。
ガバナンスとモニタリングについては、 リソースの監査と評価のためのAWS Config、ログとメトリクスのためのAmazon CloudWatch、ベストプラクティスの推奨事項を提供するAWS Trusted Advisorを導入しています。全体として、このアーキテクチャは幅広いAWSサービスを活用し、システムの高トラフィックと重要性に対応できる堅牢で拡張性の高い安全なプラットフォームを実現しています。
SISUインフラストラクチャの適切なガバナンスと制御を確保するため、アカウントの構成について見ていきましょう。AWS Organizations内にマルチアカウント構造を実装しました。最上位にはAWS環境全体のエントリーポイントとなるRoot OUがあります。その下には、リソースの一元管理を担当するマネジメントアカウントがあります。また、SISU OU内には特定のアカウントがあります：バックアップ、セキュリティ、ロギング用の専用アカウントで、適切な職務分掌を確保しています。さらに、SISU統合環境、SISU UAT（ユーザー受け入れテスト）環境、SISUテスト環境、そしてSISU本番環境があります。このガバナンス構造により、リソースに対する高度な制御、可視性、セキュリティを維持しながら、異なる環境を独立して管理する柔軟性を実現しています。
Alexandraが述べたように、AWSではセキュリティが最優先事項であり、認証と認可プロセスの保護は多層防御戦略の第一歩です。これは、脅威アクターがAWS環境内の設定ミスのあるサービスを探る最初のレイヤーだからです。AWS Identity and Access Management (IAM)を使用して、SISUを管理するための職務分掌と最小権限の原則を実装しました。アーキテクチャの中核には、ロールがあります。 これらのロールは、データベース管理者、Site Reliability Engineer、セキュリティアナリスト、自動化サービスなど、さまざまなタイプのユーザーに対して、特定のポリシーを通じて必要な権限を付与するために使用されます。
ユーザーがAWS ConsoleやAWS CLIにアクセスする必要がある場合、 最初のステップは多要素認証トークンを含む認証情報を提供することです。認証情報が検証された後、AWS環境内で職務を遂行するための適切な権限を持つ特定のロールを引き受けます。AWS環境全体はInfrastructure as Codeを使用して管理されています。まだ使用していない方には、ぜひお勧めします。自動化によってエラーを減らし、環境全体で一貫したデプロイが可能になり、以前のプロジェクトのコードを新しいプロジェクトで再利用できるため、変更のスケーリングが容易になるからです。
GitLabは私たちの環境におけるすべてのインフラストラクチャコードの信頼できる情報源です。サイトエンジニアがGitLabにコードをプッシュすると、パイプラインが起動します。パイプラインが起動すると、GitLab CI Runnerが実行を開始し、シークレットキーとアクセスキーを使用してAWSで認証を行います。その後、GitLab CI RunnerはAWS上にリソースをデプロイするための高権限ロールを引き受けることで、さらなるセキュリティレイヤーを追加します。この高権限ロールには、GitLab CI Runnerからのアクセスのみを許可するIPアドレス制限を条件として設定しています。このようなAWSの強力な機能を活用することで、最小権限の原則とディフェンスインデプスの原則に基づいた、安全で監査可能な認証・認可プロセスでSISUを管理できる仕組みを構築しました。
Carolが発表の冒頭で述べたように、SISUはブラジルの公立大学への主要な入学申請システムであり、善意のユーザーにも悪意のユーザーにも高い注目を集めています。DDoS（Distributed Denial of Service）についてご存知の方もいらっしゃると思いますが、DDoSとは、通常は単一の攻撃者によって制御される、インターネット上の複数の侵害されたシステムが、特定のシステムやネットワークに対して一斉にアクセスを行い、サービスを圧迫することで、正当なユーザーがアプリケーションにアクセスできなくすることを目的とした攻撃の一種です。このようなDDoS攻撃の性質を理解することで、SISU のアーキテクチャに適切な保護対策を実装することができました。
SISU運用中のDDoSによる混乱を防ぐため、私たちはAWS Shield Advancedを使用しています。AWS Shield Advancedは、DDoS攻撃、大量のボットトラフィック、SQLインジェクションなどのWebアプリケーションの脅威から環境を保護するマネージドサービスです。AWS Shield AdvancedはAWS WAFと連携して、攻撃を自動的に検知し緩和します。Shield Advancedは、Amazon Route 53のホストゾーン、Amazon CloudFrontのディストリビューション、AWS Global Acceleratorのアクセラレーター、Elastic Load Balancing、そしてEC2などのAWSリソースに紐付けられたElastic IPを保護します。AWS Shield Advancedでは、レイヤー7攻撃の自動緩和と、攻撃時のコスト保護スケーリングが提供されます。例えば、DDoSイベント中にアプリケーションが標的になった場合、攻撃を吸収するためにスケールアップが必要になったマシンのコストは、月末の請求から免除される可能性があります。AWS Shield Advancedのもう一つの優れた機能は、SISUの境界を保護するDDoSイベント対応の専門セキュリティエンジニアチームであるAWS Shield Response Teamへのアクセスです。私たちは、Global AcceleratorとFirewall Manager以外のすべてのサービスを利用しています。
SISUアーキテクチャのエッジにおけるAWSの境界保護についてもう少し詳しく見ていきましょう。SISUアーキテクチャのエッジでは、フロントエンドとAPIの両方のDNSリクエストを処理するためにAmazon Route 53を使用しています。さらに、2つのCloudFrontディストリビューションがあります。1つはフロントエンドの静的コンテンツ用、もう1つはAPI用です。リクエストはNetwork Load Balancerを経由して、OpenShiftクラスター内のAPIに送られます。また、CloudFrontディストリビューションには、フロントエンドとAPIの両方をWebアタックから保護するAWS WAFが設定されています。先ほど述べたように、アーキテクチャ上のすべてのリソースはAWS Shield Advancedによって保護されています。
これらのサービスを補完するものとして、環境内の異常やDDoSイベントの可能性を検知するためのメトリクスとログを監視するAmazon CloudWatchがあります。さらに、CloudWatchのメトリクスとログは、セキュリティイベントやアプリケーションの障害を迅速に特定して対処できるよう、お客様のインシデント対応プロセスと緊密に統合されています。このようにセキュリティサービスを層状に配置することで、ブラジルの何百万人もの学生のためにSISUを安全かつ利用可能な状態に保つ、包括的な境界保護戦略を構築しています。
SISUの本番稼働に向けた準備と AWS Countdownフレームワーク
脅威の検知とインシデント対応は、私たちのディフェンス・イン・デプスの戦略における重要な側面です。複数のサービスからイベントを収集・分析し、タスクを自動化し、セキュリティの問題やイベントを統合してSISUチームの運用効率を向上させるための包括的なサービス群を実装しました。先ほど申し上げたように、 Amazon CloudWatchのアラームを作成し、SNSトピックに通知を送信して2つのLambda関数をトリガーすることで、イベント検知とインシデント対応を改善しました。最初のLambda関数は、あらゆる種類のイベントや異常が発生した際にSISUのセキュリティ運用チームを関与させる役割を担います。2つ目はAWS Shield関数で、イベント中の異常や問題が発生した際にAWS Shield Response Teamを関与させます。
さらに、Amazon GuardDutyとAWS Trusted AdvisorのデータをAWS Configを通じて活用し、アーキテクチャ内の脅威やSISUのセキュリティ問題につながる可能性のある設定ミスを監視しています。これらの発見事項はAWS Security Hubで一元管理され、その後、AWSのセキュリティベストプラクティス評価を実行するオープンソースツールであるProwlerと統合されます。その後、すべての発見事項はApplication Security Posture ManagementツールであるDetectDojoに送信され、顧客はこれを使用してSISUアーキテクチャ内の問題を追跡し、これらのリスクを軽減するためのアクションプランを作成します。
AWSのセキュリティサービス、オープンソースツール、そして顧客のインシデント対応プロセスを組み合わせることで、SISUのための堅牢な検知とインシデント対応の仕組みを構築しました。SISUアーキテクチャの詳細な説明を続けますと、 ここではOpenShiftクラスター内でアプリケーションがどのように実行されているかを示しています。アーキテクチャの最上部には、OpenShiftクラスターのエントリーポイントとなるNetwork Load Balancerがあります。Network Load Balancerがリクエストを受け取ると、Ingress Controller Routerポッドに送信します。
Ingress Controller Routerポッドは、OpenShiftクラスター内のSISUの適切なサービスやデプロイメントにリクエストをルーティングする役割を担っています。クラスター内には2つのプロジェクト、つまり2つのアプリケーションがあります。1つ目はプロジェクトSISUで、学生がイベント開始前に空き枠を確認できるポータルです。
SISUの最初のレイヤーは、このために使用するインバウンドAPI Gatewayです。2つ目はアプリケーション自体で、3つ目はRed Hatが開発したインメモリキャッシュであるData Gridです。2つ目のアプリケーションはSISU Luoです。SISU Luoは、学生が空き枠に応募し、採用結果を確認するためのAPIです。プロジェクトSISUと同様に、インバウンドAPI Gatewayがありますが、アプリケーションは2つのデプロイメントに分かれています。1つ目のデプロイメントは読み取りリクエスト用で、2つ目は書き込みリクエスト用です。そしてAPI Gatewayがクラスター内の適切なデプロイメントにリクエストをルーティングする役割を担っています。
SISUプロジェクトと同様に、データベースクエリのキャッシュを保存するためのData Gridを導入しています。さらに、Outbound API Gatewayも実装しました。このOutbound API Gatewayは、SISUと外部APIとの間にTLS暗号化を使用したHTTPS通信のコネクションプールを確立するために使用されました。これにより、外部APIとSISUの間でコネクションプールを維持することで、リクエストあたり150ミリ秒のレスポンスタイムを削減することができました。
アーキテクチャと計画は重要ですが、SISUの本番稼働前に、計画し、設計し、開発したすべてをテストする必要があります。システムの堅牢性と想定されるトラフィックを円滑に処理する能力を確認するため、包括的なパフォーマンステストとロードテストを実施しました。この目的を達成するため、アプリケーション内のさまざまなユーザーパターンをシミュレートするよう設計された4つの異なるテストシナリオを実施しました。このアプローチにより、幅広い実際のシナリオでシステムのパフォーマンスを評価することができました。
テスト結果は私たちの期待を上回り、1秒あたり20,000リクエストのピーク負荷シナリオでも、15万人のユーザーが同時にシステムを利用する状況でもトランザクションを処理できました。API応答時間は文部省から要求された1秒を大きく下回り、APIの障害は皆無でした。これはシステムの回復力と耐障害性を実証するものであり、本番稼働時に予想されるトラフィックをSISUが処理できるという確信を私たちに与えてくれました。
しかし、SISUのアーキテクチャと計画に関わるすべてのチームが素晴らしい仕事をしても、障害が発生する可能性は常にあります。私たちのCTOであるReno Voloが言うように、「すべてのものは常に故障する」のです。計画フェーズやアーキテクチャフェーズで気づかなかった可能性のある障害を軽減するため、私の同僚のAlessandroが説明する予定のAWSのメカニズムをいくつか使用しました。ありがとうございました。
おそらく皆さんは、私たちのCEOであるAndy Jassyの「経験に対する圧縮アルゴリズムは存在しない」という言葉をご存知でしょう。この言葉は、ソリューションを構築する際に近道を取ろうとするのではなく、設計と計画の重要性を説いています。この原則は、SISUのような重要なシステムの移行において、私たちのアプローチを大きく導いてきました。私たちは手抜きをしたり、プロセスを急いだりする余裕はありませんでした。アーキテクチャを慎重に設計し、徹底的にテストを行い、起こりうる課題に備える必要がありました。そのため、SISUの立ち上げ前に実施したパフォーマンステストとロードテストを特に重視しました。私たちは、SISUが成功することを単に期待するのではなく、特にユーザートラフィックとパターンをシミュレートする際に、それを保証する必要がありました。この事前の作業により、潜在的なボトルネックや脆弱性を特定し、プロジェクト全体を通じて必要な調整を行い、ブラジルの受験生にシームレスな体験を提供することができました。
次にご紹介したいトピックは、AWS Countdownと呼ばれるフレームワークについてです。 AWSでは、大規模イベントの整合性と適切なガバナンス計画を確保するために、以前IEMと呼ばれていたこのフレームワークを使用しています。このプロセスには、計画立案、リスク軽減の検討、そしてイベント後の振り返りが含まれます。また、Amazon.comでのトラフィックやオンラインショッピングの活動が大幅に増加するAmazon Prime Dayなどのイベントでも、このプロセスを活用しています。この体系的なアプローチに従うことで、SISUのローンチ前に起こりうる課題を予測し、対処することができ、成功裏にGo-liveを実現することができました。AWS Countdownは、AWSの専門家が開発した実績のあるプレイブックを活用することで、プロジェクト全体を通してサポートしてくれました。
SISUの本番稼働結果と今後の展望
数百件のAWS Countdownイベントを実施してきた結果、AWSではアカウントエンゲージメント全体を通じて段階的に実施するフレームワークを確立しました。タイムラインには、それぞれのフェーズが示されています。大まかに言うと、Countdownエンゲージメントには4つのフェーズがあります。まず「開始」フェーズでは、イベントの日程と詳細を持ってCountdownエンゲージメントをリクエストします。その時点で、TAMのDanilo Castroがアカウントチームに配属されました。「計画」フェーズでは、イベントの性質を深く理解し、インフラストラクチャとアーキテクチャを確認し、リスクの特定と軽減を行い、Runbookを作成し、サービスの制限を確認することに時間を費やします。「実行」フェーズはイベントの主要フェーズで、インフラストラクチャの監視とエスカレーションの調整が必要な場合の対応が含まれます。「レビュー」フェーズでは、通常運用に戻り、主要な指標を分析し、継続的な改善のためにイベントから得られた教訓を文書化します。
テクノロジーソリューションの構築は、 物理的な建物を建てるのと非常によく似ています。基礎がしっかりしていないと、建物の完全性や機能性を損なう構造的な問題を引き起こす可能性があります。テクノロジーソリューションに取り組む際には、Well-Architected Frameworkの6つの柱を活用すべきで、それによって安定的で効率的なシステムを構築することができます。6つの柱とは、開発運用ワークロードを効果的にサポートし、サポートプロセスを継続的に改善する能力である「運用上の優秀性」、資産、データ、システムを保護する能力である「セキュリティ」、そして「信頼性」です。
「信頼性」、この柱は、システムが障害に対処し、期待通りに運用を継続できることを確保するものです。予期せぬ問題に対処するための冗長性とレジリエンスを構築することが重要です。「パフォーマンス効率」、この柱は、ユーザーのニーズを満たすためにシステムのパフォーマンスを最適化することに関するものです。システムを高速かつレスポンシブにするために、適切なリソースとテクノロジーを使用することが重要です。「コスト最適化」、この柱は、AWSクラウドから得られる価値を最大化できるよう、システムが不必要なコストやサービスを使用していないことを確認することに関するものです。「持続可能性」、この柱は、システムや環境が持続可能で、地球への影響を最小限に抑えることを確保するものです。
ここで質問させていただきたいのですが、Well-Architectedレビューを既に実施したことがある方は何人いらっしゃいますか？AWS ConsoleでアクセスできるAWS Well-Architected Toolを使用すれば、誰でもワークロードや環境をレビューすることができます。システムや環境を継続的に改善できるよう、定期的に実施することをお勧めします。Well-Architected FrameworkとAWS Consoleの他にも、私の同僚のMakinoが今から説明する別のメカニズムも使用しました。
次に私たちが使用している別のメカニズムについてお話ししましょう。 それは、Shield Response Fire Drillです。まず、この会場で消火器の使い方を知っている方は手を挙げてください。あまり多くないですね。防護装置の使い方を知り、それらが期待通りに機能しているかを確認する必要があるのと同じように、私たちのアーキテクチャにデプロイしたソリューションの使い方を知り、それらが正しく設定されているかを確認する必要があります。消火器の使い方を学んだり、それらが期待通りに機能しているかをテストしたりする最良の方法は何でしょうか？それは消防訓練を通じてです。
AWS Shield Advancedが正しく設定され、DDoSイベントが発生した場合に各チームが何をすべきかを把握していることを確認するため、私たちはShield Fire Drillと呼ばれるAWSのメカニズムを使用しました。これは、AWS環境内でのインシデントの検知、通知、対応における潜在的なギャップを特定するためのDDoS攻撃のシミュレーションです。SISUでは、Shield Response Team（SRT）がSISUのセキュリティチームと協力してDDoSイベントのシミュレーションを実施しました。これを行うために、SRTはCloudWatchのDDoSメトリクスに攻撃データを注入し、DDoSイベントの検知、通知、対応のプロセス全体をトリガーしました。この訓練中、SRTを呼び出すLambda関数が適切に設定されていないことが判明しました。この発見により、SISUのセキュリティチームはDDoSイベント発生時にSRTを呼び出すためのLambda関数の正しい設定方法を把握することができました。このメカニズムにより、検知と対応の手段をテストし、Alessandroが次にお話しする本番稼働時にDDoSイベントに効果的に対処できる準備が整っていることを確認できました。
ありがとうございます、Makino。 このプラットフォームは今年の1月22日に本番稼働を開始し、10万4,000人以上の受験生のアクセスがピークを記録しました。
1月22日には、1分あたり約11,000件の登録というピークを記録しました。外部プロバイダーとの認証失敗といった予期せぬ問題はありましたが、それが私たちを止めることはありませんでした。私たちの献身的なプロフェッショナルたちの積極的なアプローチにより、この課題に対処し、成功的なローンチを実現することができました。チームはAWSのカスタマーパートナーと共にWar Roomに参加し、4日間を通じて追加作業が成功するよう尽力しました。
どのようなシステムでも効果的な運用にはモニタリングが不可欠であり、SISUも例外ではありません。しかし、インフラストラクチャやアプリケーションのメトリクスだけでなく、ビジネス関連のデータのモニタリングも同様に重要です。今年1月に行われた4日間のSISUの結果、220万人の対象学生のうち、140万人以上の学生が、ブラジル全土の107の大学にある26万以上の空席に対して240万件以上の登録を行いました。これらの数字は、何百万人もの学生の人生におけるSISUの重要性を示しています。さらに、SISUの実行ウィンドウはわずか4日間、つまり96時間であることを考えると、1時間のダウンタイムでもSLAの1パーセント以上の低下を意味します。安定した信頼性の高いプラットフォームの維持が私たちの優先事項でした。なぜなら、いかなる障害やダウンタイムも、SISUに将来の学業への希望をかける何百万人もの学生に重大な影響を及ぼす可能性があったからです。
次期バージョンで計画しているSISUの次のステップについてお話ししましょう。例えば、Well-Architected Frameworkのレビューです - 環境を定期的にレビューすることは常に良い習慣です。ここで重要な質問があります：皆さんは定期的に環境を見直していますか？また、最適化と自動化による運用効率の向上も計画しています。その他のステップには、需要の変動に対応するためのOpenShiftクラスターとPodの自動スケーリングの実装、運用手順書の自動化、そして最後にアプリケーションのMicroservices化による近代化が含まれます。これらは、SISUをより堅牢で信頼性の高いソリューションにするために計画している施策の一部です。
以上で私たちの発表を終わります。MakinoとAlessandraにもう一度ここに来ていただき、本日は皆様のお時間とご注目をいただき、ありがとうございました。ご質問がある方や、私たちの経験や学んだ教訓についてもっと詳しく知りたい方は、お気軽にご連絡ください。より詳細な情報を喜んでご提供させていただきます。また、モバイルアプリでのアンケートへのご回答もお忘れなくお願いいたします。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion