Binary file Images/apibase.pdf has changed

Binary file Images/apihukusu.pdf has changed

Binary file Images/gitlab.pdf has changed

Binary file Images/nagi.graffle has changed

Binary file mid_thesis.pdf has changed

--- a/mid_thesis.tex	Fri Sep 11 19:02:24 2020 +0900
+++ b/mid_thesis.tex	Mon Sep 14 19:01:21 2020 +0900
@@ -3,58 +3,79 @@
 \usepackage{multicol}
 \usepackage{picins}
 \usepackage{fancyhdr}
+\usepackage{here}
+%\usepackage{indentfirst}
 \lhead{\parpic{\includegraphics[height=1zw,keepaspectratio,bb=0 0 251 246]{pic/emblem-bitmap.pdf}}琉球大学主催 工学部工学科知能情報コース 中間発表予稿}
 \usepackage[top=2cm, bottom=2cm, left=1cm, right=1cm]{geometry}
 
 
 \begin{document}
 
-\title{情報工学科演習用のコンテナ技術を用いた新規サービスの設計・実装
-       Design and Implementation of New service using container technology for Information science exercise}
+\title{情報工学科演習用のコンテナ技術を用いたサービスの設計・実装
+       Design and Implementation of service using container technology for Information science exercise}
 \author{175733E 氏名 {宮平 賢}{Miyahira Ken} 指導教員 : {河野 真治} }
 %\date{}
 
 \maketitle
 \begin{abstract}
 情報技術の普及に伴い情報系の学生が課題や演習を行う学習環境が必要である。
-この学習環境では, 課題や演習によっては並列処理により, CPU より GPU が必要となる場合がある。
-このような学習環境を複数の学生に提供する方法として, VM や コンテナがある。
-しかし, 琉球大学工学部で運用している VM 貸出サービスでは, GPU の共有に対応していない。
-そこで, コンテナを利用することができる Docker と Singularity を用いて, オンプレミス環境でコンテナ貸出サービスを提供する。
-また, PC 上からコンテナへの操作を可能にするために Kubernetes でのコンテナ作成にも対応する。
-コンテナ貸出サービスは LDAP で管理された学生のアカウントを使用することで, 適切にコンテナの管理を行う。
-本稿ではサービスを実装する上で必要な技術概要を延べ, サービスの設計・実装を行う。
+学習環境を複数の学生に提供する方法として, VM や コンテナがある。
+琉球大学工学部では VM 貸出サービスがある。
+課題や演習によっては CPU より GPU が必要となる場合がある。
+しかし, 本コースの VM 貸出サービスは GPU の共有に対応していない。
+そこで, コンテナ仮想化技術を利用できる Docker と Kubernetes, Singularity を用いて, GPU を含む学習環境を提供する。
+本稿では学習環境を提供するサービスの設計・実装を行う。
+
+%この学習環境では, 課題や演習によっては並列処理により, CPU より GPU が必要となる場合がある。
+%このような学習環境を複数の学生に提供する方法として, VM や コンテナがある。
+%しかし, 琉球大学工学部で運用している VM 貸出サービスでは, GPU の共有に対応していない。
+%また, PC 上からコンテナへの操作を可能にするために Kubernetes でのコンテナ作成にも対応する。
+%コンテナ貸出サービスは LDAP で管理された学生のアカウントを使用することで, 適切にコンテナの管理を行う。
+%本稿ではサービスを実装する上で必要な技術概要を延べ, サービスの設計・実装を行う。
+\end{abstract}
+
+
+\renewcommand{\abstractname}{Abstract}
+\begin{abstract}
+With the spread of information technology, there is a need for a learning environment in which information students can do assignments and exercises. 
+There are VMs and containers as a way to provide a learning environment for multiple students. 
+The Information science of the University of the Ryukyus has a VM rental service.
+Some assignments and exercises require GPUs rather than CPUs. 
+However, the VM rental service in this course does not support GPU sharing. 
+Therefore, we provide a learning environment that includes GPUs using Docker, Kubernetes and Singularity, which can utilize container virtualization technologies.
+In this paper, we design and implement a service that provides a learning environment.
 \end{abstract}
 
 \thispagestyle{fancy}
 
 \begin{multicols*}{2}
-\section{はじめに}
+\section{コンテナ技術を用いた学習環境の提供}
 情報通信技術の普及に伴い学生が学ぶ学習環境が必要となる。その学習環境として VM や コンテナにより, 手軽に開発し試せる技術が普及している。
 だが, 手元の PC 上で VM や コンテナを立ち上げ, 開発を行うことはできるが, VM や コンテナの使用には高性能 PC や 有料のクラウドサービスが必要になる場合がある。
 この大きな負担を学生に負わせない仕組みが必要である。
 \par
-琉球大学工学部工学科知能情報コースでは新たに人工知能やシステム開発などの先端技術を身につける講義や実験が設けられた。
-講義の演習や実験は学生の PC で環境を構築し実行する。
+%琉球大学工学部工学科知能情報コースでは新たに人工知能やシステム開発などの先端技術を身につける講義や実験が設けられた。
+%講義の演習や実験は学生の PC で環境を構築し実行する。
 本コースでは希望する学生に学科のブレードサーバから仮想環境を貸出すサービスを行なっている。
-貸出をする VM のデフォルトのスペックは CPU 1コア, メモリ 1GB, ストレージ 10GB である。
-デフォルトのスペックでは不足する場合, 要望に応じてスペックの変更を行なっている。
-だが, 貸出 VM でも課題によってはスペックが足りなく, 処理に時間がかかることがあった。
-例として, 人工知能の講義において課される課題においては CPU より GPU を用いることで処理時間を早くすることができる。
+貸出 VM スペックは CPU 1コア, メモリ 1GB, ストレージ 10GB である。
+このスペックで不足する場合, 要望に応じてスペックの変更を行なっている。
+だが, 貸出 VM でも課題によっては処理に時間がかかることがある。
+例として, 人工知能の講義において課される課題においては CPU より GPU が必要となる場合がある。
 しかし, 現在の VM 貸出サービスでは GPU の共有に対応していない。
 VM 上で GPU を共有するには PCI パススルーを利用することで可能だが, PCI パススルーでは複数の VM に共有することができない。
-GPU が搭載されている PC は研究室によっては用意されているが, 研究室に所属していない学生は利用することができない。
-そのため, 本コースの学生が高性能な環境を利用できる新たな仕組みが必要である。
-\par
-学科のブレードサーバに搭載される GPU は VM の貸出サービスでは利用することができない。そこでコンテナ技術を利用する。
-コンテナ管理ソフトウェアである Docker\cite{docker} では NVIDIA Container Toolkit である nvidia-docker\cite{nvidia-docker} を利用することで, 複数のコンテナで GPU を共有することができる。
-Docker は基本的に root 権限で動作する。また一般ユーザが docker コマンドを使用するには docker グループに追加する必要がある。
-そのため Docker をマルチユーザ環境で使用すると, 他ユーザのコンテナを操作できるなどセキュリティ上の問題がある。\par
-そこで, 本論文では, Docker とマルチユーザ環境で利用しやすいコンテナプラットフォームである Singularity\cite{singu} を利用したコンテナ貸出サービスを設計・実装する。
-このコンテナ貸出サービスでは, Web コンソールからコンテナの管理をすることで他ユーザのコンテナへの操作をさせない。
+そこで, GPU を含めた学習環境をコンテナ技術を用いて提供するサービスの設計・実装を行う。
+%GPU が搭載されている PC は研究室によっては用意されているが, 研究室に所属していない学生は利用することができない。
+%そのため, 本コースの学生が高性能な環境を利用できる新たな仕組みが必要である。
+%\par
+%学科のブレードサーバに搭載される GPU は VM の貸出サービスでは利用することができない。そこでコンテナ技術を利用する。
+%コンテナ管理ソフトウェアである Docker\cite{docker} では NVIDIA Container Toolkit である nvidia-docker\cite{nvidia-docker} を利用することで, 複数のコンテナで GPU を共有することができる。
+%Docker は基本的に root 権限で動作する。また一般ユーザが docker コマンドを使用するには docker グループに追加する必要がある。
+%そのため Docker をマルチユーザ環境で使用すると, 他ユーザのコンテナを操作できるなどセキュリティ上の問題がある。\par
+%そこで, 本論文では, Docker とマルチユーザ環境で利用しやすいコンテナプラットフォームである Singularity\cite{singu} を利用したコンテナ貸出サービスを設計・実装する。
+%このコンテナ貸出サービスでは, Web コンソールからコンテナの管理をすることで他ユーザのコンテナへの操作をさせない。
 
 \section{技術概要}
-本研究で使用した仮想化技術, コンテナ技術, また本コースで利用しているサービスについての概要を説明する。
+%本研究で使用した仮想化技術, コンテナ技術, また本コースで利用しているサービスについての概要を説明する。
 
 \subsection{Docker}
 Docker とは OS レベルの仮想化技術を利用して, ソフトウェアをコンテナと呼ばれるパッケージで提供する。またコンテナの実行だけでなく, 
@@ -65,51 +86,51 @@
 \subsection{Kubernetes}
 Kubernetes\cite{k8s} とは, アプリケーションのデプロイ, スケーリング, 及び管理を用意にするためのコンテナを動的管理するコンテナオーケストレーションである。
 Kubernetes ではオブジェクトによりクラスターの状態を表現する。オブジェクトはコンテナだけでなく, ネットワークやストレージ, 接続ポリシーの望ましい状態を記述できる。
-本研究では以下のオブジェクトを主に利用する。
-\begin{itemize}
-  \item Pod
-  \begin{itemize}
-      \item Kubernetes で作成, 管理できる最小単位。Pod 内に 1 つ以上のコンテナを起動できる。
-  \end{itemize}
-
-  \item ReplicaSet 
-  \begin{itemize}
-      \item 安定した Pod の維持を行い, クラスタで必要な Pod 数を管理する。Pod のセルフヒーリングを行う。
-  \end{itemize}
-
-  \item Deployment
-  \begin{itemize}
-      \item ReplicaSet のロールアウトを図るなど, 管理を行う。
-  \end{itemize}
-
-  \item Service
-  \begin{itemize}
-      \item Pod にアクセスするための IP アドレスやポートを割り振る。
-  \end{itemize}
-
-  \item Ingress
-  \begin{itemize}
-      \item 外部からのアクセスを管理する。負荷分散, SSL 終端, 名前ベースの仮想ホスティングの機能を提供する。
-  \end{itemize}
-
-  \item Namespace
-  \begin{itemize}
-      \item 仮想クラスタとしてグループ化して取り扱える。
-  \end{itemize}
-
-  \item Role
-  \begin{itemize}
-      \item Kubernetes API の利用権限 Namespace ごとに定義する。
-  \end{itemize}
-
-  \item RoleBinding
-  \begin{itemize}
-      \item ユーザやグループに Role を関連付ける。
-  \end{itemize}
-\end{itemize}
+%本研究では以下のオブジェクトを主に利用する。
+%\begin{itemize}
+%  \item Pod
+%  \begin{itemize}
+%      \item Kubernetes で作成, 管理できる最小単位。Pod 内に 1 つ以上のコンテナを起動できる。
+%  \end{itemize}
+%
+%  \item ReplicaSet 
+%  \begin{itemize}
+%      \item 安定した Pod の維持を行い, クラスタで必要な Pod 数を管理する。Pod のセルフヒーリングを行う。
+%  \end{itemize}
+%
+%  \item Deployment
+%  \begin{itemize}
+%      \item ReplicaSet のロールアウトを図るなど, 管理を行う。
+%  \end{itemize}
+%
+%  \item Service
+%  \begin{itemize}
+%      \item Pod にアクセスするための IP アドレスやポートを割り振る。
+%  \end{itemize}
+%
+%  \item Ingress
+%  \begin{itemize}
+%      \item 外部からのアクセスを管理する。負荷分散, SSL 終端, 名前ベースの仮想ホスティングの機能を提供する。
+%  \end{itemize}
+%
+%  \item Namespace
+%  \begin{itemize}
+%      \item 仮想クラスタとしてグループ化して取り扱える。
+%  \end{itemize}
+%
+%  \item Role
+%  \begin{itemize}
+%      \item Kubernetes API の利用権限 Namespace ごとに定義する。
+%  \end{itemize}
+%
+%  \item RoleBinding
+%  \begin{itemize}
+%      \item ユーザやグループに Role を関連付ける。
+%  \end{itemize}
+%\end{itemize}
 
 \subsection{Singularity}
-Singularity とは, HCP クラスタ上で複雑なアプリケーションを実行するために開発されたコンテナプラットフォームである。
+Singularity とは, HPC クラスタ上で複雑なアプリケーションを実行するために開発されたコンテナプラットフォームである。
 Singularity は マルチユーザに対応しており, コンテナ内での権限は実行ユーザの権限を引き継ぐため, ユーザに特別な権限の設定が必要ない。
 またデフォルトで, \$HOME, /tmp, /proc, /sys, /dev がコンテナにマウントされ, サーバ上の GPU を簡単に利用できる。
 Singularity のコンテナイメージは Docker Hub に登録されているイメージ, またはDockerfile から作成したイメージを変換することで利用することができる。
@@ -124,38 +145,50 @@
 \par
 GitLab Runner とは, ビルドのためのアプリケーションであり, GitLab CI と連携することで別の場所でビルドを動かすことができる。
 
-\subsection{Kernel-based Virtual Machine (KVM)}
-KVM\cite{kvm} とは, Linux 自体を VM の実行基盤として機能させるソフトウェアである。
-CPU の仮想化支援機能を必要とし, 完全仮想化により OS の仮想化環境を提供する。
-
-\subsection{ie-virsh}
-ie-virsh\cite{ie-virsh} とは, 本コースの Operating System という講義に向けに libvirt の CLI である virsh をラップし複数のユーザで利用することができる VM 管理ツールである。
-学生が手元の PC で作成した VM をブレードサーバ上にデプロイすることができる。
-
-\subsection{ie-docker}
-ie-docker とは Docker をラップし複数のユーザで利用することのできるコンテナ管理ツールである。
-利用する学生は ssh でブレードサーバへ接続し, ie-docker を使用してコンテナを操作することができる。
-
+%\subsection{Kernel-based Virtual Machine (KVM)}
+%KVM\cite{kvm} とは, Linux 自体を VM の実行基盤として機能させるソフトウェアである。
+%CPU の仮想化支援機能を必要とし, 完全仮想化により OS の仮想化環境を提供する。
+%
+%\subsection{ie-virsh}
+%ie-virsh\cite{ie-virsh} とは, 本コースの Operating System という講義に向けに libvirt の CLI である virsh をラップし複数のユーザで利用することができる VM 管理ツールである。
+%学生が手元の PC で作成した VM をブレードサーバ上にデプロイすることができる。
+%
+%\subsection{ie-docker}
+%ie-docker とは Docker をラップし複数のユーザで利用することのできるコンテナ管理ツールである。
+%利用する学生は ssh でブレードサーバへ接続し, ie-docker を使用してコンテナを操作することができる。
+%
 \subsection{digdog}
-digdog とは Kubernetes を利用し Web コンソールからコンテナを作成することができるコンテナ貸出サービスである。
+digdog\cite{digdog} とは Kubernetes を利用し Web コンソールからコンテナを作成することができるコンテナ貸出サービスである。
 学生は学科アカウントを使用して Web サービスへログインし, 登録されている Docker イメージでコンテナを作成することができる。
 
 \section{サービスの設計}
-サービスでは本コースの学生や教員がにコンテナ貸出を行う。このコンテナ貸出の構成を図\ref{fig:wm} に示し, 概要を以下で説明する。
+%サービスでは本コースの学生や教員がにコンテナ貸出を行う。このコンテナ貸出の構成を図\ref{fig:wm} に示し, 概要を以下で説明する。
+
+サービスは本コースの学生や教員が利用する。そのため, ユーザが他のユーザのコンテナの削除などの操作を行えないように制限をするなどの, マルチユーザ環境へ対応する必要がある。
+また, 管理者にコンテナで利用するイメージを用意してもらうのではなく, 利用したい学習環境をユーザが構築できる仕組みが必要である。
+GPU を含む学習環境を提供するために, 複数のコンテナへ GPU を共有できる仕組み, またコンテナへのファイルの共有ができる仕組みが必要となる。
 
-\subsection{コンテナの作成}
-学生または教員は学科アカウントで Web コンソールへログインする。Web コンソールでは ユーザのコンテナ一覧や Docker イメージ一覧を確認することができる。
+%コンテナによる学習環境にあたっては以下の用件が必要となる。
+%
+%\begin{itemize}
+%  \setlength{\parskip}{0cm} % 段落間
+%  \setlength{\itemsep}{0cm} % 項目間
+%  \item マルチユーザへの対応
+%  \item イメージを自由に作成できる
+%  \item GPU が利用できる
+%  \item コンテナへファイルの共有ができる
+%\end{itemize}
+
+\subsection{マルチユーザへの対応}
+Docker は基本的に root 権限で動作する。また一般ユーザが docker コマンドを使用するには docker グループに追加する必要がある。
+そのため docker グループに追加されたユーザは, 他ユーザのコンテナを操作できるなどセキュリティ上の問題がある。
+\par
+そこで, Web コンソールを用いて管理を行う。 Web コンソールには学科のアカウントを用いてログインし, コンテナの作成や操作を可能とする。
 コンテナ作成は Docker コンテナと Kubernetes コンテナの 2つから選択することができる。
 コンテナ作成を選択するとコンテナを作成するために必要な情報を入力する。入力する内容は表\ref{tb:wmcon} である。
-コンテナ名にはユーザのアカウント名が補完されるため, 他のユーザと被ることはない。
-Docker イメージには Docker Hub に登録されているイメージや, ユーザが作成したイメージを入力することができる。
-環境変数とゲストポートはスペース区切りで複数入力することができる。
-また, コンテナ内で GPU を使用するにはチェックボックスにチェックを入れる。
-ホストポートは, エフェメラルポートの範囲から設定される。ユーザは設定されたホストポートを使用してコンテナのサービスへアクセスする。
-また, ユーザは Docker コンテナに対しては Web コンソールから, Kubernetes コンテナには手元の PC から操作することができる。
-必要なくなったコンテナは Web コンソールのコンテナ一覧から削除することができる。
+作成時にコンテナ名をユーザのアカウント名で補完されるため, 他のユーザと被ることはない。
 
-\begin{table}[htb]
+\begin{table}[H]
   \begin{center}
   \caption{コンテナ作成時の入力内容}
   \begin{tabular}{c|l} \hline
@@ -169,21 +202,96 @@
   \end{center}
 \end{table}
 
+%\subsection{コンテナの作成}
+%学生または教員は学科アカウントで Web コンソールへログインする。Web コンソールでは ユーザのコンテナ一覧や Docker イメージ一覧を確認することができる。
+%コンテナ作成は Docker コンテナと Kubernetes コンテナの 2つから選択することができる。
+%コンテナ作成を選択するとコンテナを作成するために必要な情報を入力する。入力する内容は表\ref{tb:wmcon} である。
+%コンテナ名にはユーザのアカウント名が補完されるため, 他のユーザと被ることはない。
+%Docker イメージには Docker Hub に登録されているイメージや, ユーザが作成したイメージを入力することができる。
+%環境変数とゲストポートはスペース区切りで複数入力することができる。
+%また, コンテナ内で GPU を使用するにはチェックボックスにチェックを入れる。
+%ホストポートは, エフェメラルポートの範囲から設定される。ユーザは設定されたホストポートを使用してコンテナのサービスへアクセスする。
+%また, ユーザは Docker コンテナに対しては Web コンソールから, Kubernetes コンテナには手元の PC から操作することができる。
+%必要なくなったコンテナは Web コンソールのコンテナ一覧から削除することができる。
+%
+%\begin{table}[H]
+%  \begin{center}
+%  \caption{コンテナ作成時の入力内容}
+%  \begin{tabular}{c|l} \hline
+%    ContainerName  & コンテナ名 \\ \hline
+%    Image & Docker イメージ \\ \hline
+%    Environments & コンテナ作成時の環境変数 \\ \hline
+%    GuestPort & コンテナが使用するポート番号 \\ \hline
+%    GPU & GPU を使用するか \\ \hline
+%    \end{tabular}
+%  \label{tb:wmcon}
+%  \end{center}
+%\end{table}
+
 \subsection{イメージの作成}
-Docker イメージの作成は学科で使用している GitLab の CI/CD の CI 機能を利用する。
+Docker イメージの作成は学科で使用している GitLab の CI/CD の CI 機能を利用する。ユーザがイメージを作成する流れを図\ref{fig:gitlab} に示す。
 ユーザは学科 GitLab から CI トークンを取得し, Web コンソールに取得したトークンをセットする。この時 Docker 側に GitLab Runner の立ち上げを依頼する。
 トークンの設定後, Web コンソールから CI 用の YAML ファイルをダウンロードし Dockerfile と一緒に学科 GitLab のリポジトリにプッシュする。
-Docker イメージのビルドが成功すると Web コンソールのイメージ一覧で確認ができる。作成した Docker イメージは編集からイメージの使い方の記述や他の学生に共有するか設定を行える。
-必要なくなったイメージは Web コンソールのイメージ一覧から削除することができる。
+GitLab にプッシュした Dockerfile が GitLab Runner 上でビルドされる。
+ビルドの成否は GitLab から確認することができ, 作成されたイメージは Web コンソールから確認することができる。
+GitLab の CI/CD 機能を利用することで, 学生に権限を与えることなくイメージの作成を行うことが可能となる。
+
+%Docker イメージのビルドが成功すると Web コンソールのイメージ一覧で確認ができる。作成した Docker イメージは編集からイメージの使い方の記述や他の学生に共有するか設定を行える。
+%必要なくなったイメージは Web コンソールのイメージ一覧から削除することができる。
 
-\subsection{Singularity の利用}
+\begin{figure}[H]
+    \begin{center}
+        \includegraphics[width=95mm]{Images/gitlab.pdf}
+    \end{center}
+    \caption{イメージの作成}
+    \label{fig:gitlab}
+\end{figure}
+
+\subsection{GPU の利用}
+Docker では NVIDIA Container Toolkit である nvidia-docker\cite{nvidia-docker} を利用する。
+GPU を利用するための環境が整っている nvidia/cuda を用いてイメージの作成を行う。
+作成したイメージをコンテナ作成時の表\ref{tb:wmcon} の Docker イメージに入力する。
+また GPU を利用するかのチェックを入れることで, コンテナへ GPU を共有することが可能となる。
+
+\subsection{ファイルの共有}
 コンテナに大量のデータを送信する必要がある場合や, データを永続化させたい場合に Singularity を利用する。
-Singularity は Docker イメージを変換し使用できるが, イメージの変換には sudo 権限が必要となる。
-Docker イメージの変換を申請性にすると, 管理者の仕事が増え, またユーザも利用しづらい。
 Singularity はユーザ権限で動作することから, 学生が ssh でブレードサーバへ接続し利用する方が適している。
+Singularity は Docker イメージを変換し使用できる。
+だが, イメージの変換には sudo 権限が必要となる。
+%Docker イメージの変換を申請性にすると, 管理者の仕事が増え, またユーザも利用しづらい。
 そこで, Web コンソールから Singularity 用のイメージをダウンロードできる仕様とする。\par
 ユーザは利用したいイメージをダウンロードし, ブレードサーバへ送信して Singularity を使用する。Singularity を利用する流れを図\ref{fig:singu} に示す。
 
+\begin{figure}[H]
+    \begin{center}
+        \includegraphics[width=80mm]{Images/singularity.pdf}
+    \end{center}
+    \caption{Singularityの利用}
+    \label{fig:singu}
+\end{figure}
+
+\section{サービスの実装}
+%本コースでは学科システムを教員の指導の下, 学生主体でシステム管理チームと呼ばれる組織によって構築・運用・管理が行われている。
+%学科システムはブレードサーバを 4 台, SAN 用ストレージと汎用ストレージをそれぞれ 2台ずつ導入している。本コースの基幹サービスはこのブレードサーバの仮想環境上で VM として動作している。
+%新たにサービスを実装するとなると, システム管理チームが運用・管理を行いやすい実装にする必要がある。\par
+%Web コンソールや Docker の操作を 1 つにまとめると, Docker コンテナの作成が 1台のブレードサーバのみになってしまう。
+%そこで, コンテナ貸出システムは, 機能ごとに以下の 3 つにサービスに分ける。
+%Docker や Kubernetes の操作を HTTP API で提供することにより, リクエスト先を変更することで複数のブレードサーバにコンテナを分散することができる。
+%だが, 現時点では未実装である。
+
+サービスのシステム構成を図\ref{fig:wm} に示す。
+Web コンソールで Docker や Kubernetes の操作をまとめるのではなく, 機能ごとに以下の 3 つにサービスを分ける。
+Web コンソールから HTTP API で各機能へリクエストを送信し操作を行う。
+\par
+実装にはDocker や Kubernetes の実装言語であり, 操作するためのライブラリが揃っている Go 言語を使用する。
+\begin{itemize}
+  \setlength{\parskip}{0cm} % 段落間
+  \setlength{\itemsep}{0cm} % 項目間
+  \item Web コンソール
+  \item Docker の操作
+  \item Kubernetes の操作
+\end{itemize}
+
 \begin{figure*}[tb]
     \begin{center}
         \includegraphics[width=100mm]{Images/whalemountain.pdf}
@@ -192,37 +300,16 @@
     \label{fig:wm}
 \end{figure*}
 
-\begin{figure}[tb]
-    \begin{center}
-        \includegraphics[width=80mm]{Images/singularity.pdf}
-    \end{center}
-    \caption{Singularityの利用}
-    \label{fig:singu}
-\end{figure}
-
-\section{サービスの実装}
-本コースでは学科システムを教員の指導の下, 学生主体でシステム管理チームと呼ばれる組織によって構築・運用・管理が行われている。
-学科システムはブレードサーバを 4 台, SAN 用ストレージと汎用ストレージをそれぞれ 2台ずつ導入している。本コースの基幹サービスはこのブレードサーバの仮想環境上で VM として動作している。
-新たにサービスを実装するとなると, システム管理チームが運用・管理を行いやすい実装にする必要がある。\par
-Web コンソールや Docker の操作を 1 つにまとめると, Docker コンテナの作成が 1台のブレードサーバのみになってしまう。
-そこで, コンテナ貸出システムは, 機能ごとに以下の 3 つにサービスに分ける。
-Docker や Kubernetes の操作を HTTP API で提供することにより, リクエスト先を変更することで複数のブレードサーバにコンテナを分散することができる。
-だが, 現時点では未実装である。\par
-実装にはDocker や Kubernetes の実装言語であり, 操作するためのライブラリが揃っている Go 言語を使用する。
-\begin{itemize}
-  \item Web コンソール
-  \item Docker の操作
-  \item Kubernetes の操作
-\end{itemize}
-
 \subsection{Web コンソール}
 Web コンソールは本コースの学生や教員が利用するため, 学科アカウントでログインできる必要がある。学科の LDAP サーバを利用して学科アカウントで LDAP 認証を実装する。\par
-Docker の操作や Kubernetes の操作を行う HTTP API はセッション管理を行わないため, Web コンソールで管理する必要がある。
+%Docker の操作や Kubernetes の操作を行う HTTP API はセッション管理を行わないため, Web コンソールで管理する必要がある。
+Docker の操作や Kubernetes の操作を行う機能では, ユーザの管理を行わないため Web コンソールで管理する必要がある。
 そのため, ユーザのコンテナやイメージの情報をデータベースに格納して管理する。
-ユーザが作成する Docker イメージの情報を取得しユーザのアカウントID と紐付けを行う。また, 作成した Docker イメージは共有することができ, 共有されたイメージはユーザのイメージ一覧とは別の一覧で確認することができる。
-ユーザはコンテナ作成時にイメージを入力することができる。この時, 他のユーザが作成したイメージの場合, そのイメージが共有されたイメージなのか確認を行うことで, 非共有に設定されたイメージではコンテナの作成はできない。
-コンテナの操作を行う時, コンテナに紐づけられたアカウントID との確認が行われることで, 他のユーザのコンテナを操作することはできない。
-同様にイメージの削除を行う時にもアカウントID の確認が行われる。
+ユーザがコンテナやイメージの操作を行う時は, 紐づけられたアカウントID の確認を行うことで, 他のユーザのコンテナやイメージの操作を制限する。
+%ユーザが作成する Docker イメージの情報を取得しユーザのアカウントID と紐付けを行う。また, 作成した Docker イメージは共有することができ, 共有されたイメージはユーザのイメージ一覧とは別の一覧で確認することができる。
+%ユーザはコンテナ作成時にイメージを入力することができる。この時, 他のユーザが作成したイメージの場合, そのイメージが共有されたイメージなのか確認を行うことで, 非共有に設定されたイメージではコンテナの作成はできない。
+%コンテナの操作を行う時, コンテナに紐づけられたアカウントID との確認が行われることで, 他のユーザのコンテナを操作することはできない。
+%同様にイメージの削除を行う時にもアカウントID の確認が行われる。
 
 \subsection{Docker の操作}
 Docker は Docker Engine API を提供している。Docker デーモンは指定した IP アドレスと ポート を リッスンする。 IP アドレスと ポートの指定を行うことで外部から Docker の操作が可能になる。
@@ -230,6 +317,8 @@
 また, 本研究で実装するサービスでは Docker のすべての操作を必要としない。そこで, Docker の操作を行うための SDK \cite{sdk} を使用し, 必要な機能のみを実装する。\par
 サービスを提供する上で Docker の必要となる操作は以下である。
 \begin{itemize}
+  \setlength{\parskip}{0cm} % 段落間
+  \setlength{\itemsep}{0cm} % 項目間
   \item コンテナの作成
   \item コンテナの削除
   \item コンテナでのコマンド実行
@@ -238,37 +327,48 @@
   \item イメージの削除
 \end{itemize}
 
-コンテナは, 表\ref{tb:wmcon} で入力した情報を下に作成を行う。コンテナ名は Web コンソールからリクエストを送るタイミングで補完される。
-また, コンテナが属するネットワーク名も補完される。リクエストは JSON 形式でやり取りを行う。
-リクエストからコンテナを作成後, 作成したコンテナID やネットワークID, コンテナのステータスを返却する。
-返却したコンテナID やネットワークID を下にコンテナ削除やコマンドの実行, ファイルの送信を処理する。
-ファイルの送信では JSON 形式ではなく multipart/form-data 形式でリクエストを受ける。
-ユーザが作成するコンテナとは別に, GitLab CI/CD で Docker イメージをビルドするための GitLab Runner を立てる必要がある。
-立ち上げはユーザが Web コンソールで CD トークンの設定時に行われる。GitLab Runner をユーザごとに立ち上げることで, 複数のユーザが同時にビルドを行うことができる。\par
-Docker イメージは GitLab CI/CD を利用して作成するが, ビルドが成功したかを判断することはできない。
-そのため, Web コンソール側から 5 分に一度イメージの更新リクエストを受け, Docker イメージの一覧をリストにまとめ返却を行う。\par
+Web コンソールから JSON 形式でリクエストを受信する。このリクエストを元に上記の操作を行う。
+だが, ファイルの送信では JSON 形式ではなく, multipart/form-data 形式でリクエストを受ける。
+
+%コンテナは, 表\ref{tb:wmcon} で入力した情報を下に作成を行う。コンテナ名は Web コンソールからリクエストを送るタイミングで補完される。
+%また, コンテナが属するネットワーク名も補完される。リクエストは JSON 形式でやり取りを行う。
+%リクエストからコンテナを作成後, 作成したコンテナID やネットワークID, コンテナのステータスを返却する。
+%返却したコンテナID やネットワークID を下にコンテナ削除やコマンドの実行, ファイルの送信を処理する。
+%ファイルの送信では JSON 形式ではなく multipart/form-data 形式でリクエストを受ける。
+%ユーザが作成するコンテナとは別に, GitLab CI/CD で Docker イメージをビルドするための GitLab Runner を立てる必要がある。
+%立ち上げはユーザが Web コンソールで CD トークンの設定時に行われる。GitLab Runner をユーザごとに立ち上げることで, 複数のユーザが同時にビルドを行うことができる。\par
+%Docker イメージは GitLab CI/CD を利用して作成するが, ビルドが成功したかを判断することはできない。
+%そのため, Web コンソール側から 5 分に一度イメージの更新リクエストを受け, Docker イメージの一覧をリストにまとめ返却を行う。\par
 
 \subsection{Kubernetes の操作}
 Docker と同様に Kubernetes のすべての操作を必要としないため, Kubernetes と対話するためのライブラリである client-go \cite{kubecli} を使用し, 必要な機能のみを実装する。
 サービスを提供する上で Kubernetes の必要となる操作は以下である。
 
 \begin{itemize}
+  \setlength{\parskip}{0cm} % 段落間
+  \setlength{\itemsep}{0cm} % 項目間
   \item コンテナの作成
   \item コンテナの削除
   \item 認証トークンの取得
 \end{itemize}
 
-Kubernetes でのコンテナ作成は Pod を作成することである。 Kubernetes でのコンテナ作成は Namespace, Deployment, Service, 
-Ingress の流れでオブジェクトを作成する。コンテナの作成は Docker と同様に表\ref{tb:wmcon} の情報を下に作成する。
-作成するそれぞれのオブジェクト名は Web コンソールでコンテナ名とアカウントID で補完される。また, Namespace はアカウントID となる。
-コンテナの削除にはそれぞれのオブジェクト名と Namespace を用いる。\par
-Kubernetes で作成したコンテナは Web コンソールからコマンドの実行やファイルの送信などの操作を行わず, Role と RoleBinding を用いた Role-based access control (RBAC) 
-を利用することで手元の PC より操作を行うこととする。
-RBAC で使用する認証トークンはユーザごとに作成された Namespace に設定されるトークンを返すことで, 他のユーザが認証することはできない。
-またアクセス制御は Namespace ごとに設定されることで, 他のユーザのコンテナを操作することはできない。
-RBAC で許可するリソースの操作は表\ref{tb:wm} である。
+Docker と同様に Web コンソールから JSON 形式でリクエストを受信し, リクエストを元に上記の操作を行う。
+Kubernetes ではコンテナへのコマンドの実行やファイルの送信は実装せず, 認証のトークンを取得する機能を実装する。
+Kubernetes では, Kubernetes API の利用権限 Namespace ごとに定義する Role, ユーザやグループに Role を関連付ける RoleBinding がある。
+この Role と RoleBinding を用いた Role-based access control (RBAC) を利用することで手元の PC からコンテナに対して操作を行うことが可能となる。
+そのため, RBAC への認証トークンを取得する。RBAC で許可するリソースの操作は表\ref{tb:wm} である。
 
-\begin{table}[htb]
+%Kubernetes でのコンテナ作成は Pod を作成することである。 Kubernetes でのコンテナ作成は Namespace, Deployment, Service, 
+%Ingress の流れでオブジェクトを作成する。コンテナの作成は Docker と同様に表\ref{tb:wmcon} の情報を下に作成する。
+%作成するそれぞれのオブジェクト名は Web コンソールでコンテナ名とアカウントID で補完される。また, Namespace はアカウントID となる。
+%コンテナの削除にはそれぞれのオブジェクト名と Namespace を用いる。\par
+%Kubernetes で作成したコンテナは Web コンソールからコマンドの実行やファイルの送信などの操作を行わず, Role と RoleBinding を用いた Role-based access control (RBAC) 
+%を利用することで手元の PC より操作を行うこととする。
+%RBAC で使用する認証トークンはユーザごとに作成された Namespace に設定されるトークンを返すことで, 他のユーザが認証することはできない。
+%またアクセス制御は Namespace ごとに設定されることで, 他のユーザのコンテナを操作することはできない。
+%RBAC で許可するリソースの操作は表\ref{tb:wm} である。
+
+\begin{table}[H]
   \begin{center}
   \caption{kubectl のコマンド}
   \begin{tabular}{c|l} \hline
@@ -281,118 +381,130 @@
   \end{center}
 \end{table}
 
-
 %\section{サービスの評価}
 
-\section{他のサービスとの比較}
-今回作成した Web サービスは主に学生の学習環境をコンテナ技術を利用して提供する。
-そこで, これまで本コースで使用されてきたサービス, また近年普及しているクラウドサービスと比較する。
-
-\subsection{ie-virsh}
-ie-virsh は手元の PC で作成した VM を学科のブレードサーバにデプロイできるサービスである。
-ie-virsh は ユーザの UID 及び GID 情報を取得することで, 他のユーザの VM を操作させない。表\ref{tb:ie-virsh}は ユーザが利用できる ie-virsh の機能である。
-ie-virsh では VM の実行環境を提供するため, ユーザが好みの VM を構築できるなど自由度が高い。\par
-本研究で実装したサービスでは, コンテナ作成に使用する Docker イメージで構築されたアプリケーションに限定される。
-また, ユーザが欲しい環境は Docker イメージを作成しなければいけないため, Docker について学習する必要がある。
-だが, コンテナは VM と違い開発環境やテスト環境の構築の容易さや, 他のユーザにイメージを共有することで同じ環境を利用することができるなどの良さがある。
-
-\begin{table}[htb]
-  \begin{center}
-  \caption{ie-virsh のコマンド}
-  \begin{tabular}{c|l} \hline
-    define  & XML の template を下に domain を作成 \\ \hline
-    undefine & define で作成した domain を削除 \\ \hline
-    list & define で作成した domain の一覧表示 \\ \hline
-    start & 指定した domain 名の VM を起動 \\ \hline
-    destroy & 指定した domain 名の VM を停止 \\ \hline
-    dumpxml & domain の XML を参照 \\ \hline
-    \end{tabular}
-  \label{tb:ie-virsh}
-  \end{center}
-\end{table}
-
-\subsection{ie-docker}
-ie-docker は Docker をラップしたツールであり, ユーザは学科のブレードサーバへ ssh で接続を行い CUI から利用することができる。
-ie-docker は ユーザの UID 及び GID 情報を取得することで, 他のユーザのコンテナを操作させない。
-表\ref{tb:ie-docker} は ie-docker で利用できる機能である。
-この機能を使用しコンテナ作成などの操作を行うことができる。
-だが, ie-docker ではユーザがコンテナで使用するイメージを管理者が用意する必要がある。
-そのため, コンテナで使用したいイメージが用意されていないなどの問題があった。\par
-本研究で実装したサービスでは, コンテナで使用するイメージは Docker Hub に登録されているイメージ, または作成したイメージを利用することができる。
-ユーザが Docker イメージを作成できることで管理者の負担が少なくなると考える。
-
-\begin{table}[htb]
-  \begin{center}
-  \caption{ie-docker のコマンド}
-  \begin{tabular}{c|l} \hline
-    ps  & 起動中のコンテナの一覧を表示する \\ \hline
-    run & コンテナを作成する \\ \hline
-    start & コンテナを起動する \\ \hline
-    stop & コンテナを停止する \\ \hline
-    attach & 起動しているコンテナに attach する \\ \hline
-    cp & コンテナにファイルを送信する \\ \hline
-    rm & コンテナを削除する \\ \hline
-    \end{tabular}
-  \label{tb:ie-docker}
-  \end{center}
-\end{table}
-
-\subsection{digdog}
-digdog は Kubernetes を利用したコンテナ貸出サービスである。
-学生は Dockerfile を GitLab CI/CD を利用してビルドし, 学科の GitLab Container Registry に Docker イメージを登録する。
-Web コンソールからコンテナ作成で使用するイメージは, 登録したイメージから選択することができる。
-Kubernetes 上にコンテナを作成するため, 学生の入力を下に Deployment, Service, Ingress の作成を行う。
-また, Namespace はユーザのアカウントID で作成され, Namespace ごとに RBAC の設定がされている。
-そのため, 学生は手元の PC から Web コンソールから作成したコンテナを操作することができる。
-表\ref{tb:digdog} は RBAC で許可されているリソースの操作である。\par
-本研究のサービスは digdog を参考に実装されている。そのため, Kubernetes でのコンテナ作成は digdog と同じ流れで作成を行う。
-だが, digdog では Docker Hub に登録されているイメージを選択することができない。
-また, Kubernetes でのコンテナ貸出のため, Kubernetes クラスター上の Master が停止するとサービスを提供できないなどの課題があった。
-本研究のサービスでは, Kubernetes でのコンテナの作成だけでなく, Docker でのコンテナの作成にも対応することで, Docker のみでサービスの提供ができるように改良を行った。
-また, コンテナ作成時のイメージを選択ではなく入力にすることで, Docker Hub に登録されているイメージを利用できるように改良を行った。
-
-\begin{table}[htb]
-  \begin{center}
-  \caption{kubectl のコマンド}
-  \begin{tabular}{c|l} \hline
-    get  & Pod の一覧を表示する \\ \hline
-    log & Pod の Log を表示する \\ \hline
-    exec & Pod にアクセスする \\ \hline
-    \end{tabular}
-  \label{tb:digdog}
-  \end{center}
-\end{table}
-
-\subsection{クラウドサービス}
-近年様々なクラウドサービスが普及し手元の PC から高性能なクラウド環境を利用することができる。
-だが, クラウドサービスは無料から有料まであり。無料では時間制限や容量制限など様々な制限がある。
-また有料だと設定のミスにより高額な請求がくるなど, 気軽に利用しづらい。
-そのため, 本サービスはオンプレミス環境で実装を行った。
-オンプレミス環境にすることで利用の制限がなく, サービスで使用するデータを自身で管理できるなどの良さがある。
-だが, クラウドサービスと違い物理サーバなどのメンテナンスや, サービスの導入にあたって環境構築などの課題がある。
-しかし, オンプレミスで運用していくことで, 学生の学習に繋がると考える。
+%\section{他のサービスとの比較}
+%今回作成した Web サービスは主に学生の学習環境をコンテナ技術を利用して提供する。
+%そこで, これまで本コースで使用されてきたサービス, また近年普及しているクラウドサービスと比較する。
+%
+%\subsection{ie-virsh}
+%ie-virsh は手元の PC で作成した VM を学科のブレードサーバにデプロイできるサービスである。
+%ie-virsh は ユーザの UID 及び GID 情報を取得することで, 他のユーザの VM を操作させない。表\ref{tb:ie-virsh}は ユーザが利用できる ie-virsh の機能である。
+%ie-virsh では VM の実行環境を提供するため, ユーザが好みの VM を構築できるなど自由度が高い。\par
+%本研究で実装したサービスでは, コンテナ作成に使用する Docker イメージで構築されたアプリケーションに限定される。
+%また, ユーザが欲しい環境は Docker イメージを作成しなければいけないため, Docker について学習する必要がある。
+%だが, コンテナは VM と違い開発環境やテスト環境の構築の容易さや, 他のユーザにイメージを共有することで同じ環境を利用することができるなどの良さがある。
+%
+%\begin{table}[htb]
+%  \begin{center}
+%  \caption{ie-virsh のコマンド}
+%  \begin{tabular}{c|l} \hline
+%    define  & XML の template を下に domain を作成 \\ \hline
+%    undefine & define で作成した domain を削除 \\ \hline
+%    list & define で作成した domain の一覧表示 \\ \hline
+%    start & 指定した domain 名の VM を起動 \\ \hline
+%    destroy & 指定した domain 名の VM を停止 \\ \hline
+%    dumpxml & domain の XML を参照 \\ \hline
+%    \end{tabular}
+%  \label{tb:ie-virsh}
+%  \end{center}
+%\end{table}
+%
+%\subsection{ie-docker}
+%ie-docker は Docker をラップしたツールであり, ユーザは学科のブレードサーバへ ssh で接続を行い CUI から利用することができる。
+%ie-docker は ユーザの UID 及び GID 情報を取得することで, 他のユーザのコンテナを操作させない。
+%表\ref{tb:ie-docker} は ie-docker で利用できる機能である。
+%この機能を使用しコンテナ作成などの操作を行うことができる。
+%だが, ie-docker ではユーザがコンテナで使用するイメージを管理者が用意する必要がある。
+%そのため, コンテナで使用したいイメージが用意されていないなどの問題があった。\par
+%本研究で実装したサービスでは, コンテナで使用するイメージは Docker Hub に登録されているイメージ, または作成したイメージを利用することができる。
+%ユーザが Docker イメージを作成できることで管理者の負担が少なくなると考える。
+%
+%\begin{table}[htb]
+%  \begin{center}
+%  \caption{ie-docker のコマンド}
+%  \begin{tabular}{c|l} \hline
+%    ps  & 起動中のコンテナの一覧を表示する \\ \hline
+%    run & コンテナを作成する \\ \hline
+%    start & コンテナを起動する \\ \hline
+%    stop & コンテナを停止する \\ \hline
+%    attach & 起動しているコンテナに attach する \\ \hline
+%    cp & コンテナにファイルを送信する \\ \hline
+%    rm & コンテナを削除する \\ \hline
+%    \end{tabular}
+%  \label{tb:ie-docker}
+%  \end{center}
+%\end{table}
+%
+%\subsection{digdog}
+%digdog は Kubernetes を利用したコンテナ貸出サービスである。
+%学生は Dockerfile を GitLab CI/CD を利用してビルドし, 学科の GitLab Container Registry に Docker イメージを登録する。
+%Web コンソールからコンテナ作成で使用するイメージは, 登録したイメージから選択することができる。
+%Kubernetes 上にコンテナを作成するため, 学生の入力を下に Deployment, Service, Ingress の作成を行う。
+%また, Namespace はユーザのアカウントID で作成され, Namespace ごとに RBAC の設定がされている。
+%そのため, 学生は手元の PC から Web コンソールから作成したコンテナを操作することができる。
+%表\ref{tb:digdog} は RBAC で許可されているリソースの操作である。\par
+%本研究のサービスは digdog を参考に実装されている。そのため, Kubernetes でのコンテナ作成は digdog と同じ流れで作成を行う。
+%だが, digdog では Docker Hub に登録されているイメージを選択することができない。
+%また, Kubernetes でのコンテナ貸出のため, Kubernetes クラスター上の Master が停止するとサービスを提供できないなどの課題があった。
+%本研究のサービスでは, Kubernetes でのコンテナの作成だけでなく, Docker でのコンテナの作成にも対応することで, Docker のみでサービスの提供ができるように改良を行った。
+%また, コンテナ作成時のイメージを選択ではなく入力にすることで, Docker Hub に登録されているイメージを利用できるように改良を行った。
+%
+%\begin{table}[htb]
+%  \begin{center}
+%  \caption{kubectl のコマンド}
+%  \begin{tabular}{c|l} \hline
+%    get  & Pod の一覧を表示する \\ \hline
+%    log & Pod の Log を表示する \\ \hline
+%    exec & Pod にアクセスする \\ \hline
+%    \end{tabular}
+%  \label{tb:digdog}
+%  \end{center}
+%\end{table}
+%
+%\subsection{クラウドサービス}
+%近年様々なクラウドサービスが普及し手元の PC から高性能なクラウド環境を利用することができる。
+%だが, クラウドサービスは無料から有料まであり。無料では時間制限や容量制限など様々な制限がある。
+%また有料だと設定のミスにより高額な請求がくるなど, 気軽に利用しづらい。
+%そのため, 本サービスはオンプレミス環境で実装を行った。
+%オンプレミス環境にすることで利用の制限がなく, サービスで使用するデータを自身で管理できるなどの良さがある。
+%だが, クラウドサービスと違い物理サーバなどのメンテナンスや, サービスの導入にあたって環境構築などの課題がある。
+%しかし, オンプレミスで運用していくことで, 学生の学習に繋がると考える。
 
 \section{今後の課題}
 本研究で実装したサービスでは学生が学習環境として利用するには, まだ必要な実装が不足している。\par
-本サービスでは, 大量のデータを用いる時に Singularity を使用できる環境を用意している。だが, Web コンソールから作成した Docker や Kubernetes のコンテナでは
-データの永続化が対応していないため, コンテナの削除時に共に削除されてしまう。学科のブレードサーバでは学生ごとのディレクトリがある。
-Docker ではそのディレクトリをコンテナ立ち上げ時にマウントすることで, コンテナ内のデータの永続化に対応できる。
-また, Kubernetes では Peresistent Volumes という永続ボリュームの仕組みがある。この Peresistent Volumes をユーザごとに管理することで, コンテナ内のデータの永続化に対応できる。
-このような対策でコンテナ内のデータの永続化に対応できるが, コンテナごとにデータの保存場所が違うなどの問題があるため, データを管理する仕組みが必要だと考える。\par
+本サービスでは, 大量のデータを用いる時に Singularity を使用できる環境を用意している。
+だが, Web コンソールから作成した Docker や Kubernetes のコンテナではデータの永続化に対応していないため, コンテナの削除で削除されてしまう。
+そこで, 学科のサーバでは学生ごとのディレクトリにマウントするなどの対策を行う必要がある。
+\par
 本サービスでは, 学生が自由に Docker イメージを作成できる。また, Docker イメージを Singularity 用のイメージに変換する。
-そのため, イメージの容量でブレードサーバのストレージを圧迫してしまう可能性があることから, 定期的にイメージを削除する必要がある。
+そのため, イメージの容量でブレードサーバのストレージを圧迫してしまう可能性があることから, あまり利用されていないイメージは定期的に削除する必要がある。
+\par
+次にネットワークの設定である。
+作成したコンテナへのアクセスには, コンテナが動作しているサーバの IP アドレス, 設定されたポート番号を使用する。
+そのため, 外部からアクセスなどに対応することができない。そこで, コンテナごとに IP アドレスを設定するなどの対策が必要である。
+\par
 また, 本サービスではユーザごとにリソースの制限を行っていないため, 過剰なリソースの占有を防ぐための対策をする必要がある。
-GPU などの負荷がかかるプログラムの実行で使用されるリソースにはジョブ管理ソフトウェアなどで対策をとる。\par
-本サービスは Docker Hub に登録されている Dokcer イメージを利用できるが, Docker Hub は誰でもイメージを登録することができる。
-そのため, Docker Hub に登録されているイメージにマルウェアが仕込まれている可能性がある。
-イメージの取得時にスキャンを行うなど, セキュリティ対策を考える必要がある。
+GPU などの負荷がかかるプログラムの実行で使用されるリソースにはジョブ管理ソフトウェアなどで対策をとる。\
 
-\section{まとめ}
-本稿では, 本コースで利用する新規サービスの設計と実装, また本コースで利用しているサービスとの比較を行った。
-学生がコンテナ技術を用いて学習環境を利用できるサービスの設計をし, マルチユーザ環境に対応した実装をすることができた。
-学生は学科アカウントを持っていれば, Web コンソールからコンテナの作成ができる。
-また, GitLab CI/CD を利用し Dockerfile から Docker イメージをビルドすることで, イメージの作成を学ぶこともできる。\par
-今後, テスト環境にデプロイを行い, ユーザやシステム管理チームからのフィードバックをもらい, 改善や実証実験を目指す。
+%学科のブレードサーバでは学生ごとのディレクトリがある。
+%Docker ではそのディレクトリをコンテナ立ち上げ時にマウントすることで, コンテナ内のデータの永続化に対応できる。
+%また, Kubernetes では Peresistent Volumes という永続ボリュームの仕組みがある。この Peresistent Volumes をユーザごとに管理することで, コンテナ内のデータの永続化に対応できる。
+%このような対策でコンテナ内のデータの永続化に対応できるが, コンテナごとにデータの保存場所が違うなどの問題があるため, データを管理する仕組みが必要だと考える。\par
+%本サービスでは, 学生が自由に Docker イメージを作成できる。また, Docker イメージを Singularity 用のイメージに変換する。
+%そのため, イメージの容量でブレードサーバのストレージを圧迫してしまう可能性があることから, 定期的にイメージを削除する必要がある。
+%また, 本サービスではユーザごとにリソースの制限を行っていないため, 過剰なリソースの占有を防ぐための対策をする必要がある。
+%GPU などの負荷がかかるプログラムの実行で使用されるリソースにはジョブ管理ソフトウェアなどで対策をとる。\par
+%本サービスは Docker Hub に登録されている Dokcer イメージを利用できるが, Docker Hub は誰でもイメージを登録することができる。
+%そのため, Docker Hub に登録されているイメージにマルウェアが仕込まれている可能性がある。
+%イメージの取得時にスキャンを行うなど, セキュリティ対策を考える必要がある。
+
+%\section{まとめ}
+%本稿では, 本コースで利用する新規サービスの設計と実装, また本コースで利用しているサービスとの比較を行った。
+%学生がコンテナ技術を用いて学習環境を利用できるサービスの設計をし, マルチユーザ環境に対応した実装をすることができた。
+%学生は学科アカウントを持っていれば, Web コンソールからコンテナの作成ができる。
+%また, GitLab CI/CD を利用し Dockerfile から Docker イメージをビルドすることで, イメージの作成を学ぶこともできる。\par
+%今後, テスト環境にデプロイを行い, ユーザやシステム管理チームからのフィードバックをもらい, 改善や実証実験を目指す。
 
 \begin{thebibliography}{99}
 
@@ -408,7 +520,7 @@
 \bibitem{gitlabcicd} GitLab CI/CD, https://docs.gitlab.com/ce/ci/, 2020/9/11.
 \bibitem{nvidia-docker} NVIDIA Container Toolkit, https://github.com/NVIDIA/nvidia-docker, 2020/9/11.
 \bibitem{digdog} 秋田 海人 and 高瀬 大空 and 上地 悠斗 and 長田 智和 and 谷口 祐治, 情報系学科における教育研究情報システムの運用管理並びに新規システムの構築に関する取り組み, インターネットと運用技術シンポジウム(2019).
-\bibitem{ie-virsh} 平良 太貴 and 河野 真治, OS 授業向けマルチユーザ VM 環境の構築, 研究報告システムソフトウェアとオペレーティング・システム(OS)(2014).
+%\bibitem{ie-virsh} 平良 太貴 and 河野 真治, OS 授業向けマルチユーザ VM 環境の構築, 研究報告システムソフトウェアとオペレーティング・システム(OS)(2014).
 
 \end{thebibliography}
 \end{multicols*}