Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ラボユース最終成果報告会(Web公開版)

4,486 views

Published on

  • Be the first to comment

  • Be the first to like this

ラボユース最終成果報告会(Web公開版)

  1. 1. サイボウズ・ラボユース 最終成果報告∼現役高校生の考えるクラウドOSの設計と実装∼ 粟本 真一 注:WEBで公開するために一部のスライドを編集しています。
  2. 2. 自己紹介• OS作ってます。• 神奈川県栄光学園高等学校2年• サイボウズ・ラボユース 1期生サブメンバー• セキュリティ&プログラミングキャンプ2011参加  (セキュアなOSクラス)
  3. 3. 唐突ですが、暫く分散処理の話を させて下さい
  4. 4. 我が家には3台のパソコンがあります
  5. 5. ここで、一台のPCを使って コンパイルを走らせた としましょう
  6. 6. ・・・お、おそい。
  7. 7. もうちょっと何とかならないの?
  8. 8. 全てのPCのCPUを合わせれば、Corei7の ハイエンドモデルに匹敵する性能が 出てもおかしくないのに・・・。
  9. 9. それなのに・・・
  10. 10. 皆で協力して計算した方が、絶対効率が良いですよね!cooperation
  11. 11. = 分散コンピューティング
  12. 12. これが、僕が分散処理に興味 を持ったきっかけです
  13. 13. 折角なので、分散処理の デモをしましょう Allba system Demo
  14. 14. 今、手元に2台のPCが あります Allba system Demo
  15. 15. この2台を使って、僕のOSのコンパイルをやって みたいと思います Allba system Demo
  16. 16. make クライアントプログラムサーバープログラム ×2 サーバープログラム ×4 Allba system Demo
  17. 17. DemoAllba system Demo
  18. 18. 計測データmake (オプション無し) : 45smake -j2 : 26s Allba : 11s(Mac Book Air 2proc, ASUS K53E 4proc) Allba system Demo
  19. 19. 分散処理とクラウドコンピューティング がどう繋がるのか
  20. 20. Answer
  21. 21. 僕は、分散処理が一番活躍するのはクラウド上だと 思っているから
  22. 22. クラウド上での分散処理• 分散処理で巨大なリソースが得られる• そのリソースを時々しか使わないのは もったいない
  23. 23. クラウド上での分散処理• クラウド上では、リソースを効率的に扱 える(沢山のユーザーが絶えずアクセスするから)• また、ユーザーは分散処理を意識する事 なくサービスを使える
  24. 24. クラウドと分散処理は 相性が良い
  25. 25. 分散処理、及びクラウドコンピューティングで OSは何ができるのか?
  26. 26. OSがやってあげた方が効率が良い事は何なのか、 という話をします。
  27. 27. 環境整備• 分散処理、並びにクラウドコンピュー ティングを行う環境が っていた方が、 当然、開発は楽になる• より良い環境を提供する事がOSの使命
  28. 28. OSがやるべき事• 分散処理に最適化されたAPIの提供• ネットワーク越しの同期• ハードウェア周りのサポート     (ex. メモリ管理)• 仮想ファイル
  29. 29. 最適化されたAPIとは• 分散処理では、多数のノードとコネク ションを張る必要がある• その中には「応答のない」ノードもある かもしれないが、その応答を待っている 暇は無い
  30. 30. 最適化されたAPIとは• ノードに接続できない時、connect()のタ イムアウトに数十秒も掛かっているくら いなら、諦めて処理を始めた方が早い• 先ほどのデモでも、connect()のタイムア ウトは5秒に設定してある
  31. 31. そもそも、複数ノードとの 接続をAPI化した方が良いforeach(node n : node_list){ error = connect(n); 新しいAPIを}
  32. 32. list < string > ip_list; list<Node>::iterator it = server_list.begin(); while (it != server_list.end()) { int server_sockfd = socket(AF_INET, SOCK_STREAM, 0); if (server_sockfd < 0) { cout << (*it).ip_addr << "(" << (*it).port << "): failed (1)" << endl; ++it; continue; } struct sockaddr_in address; address.sin_family = AF_INET; この70行のコード address.sin_addr.s_addr = inet_addr((*it).ip_addr.c_str()); address.sin_port = htons((*it).port); int len = sizeof(address); int result = fcntl(server_sockfd, F_SETFL, O_NONBLOCK); if (result < 0) { cout << "fcntl returned error(1)." << endl; close(server_sockfd); return -1; } result = connect(server_sockfd, (struct sockaddr *) &address, len); if (result < 0) { if (errno == EINPROGRESS) { fd_set set; struct timeval tv; tv.tv_sec = 5; //5秒でタイムアウト tv.tv_usec = 0;
  33. 33. 分散処理に最適化されたAPI を作れば、この3行で済む list<Node> node_list; list<int> server_sockfd = grid_socket(AF_INET, SOCK_STREAM, 0); vector<int> error = grid_connect(server_sockfd, node_list);
  34. 34. 同期• プロセス間の同期ならmutexを使えば良 い• ネットワーク越しの同期ならば?    →同等の機能があると嬉しい
  35. 35. デモプログラムでは• そもそも、分散コンパイルでは     同期を殆ど取る必要が無い• スレッドの同期に落とし込んで同期を取 れば十分
  36. 36. もっと複雑なプログラムだと、中央のノードを介さない同期 等も必要になる
  37. 37. その辺のお世話はOSがやりましょう、 という話です
  38. 38. メモリの同期• デモプログラムでは、メモリに書き込ま れたデータをソケット通信で送っていた
  39. 39. メモリの同期• メモリの同期はOSがその実力を発揮で きる場所• CPUの機能を使えば、容易に同期が取れ る
  40. 40. メモリの同期ノードAプロセス カーネルノードBプロセス カーネル
  41. 41. メモリの同期ノードAプロセス カーネル メモリ書き込みノードBプロセス カーネル
  42. 42. メモリの同期ノードAプロセス カーネル メモリアクセス検出ノードBプロセス カーネル
  43. 43. メモリの同期ノードAプロセス カーネル ページフォルトノードBプロセス カーネル
  44. 44. メモリの同期ノードAプロセス カーネル 書き込まれたデータを転送ノードBプロセス カーネル
  45. 45. メモリの同期ノードAプロセス カーネル データの反映ノードBプロセス カーネル
  46. 46. メモリの同期• データを同期したいと思ったら、メモリ の特定領域を共有メモリ化して、そこに memcpyなりなんなりで書き込めば良い だけ• プロセス間共有メモリと同じように扱え る
  47. 47. 仮想ファイル• OSは、各ノード間でファイルを共有 し、他のノード上のファイルへの透過的 なアクセスを提供できる• プログラマは、ファイルの同期を気にす る必要が無い
  48. 48. 仮想ファイル• 実装は簡単で、カーネルがファイルの実 体を持つノードのカーネルとデータをや りとりするだけ
  49. 49. デモプログラムではfstatシステムコールでタイムスタンプを確認して、ノードに問い合わせて、ノードもfstatシステムコールを実行して、古いファイルならばそれをクライアントに伝えて、クライアントはopenシステムコールでファイルを開いて、readシステムコールで読んで、サーバーはクライアントからファイルを受け取ると、openシステムコールとreadシステムコールでまた書き込む・・・
  50. 50. システムコールの呼び出しって結構コストが掛かるんですよ?
  51. 51. こういう事はOSがやってあげれば良いじゃないですか
  52. 52. // 同期 // 同期が必要かどうかを伝達if (is_need_to_sync == 1) { server->WriteNumber(server->IsNotLocalHost()); while (true) { server->ReadString(tmp, ok.size()); int fn_size = client.ReadNumber(); if (tmp != ok) { if (fn_size == 0) { cout << "Allba: error: system error" << endl; break; return -1; } } client.WriteString(ok); bool is_need_sync = true; この、クライアントと string sync_filename; list<string>::iterator it2 = ip_list.begin(); client.ReadString(sync_filename, fn_size); while (it2 != ip_list.end()) { if (*it2 == (*it).ip_addr) { struct stat stat_tmp; is_need_sync = false; int stat_status = stat(sync_filename.c_str(), &stat_tmp); break; } サーバー合わせて150行 client.WriteString(ok); ++it2; } time_t time = (time_t) client.ReadNumber(); server_list_.push_back(server); if (time <= stat_tmp.st_mtime && stat_status != -1) { if (server->IsNotLocalHost() == 1) { client.WriteString(ok); if (!is_need_sync) { continue; server->WriteNumber(0); のコードなんて、 } ++it; cout << "refreshing " << sync_filename << endl; continue; string no = "no"; } client.WriteString(no); cout << "sync starting..." << endl; int outputfile_length = client.ReadNumber(); list<string>::iterator it3 = sync_list_.begin(); while (it3 != sync_list_.end()) { client.WriteString(ok); server->WriteNumber((*it3).size()); server->ReadString(tmp, ok.size()); string outputfile; if (tmp != ok) { cout << "Allba: error: system error" << endl; char *file_data = new char[outputfile_length]; return -1; } client.ReadString(file_data, outputfile_length); tmp = *it3; FILE *fp = fopen(sync_filename.c_str(), "wb"); server->WriteString(tmp); fseek(fp, 0, SEEK_SET); server->ReadString(tmp, ok.size()); fp); fwrite(file_data, sizeof(char), outputfile_length, if (tmp != ok) { cout << "Allba: error: system error" << endl; return -1;
  53. 53. ノードA プロセス仮想ファイル経由でアクセスすれば ノードB プロセス 仮想ファイル
  54. 54. 「一行」もコードを書かなくて良いんです
  55. 55. まとめるならば、
  56. 56. 分散処理をより容易にする、それが僕のやりたい事です
  57. 57. 僕がラボユースでやった事
  58. 58. • 分散処理の勉強• 既存OSの実装を勉強• クラウドOSの設計• OSの開発
  59. 59. OSの「開発」では、基礎の構築を行っていました
  60. 60. • メモリ管理• システムコール• ファイルシステム• デバイスドライバ• スケジューリング
  61. 61. 今後の実装予定• Ethernetドライバの実装• プロトコルスタックの実装• 分散処理システムのサポート• アプリケーション実行環境の整備• Linuxのドライバの移植
  62. 62. 最後に(感想とか)• 1年という時間はOSを作るには短すぎ るけれど、やれる事はやったと思う• OS開発では、バグが発生すると1ヶ月 開発が止まる事もしばしば。そういう時 にラボのメンバーに相談できるのは心強 かった
  63. 63. 最後に(感想とか)• この中にOS開発に興味がある学生がい れば、ラボユースに申し込むと良いかも• OSASKの川合さん含め、ラボのメンバー がサポートしてくれます

×