ベン・マクモランです。ウースター工科大学でコンピュータサイエンスを学ぶ、もうすぐ3年生になります。この12週間、教育学習（TNL）チームでソフトウェアエンジニアリングのインターンとして働いてきました。edXでのインターンシップは2回目の夏になります。インターンシップ期間中に取り組んだタスクは数多くありますが、特に2つのプロジェクトについてお話ししたいと思います。
チーム向けAPIとフロントエンド開発
私が最初に取り組んだプロジェクトは、LMSのTeams機能で、現在も開発中です。この機能により、学生は少人数のグループで互いにつながり、会話しやすくなり、edXコースのバイラル性が向上します。この機能の開発には、 バックボーン API実装と Django レスト フレームワーク （DRF）。昨年の夏にコース公開ワークフローの改善に携わったため、Backbone についてはよく知っていましたが、API の作業は初めてでした。
開発全体を通して、分離され再利用可能なコンポーネントの作成に重点が置かれました。その一例が、チームリストとトピックリストのページネーションコントロールの設計です。私たちはいくつかの 汎用的で再利用可能なページングコントロール DRF が返すページ情報と互換性があります。
上図に示すように、これらのコントロールは、将来の開発で他の edX API エンドポイントと簡単に統合できます。
その 拡張可能なフィールド チームAPIをサポートするために作成したものは、再利用可能なコードのもう一つの例です。クライアントは、最初のリクエストの一部として、どのフィールドについて詳細情報を希望するかを指定できます。例えば、チーム情報のリクエストでは、ユーザーフィールドを拡張するように指定できます。これにより、ユーザー名のみを提供する代わりに、応答にはチーム内の各ユーザーの詳細が含まれます。これにより、クライアントが行う必要があるリクエストの数が削減され、フィールドが不要な場合は応答のサイズが削減されます。拡張可能なフィールドは、フィールドを次のように指定することで、あらゆるDRF APIに簡単に統合できます。 拡張可能なフィールド 折りたたみ状態と展開状態のシリアライザーを提供します。edXプラットフォームが成長するにつれて、再利用可能なコンポーネントへの重点はますます重要になります。
ディスカッションフォーラムのパフォーマンス改善
また、数週間かけてディスカッションフォーラムのパフォーマンス改善に取り組みました。edx.org のサーバーは New Relic で監視していますが、今年の夏の初めに、あるコースでコメントの投稿に40秒以上かかっているという痕跡が監視によって確認され、さらなる調査が必要となりました。
問題のあるコースをローカル開発環境に読み込み、コメントを投稿してみました。プロファイリングの結果、サーバーが分析イベントの発行にほとんどの時間を費やしていることがわかりました。この分析イベントには、ディスカッションのトピック（該当する場合）が含まれます。ディスカッションコンポーネントのトピックは、ディスカッションスレッドをフィルタリングしてグループ化する手段を提供します。例えば、インラインディスカッションコンポーネント内のすべてのスレッドは同じトピックを持ちます。
ディスカッションアプリでは、コメントはコメントサービスで使用されるディスカッションIDに基づいて作成されます。しかし、特定のコメントのディスカッショントピックは、コースの一部としてディスカッションモジュールに保存されます。ディスカッションモジュールは関連するディスカッションIDを認識していますが、ディスカッションIDしか知らなければ、ディスカッショントピックを効率的に取得する方法はありませんでした。問題となったコースには、約1000個のディスカッションモジュールがありました。アナリティクスイベントの作成は、 ひとつひとつ 議論のトピックを見つけましょう！
最初に考えたのは、ディスカッションIDにインデックスを追加することでした。しかし、edXプラットフォームにはコースの永続化メカニズムが複数存在するため（旧Mongo、分割Mongo、XMLコース）、これは問題を引き起こすことが判明しました。新しいインデックスを使用するには、大幅な変更が必要になります。そこで、代わりに ディスカッションIDと関連モジュールのマッピングこのマッピングは、コースが公開されるとMySQLデータベースにキャッシュされます。コースデータはほとんど変更されませんが、頻繁にアクセスされるため、コース全体を走査してマッピングを構築するコストは比較的高くなりますが、その頻度は低いため許容できます。
修正を実装した後、負荷テストで検証する必要がありました。このプロセスは私にとって全く新しいものでした。それ自体は難しくありませんでしたが、慣れるまでには少し時間がかかりました。既存のフォーラムを運営し、 イナゴ 修正を適用する前と適用した後の問題のあるコースに対するテスト。
修正前は、20分の負荷テストでコメントの作成に約1320秒かかっていました。コース内のすべてのディスカッションモジュールが読み込まれるため、内訳表にはMongoDBクエリがXNUMX件と非常に多く表示されています。
修正後、6.75分の負荷テストでコメントの作成に約XNUMX秒かかりました。MongoDBクエリの数がXNUMXに減少していることに注目してください。
この修正により、応答時間は約5倍高速化し、MongoDBクエリ数も大幅に削減されました。修正は現在edx-platformのマスターブランチに反映されており、近日中にedx.orgにデプロイされる予定です。
要約すれば…
edXインターンとしての経験は素晴らしいものでした。TNLチームの一員として、まるで正社員になったような気分でした。実際のチケットを担当し、自分の仕事がプラットフォームにどのような影響を与えるかを目の当たりにすることができました。オープンソースプロジェクトの開発は素晴らしい経験です。この素晴らしい夏を過ごせたことを、Andy Armstrong氏、Christina Roberts氏、TNLチームの皆様、そしてedXに感謝いたします。
